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
So what is microservice architecture?
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.
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
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
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.