Enterprises have been struggling for years to develop applications that are agile and quick to change. Microservices architecture provides a way to address this challenge and has therefore caught the attention of enterprise IT teams. Beyond the initial enthusiasm, proof of concepts and pilot implementations, enterprises are struggling to adopt this architecture. In this blog, I explain why enterprises need to consider a strategic approach to Microservices architecture and suggest a four pronged approach to adoption.
Microservices Enable Evolutionary Architecture
There are quite a few architecture styles that have emerged over the last few years from the internet companies that don’t have the constraints of legacy systems. One of the key characteristics of these architectures is their ability to respond to changing business needs, known as evolutionary architecture.Microservices architecture is one such architecture style that can address variety of concerns that effect the agility of systems. From a technical standpoint, Microservices uses service orientation principles and functional partitioning to “monolithic” applications to make systems function as relatively independent services. From a business benefit standpoint, it makes enterprises digital ready and offers multiple advantages to them. Some of which are:

  • Allows experimentation & innovation, leveraging cutting edge technologies, but localize the related risk only to a specific service.
  • Because of independent services, scaling of teams is easier, as Microservices reduces coupling between teams and enables more autonomy and accountability.
  • Improves resiliency of mission critical systems, by scaling and replicating parts of systems rapidly. In case of failure of a specific service, rest of the system can continue to run.
  • Enables cloud adoption and cloud native architectures by deployment of services over multiple VMs or containers working together
Thinking about Microservices Adoption & Challenges
Embracing Microservices architecture at an enterprise level poses unique challenges especially if we consider large enterprises that have complex application landscapes. Some of the common questions that both large and mdi-size organizations ask are:

  • Where do we start the adoption of Microservices?
  • Coupling within existing systems can be complex. Is there a way to prioritize application portfolio?
  • What capabilities do we need to start adopting this architecture style at scale?
  • What practices should we use to ensure successful adoption and get best of Microservices architecture?
  • There are no proven enterprise adoption patterns, as there is very little enterprise wide adoption outside Internet native companies. How do I do enterprise wide adoption?
Approaching Adoption Strategically
Often enterprises take a tactical approach and use Microservices to douse fires in specific problem areas. Such thinking will do more harm than good. Hence, I recommend a logical and strategic four pronged approach towards adoption. These activities need not happen in the mentioned order though. Necessary capabilities will have to build systematically, which will help realize full benefits of Microservices.

Discover: Articulating the business benefits and creating a case for Microservices adoption. Based on the maturity of enterprise this can be optional. However, one might have to build a case to get the necessary investments and budget allocation.
Plan: Assess the current state capabilities and identify the gaps in terms of capability that is required for adoption at scale. These capabilities include frameworks, technology choices, governance etc. Another important activity is to identify the applications of priority where Microservices architecture can be applied.
Act: Build the base capabilities needed for Microservices. Choose the right technology stacks. Build out platform capability. Setup guidelines and prepare playbooks. Put forward service design guidelines and start implementing services.
Optimize: Take Microservices architecture into production at scale. Ensure services are organized per domains. Automate the deployment processes. Bring in strong management & monitoring capabilities. Keep an eye for potential pitfalls.

This post is cross posted from to
Application architectures are evolving from the era of large monoliths to a more distributed design based model. One of the key initiators of this movement is the advent of cloud computing and the ability it brings in terms of handling ever increasing scale. When an enterprise primarily soaked (people and processes) with the model of building and managing monolithic applications, the journey to build new distributed systems requires re-learning some of the older design techniques and adopting some new patterns. As part of this, I will detail certain architecture concerns that become prominent when moving to a distributed model of application

  • Scheduler/Orchestration management – From managing 100s of instances to managing 1000s of instances require the ability to orchestrate/schedule service instances/containers across hosts in a seamless manner. To handle increasing scale, workload scheduling/orchestration is a key ingredient of distributed system. Products like Docker Swarm, Kubernetes, Mesos, Marathon etc are some of the leading products in this space 
  • Service Discovery/Registration – As the container based services go up and down, there need to be mechanism to register/unregister the services along with the mechanism to discover the service end points at run time. Products like Consul, Zookeeper, etcd, Confd, Eureka are some of the leading products in this space. Most of these products support load balancing of the incoming traffic across the service instances. 
  • System State Management / Cluster Management – As the cluster grows, there is a need to manage the system state of the cluster. What are the SRV for each of the services, how many instance, on what hosts, what is load etc. To manage this, there is a need for cluster management that keep track of the system state. Products like Docker Swarm Agents, Kubernetes Nodes/Masters, Mesos Slaves, Containership etc are some of the leading products in this space 
  • Data storage – the container storage is ephemeral, which means the any data that needs to be retained beyond the container lifecycle need to be persisted outside. Projects like Docker Volume Plugin, Flocker, Kubernetes Persistent volumes etc are some of the key products 
  • Network – with each of the containers running different processes, there is a need to manage and at time isolate which container services can access which other services. Multiple containers are running on same host sharing the network resources might require security groups to be created for container isolation. Similarly, containers might want to discover services that are hosted across hosts and need simple model to access those. Products like Flannel, Weaveworks, Calico are some of the products in this space. 
  • Monitoring/Auditing/Logging – With 1000s of containers running, monitoring/auditing /logging each of the containers become a tough problem. Data/Logs need to be pulled from each of the container for analysis. Products like Loggly, Fluentd, logentries, datadog, ELK stack are some of the key products in this space. 
Besides this, other factors that need to be considered are Container OS and Container Runtime when architecting a distributed application. Other factors like application runtime, deployment management, DNS, Security, SSO/OAuth, API Gateways, Circuit breakers, Performance/Scalability Patterns etc still need to be handled. In your experience, anything else that is a key architecture concern for distributed application, please do share.

This post originally appeared at
With the advent of micro-services, the application design paradigm has undergone a major shift. The days of developing monolithic applications are over. We are bringing in the principles (read SOA) hereto the preserve of applications or system integration space into the application development world.

General steps for solution architecture are –
  • Break down/decompose the application into functional areas. These functional area’s provide us the with the bounded context
  • Within the functional bounded context, design/define your micro services
  • Functional areas talk to each other over micro services or use some kind of event queue models 
  • Each of the functional areas only expose services to be consumed by the application 
Since the micro-services are consumed within the application, the need of ESB is not there. There is no message transformation or mediations required. But service discovery & load balancing of service instance still need to be done, new tools have come up (e.g. Netflix Eureka)

Now from the design perspective, you have the service identified, exposing endpoints.
Qs comes, who will do the orchestration of service invocation and aggregation of data from multiple services? 

Where does the intelligence lies ?


  • Server Side - Create an aggregator service that internally invokes other services (across functional domains) and aggregates the results. This aggregator service is invoked by the application presentation tier
  • Presentation/Application Side – If you implementing JSP or server side view creation, the presentation tier can perform the orchestration across the services and aggregate the data. One can use Lambda/Futures to implement non blocking call model also
  • Client Side – In this case, the invocation of services and aggregation of data happens at client side. The UI is composes of multiple widgets, which call up individual services and aggregate the response on the client side

Where should you intelligence lie?

There is no correct answer, depending on the use case, different options can be applied. One can also apply multiple options within the same application depending on the type of the client to be supported or at times, you do not want to expose individual services and an aggregator service might be better.

This post originally appeared at
Slide deck of my talk at Cloud Connect 2013 in Mumbai.   I spoke on the topic of architecting multi-cloud applications.   

This post originally appeared at