Microservices Architecture: An Introduction

The microservices architecture pattern is getting a lot of attention these days and it’s trending. If it is hard to believe, then just check what Google Trends says.

What is it?

A microservices architecture makes more sense when we compare it with monolithic application design:

In monolithic architectural design we create a big cumbersome application with all modules tightly coupled inside a single executable, which is typically deployed on a web or application server.
A typical monolithic architecture application looks like:

There are some disadvantages to this architectural design. These disadvantages or drawbacks have become the strengths of microservices architecture:

1. No frequent and easy releases - As monolithic applications grow in size, due to tight coupling between components, it becomes difficult to do easy and frequent releases. Release planning takes a lot of time of people from various groups. Frequent release is discouraged for making sure the application should not break due to the newly released feature.
2. Problem in continuous delivery - We may not notice this problem if the application is small. In case of bigger monolithic applications, deployment times can be frustratingly long and slow. If a single change to the application would require the entire application to be redeployed, then this could become an obstacle to frequent deployments, and thus an impediment to continuous delivery. This could be a serious issue if you are serving a mobile application where users expect the latest cool new features all the time.
3. Difficult to manage team and project - Project management has its own challenges in monolithic application development. Even a modularized application has interdependency in terms of deployment and release. It takes a toll in terms of time and effort to plan the release and manage tightly coupled interdependent modular development.
4. Expensive scalability & performance - It is possible to scale a monolithic application but the cost is very high.
5. Lack of technology diversity - When we choose a technology stack for a monolithic application, we consider a balanced stack which can serve well for all of our requirements. We can not employ specific technology for specialized needs.
6. Not easy to replace components - It is very difficult to replace any component with a better design or performance without affecting the whole architecture.

Definition

In short, Microservices architectural style defines a setup, where application components are standalone applications of their own. These independent application components talk to each other either using RMI (Remote Method Invocation), Restful Web Services or Push Messaging.
A typical Microservices based application setup is given here:

While designing systems in microservices architecture, we should be identifying independent components/modules appropriately. These components will be mini applications, which will be developed separately. They will follow their own development and deployment lifecycle.
Consider we are developing one school management system. In a school management system we have various important components like student registration, attendance, fees, assessments, etc.
When we develop this application using microservices architecture we will have independently deployed mini applications for student registration, attendance, fees and other modules.
In a general setup we can have scenarios where we need data from various components for a single request. Ideally, we will have a API gateway or front controller which will aggregate data from these components and give it back.
We should have inter-component communication. Components can communicate over REST APIs or Messaging or RMI (Remote Method Invocation).

Characteristics of microservices architecture based application are as follows:

1. Service enabled, independently running components.
2. Independently running components classified around some business capabilities.
3. Product mentality over project.
4. Smart components using simple communication channels like simple RESTish protocol or lightweight messaging queue.
5. Decentralize standards. Each independent component can use their exclusive standard for development and deployment.
6. Decentralized data management. Observe in the above diagram, how individual components have their own data storage.
7. Automated infrastructure management. For deployment of independent components, we need to rely on automated infrastructure management to reduce the complexity.
8. Application design considering failure in mind. There are several independent moving parts in applications. In the event of the receiver not getting a response, it should be handled gracefully.
9. Evolutionary design for getting the best possible decomposed system, which can be replaced and upgraded without affecting its collaborator.

Issues

There are some drawbacks or additional work, which we find in Microservices Architecture based application:

1. Team communication overhead - Microservices architecture reduces the team management complexity, but it is not able to diminish the need for team communication. Teams need to make sure that updates in one team's service does not break another's team functionality. We find this problem in monolith architecture applications, too.
2. Formal documentation overhead - Every individual running a component application needs to keep updated schemas and interface documents all the time. It helps other teams who are using the service.
3. Non uniform application - We can choose a different technology stack for different components (polygot). It leads to a problem of non uniform application design and architecture. It can increase maintenance costs in the long run.
4. Dev-Ops complexity - We need to have a mature DevOps team to handle the complexity involved in maintaining microservices based applications. Due to several moving parts of the application, it becomes complex and requires a level of expertise.
5. Increased resource use - Initial investment to run these applications is high because all the independently running components need their own runtime containers with more memory and CPU.
6. Increase network communication - Independently running components interact with each other using the network. Such systems require reliable and fast network connections.
7. Marshalling and unmarshalling - When one component needs data from another component, the sender marshals the data in some standard from its internal representation, while the receiver unmarshals data in its own representation before use. This definitely requires more processing in comparison to conventional application architecture.
8. Network security - Inter service communication needs to be secured to avoid any security breach. Due to several moving parts, these applications are more prone to security vulnerabilities.
9. Testing - Testing of such applications is definitely harder in comparison to monolith applications.
10. Production monitoring - Cost to monitor such applications is higher. Unavailability of the right tools is also an issue to be considered.
11. High upfront cost - Running multiple applications will incur more cost in comparison to monolith applications.

All the issues we had mentioned above can be solved with extra effort or usage of adequate tools.

How to decompose the application into services?

Another challenge is deciding how to partition the system into microservices. This is very much an art, but there are a number of strategies that can help:

1. Decompose by business capability and define services corresponding to business capabilities.
2. Decompose by domain-driven design subdomain.
3. Decompose by verb or use case and define services that are responsible for particular actions. e.g. a Shipping Service that’s responsible for shipping complete orders.
4. Decompose by by nouns or resources by defining a service that is responsible for all operations on entities/resources of a given type. e.g. an Account Service that is responsible for managing user accounts.

Ideally, each service should have only a small set of responsibilities. (Uncle) Bob Martin talks about designing classes using the Single Responsibility Principle (SRP). The SRP defines a responsibility of a class as a reason to change, and states that a class should only have one reason to change. It make sense to apply the SRP to service design as well.
Another analogy that helps with service design is the design of Unix utilities. Unix provides a large number of utilities such as grep, cat and find. Each utility does exactly one thing, often exceptionally well, and can be combined with other utilities using a shell script to perform complex tasks.

Known uses

Most large scale web sites including Netflix, Amazon and eBay have evolved from a monolithic architecture to a microservice architecture.
Netflix, which is a very popular video streaming service that’s responsible for up to 30% of Internet traffic, has a large scale, service-oriented architecture. They handle over a billion calls per day to their video streaming API from over 800 different kinds of devices. Each API call fans out to an average of six calls to backend services.
Amazon.com originally had a two-tier architecture. In order to scale they migrated to a service-oriented architecture consisting of hundreds of backend services. Several applications call these services including the applications that implement the Amazon.com website and the web service API. The Amazon.com website application calls 100-150 services to get the data that used to build a web page.
The auction site ebay.com also evolved from a monolithic architecture to a service-oriented architecture. The application tier consists of multiple independent applications. Each application implements the business logic for a specific function area such as buying or selling. Each application uses X-axis splits and some applications such as search use Z-axis splits. Ebay.com also applies a combination of X-, Y- and Z-style scaling to the database tier.
There are numerous other examples of companies using the microservice architecture.