Microservices - The new application architecture

Microservices are all the buzz now and every cloud provider is talking about how one can implement microservices on their platform.

But why are microservices such a big deal?

If you look at the evolution of application architecture you see a transition from monolithic to client-server to multi-tier architectures. However, most of this componentization and layering was focused on technical separation of concerns and design patterns emerged to provide loose coupling between these different layers (think UI, application server, database etc.). Microservices, on the other hand, provide a vertical kind of partitioning that segregates application logic based on functional decomposition and the single responsibility principle.

Imagine you're developing a complex ecommerce application that consists of various features that you would like to provide to your end-user - Product Catalog, Shopping Cart, Payment Options, etc. One way to approach this would be to define what is required in each of the functional modules and create a holistic design that encompasses the entire application’s functional scope. Another way, using the microservices approach, would be to look at each of these functions as fairly independent of each other and design each of these as such. This would give you the benefit of using the best technology options to implement that particular piece of functionality. E.g. for a Product Catalog you could leverage a NoSQL database and cloud platform capabilities to store images. Similarly you could use a SQL database for transactions in the payment service. The other benefit you get from doing this is that you can horizontally scale services when required, which is often the case in an ecommerce application where you have variable workload. You could, for example, instantiate multiple Product Catalog services to meet the holiday demand of shoppers browsing the site or accessing it from their mobiles.

Logically, the next thing that comes to mind is, how do these separate "services" then combine together to deliver the complete functionality of an application. That's where "dumb pipes" come into play. Based on the Unix concept of "pipes", this plumbing provides the necessary glue between your microservices. As Gary Olliffe of Gartner blogs, this is akin to "building services with the guts on the outside". 

Some of the advantages of a microservice architecture are self-evident - contained impact of changes, the ability to add features in a non-disruptive way and the ability to leverage Y-axis scalability being some of them. The disadvantages are managing the complexity of integration between the various services, defining the granularity of services and the complexities that come from managing a distributed system architecture - fault tolerance, asynchronous calls, compensating transactions etc. However, the benefits from adopting such an architecture, particularly the ability to scale-out and the ability to independently build-out features, far outweigh the disadvantages.

Disclaimer: What I express here is my own and should be attributed as such. It is not necessarily representative of a point of view of my employer.