Sunday, 23 March 2014

Microservice architecture

This year QCon 2014 London many speakers mention microservice architecture style. They talk about the problems they face with monolithic system and how they solve the problems using this type of architecture style. Martin Fowler together with James Lewis has written a multiple part article about the characteristics of microservice. Monolithic system has several disadvantages:
  • It is difficult to change.
  • It takes time to add new feature.
  • Difficult to test.
  • Deployment is a pain.
  • and many more
But it happens to every developer's life. Most of us are still going through this. Business people come to us to have something that may generate money for the business and we start with something small. We keep on adding new features to this system and over the time it becomes a monolithic system with all the characteristics mentioned above. There is another scenario - we spend several months to build something and then realize that this is not what business wants, wasting of valuable time and money. Microservice architecture can help us to overcome these situations.

So what is microservice architecture?

Microservice Architecture is a concept that aims to decouple a solution by decomposing functionality into discrete services.

So rather than putting all functionalities in one application, you go for functional decomposition. Each of the function or capability of the application becomes a service. Each of the service becomes easier to understand, develop, test and deploy. These services can scale and evolve at their own pace.

When developing application using microservice architecture style, we need to think about business capabilities of the application.

Each capability represents a service and has its own bounded context.

An example: Reward Management System

Say ABC company wants to develop this system that gives rewards to their valuable customers when they opt into a offer after seeing it in a campaign and perform some activities written in that offer. Once they complete these activities, the system gives them rewards to make them happy.

Now after performing some brain storming sessions, developers of that company come to a conclusion that the Reward Management System needs to have four capabilities:
  • Management of campaigns
  • Management of offers
  • Tracking of customers' activities
  • Give reward

They can develop one application with all capabilities in one place. But since they want to give a try microservice architecture style, so they decide to develop individual service for each of the capabilities. So
  • Management of campaigns becomes Campaign Service
  • Management of offers becomes Offer Service
  • Tracking of customers' activities becomes Tracking Service
  • Give reward becomes Reward service

Bounded Context

A Bounded Context is an explicit boundary within which a domain model exists. Inside the boundary all terms and phrases of the Ubiquitous Language have specific meaning, and the model reflects the Language with exactness.

In Reward Management System each of the capabilities has its own bounded context. Campaign Service only deals with campaigns: creating, updating, viewing, deleting, associating offer with a campaign and approving, publishing campaigns. Offer Service manages offers: again creating, updating, viewing, deleting offer. Tracking service tracks which offer a customer has chosen to opt in and how far she or he has completed her or his activities to get the reward. Reward service gives reward once customers complete their activities. All these services talk to each other to reach a common goal which is giving rewards to the customers.


This type of architecture style has many benefits:

Reduce complexities to understand

In microservice architecture: One business capability = One Service. So services are not suppose to be very big. Each of these service should not big enough to overcome the thinking process. You need to understand what it does. If any service goes beyond your thinking process, then it may be doing more than one thing. So it may be the right time to break it further. This reduces the complexities to understand a lot and eventually help in thinking process. In Reward Management System example, development team is not thinking the full system, most of the time they are thinking about individual service in isolation.

Easy to change

Since each service is small and focus on one capability of the system, you can change it quite easily. Even after development, if you find that it is not meeting business needs (based on different business relevant metrics), you can throw it and develop it again.

Cross functional teams

A cross-functional team is a group of people with different functional expertise working toward a common goal. Cross functional team is a self-directed team. Assigning a task to a team composed of multi-disciplinary individuals increases the level of creativity and out of the box thinking. Each member offers an alternative perspective to the problem and potential solution to the task. [wiki]

Microservice architecture opens the door for cross functional teams. These teams come with full range of skills for the development: user-experience, back-end development, testing, database etc. They design, build, test and deployed it. This team takes the full responsibility for the software in production.

Choice of technology stack

Same technology stack may not be suitable to solve all types of problem. In microservice architecture different team can select different technology stack for different services based on the problem and different other requirements. For example: one team can go typical java stack (Spring, Hibernate, RDBMS), other team can go for Node.js and NoSQL. There are also many other JVM based languages. Point is, in monolithic architecture, we often stuck with one set of technology whereas microservice architecture gives us many options to choose from. Polyglot programming and polyglot persistence are quite common and easy to do in microservice architecture.


Since services are small and doing one task, testing becomes easy in microservice architecture. We can add many automated tests that can be run using continuous delivery pipeline.

Real time Monitoring and Metrics

Real time Monitoring and Metrics are an important part of microservice architecture. We need to check both architectural elements (how many requests per second is the database getting) and business relevant metrics (such as how many customers opt into a offer per minute are received). Dashboards can be developed that show up/down status and a variety of operational and business relevant metrics of different services.


There are many other benefits of this architecture style that are not mentioned here. I personally feel that developers can make their professional life easier and less painful by using microservice architecture style. After all, simple solution matters.