When Should You Go for Microservice Architecture?

There is steady increase in the adoption of microservice architecture style since 2014 (Figure 1). Microservice architectural style structures an application as a collection of loosely coupled services that implement business capabilities.

Related Categories

Constraints Imposed by Microservice Style

By adhering to the following constraints imposed by microservice architecture style, what we get is a system where services can be deployed independently, faults are isolated, frequent updates are possible and it’s easy to introduce new technologies into the application.

Each service represents a single responsibility.
Every service is independent of the others.
Each service needs its own JVM (or equivalent) so instances are isolated.
Data is private to the service that owns it.
Services do not share data and need to implement queries that need to retrieve data owned by multiple services.
Well defined mechanism to implement service-to-service communication and scheme to deal with partial failure.
Requests that span multiple services and require careful coordination between the teams.
Testing to cover the interactions between services.
Deploying and managing a system comprised of many different services.

Consider Challenges Versus Benefits

Each architectural constraint has its own associated challenges/benefits, so it’s important to understand and balance both. Before adopting any style of architecture, you have to ask yourself if the benefits outweigh the challenges for the application you are considering.

In the table below, we take a look at the benefits versus challenges of microservice style applications.

Benefits	Challenges
Enables the continuous delivery and deployment of large, complex applications.	There is an additional complexity of creating a distributed system.
Improved maintainability: Each service is relatively small so it’s easier to understand and change.	Implementing requests that span multiple services is more difficult. Maintaining data consistency between service(s) is a challenge.
Better Testability: services are smaller and faster to test.	Testing the interactions between services is more difficult.
Better deployability: services can be deployed independently.	Increased operational and deployment complexity of deploying and managing a system comprised of many different services.
Each team can develop, test, deploy and scale their services independently of all of the other teams.	Implementing requests that span multiple services requires careful coordination between the teams.
Improved fault isolation.	Inter-service communication and dealing with partial failure implementation is challenging.
Eliminates long-term commitment to a technology stack.	Overhead of multiple JVM runtimes (or equivalent) and increase in memory consumption needs to be taken care of.

Scenarios Where You Can Consider Going for Microservice

Consider an scenario where you are developing an enterprise application that must support the following characteristics:

Support for different variety of clients that includes desktop browsers, mobile browsers and native mobile applications.
Expose an API for third parties to consume.
Integration with other applications via web services or a message broker.
Run multiple instances of the application on multiple machines to fulfill scalability and availability NFR requirements.
Adopt emerging technology stack.
Planning to go for continuous deployment pipeline setup for the application.

From the requirements above, you can very well say the application is 100% fit for a microservices architecture.

You have to define an architecture that structures the application as a set of loosely coupled, collaborating services. Services can communicate using either synchronous or asynchronous protocols. Services can be developed and deployed independently of one another. Each service has its own database in order to be decoupled from other services.

Let’s look at some of the typical scenarios where you can consider going for microservice style of architecture:

Monolithic application migration due to improvements needed in scalability, manageability, agility or speed of delivery.
Re-platform a legacy application by transforming functions/modules to microservices.
Rewriting legacy application to modern languages, technology stack to meet the demands of modern business.
Individual cross-cutting services that are independent in nature. For example: encryption services, authentication services, etc.
Independent business applications or services reused across multiple channels. For example, payment services, login services, flight search services, customer profile services, notification services, etc.
Commonly used enterprise applications. For example, time tracking application.
Scenarios where a service provider makes computing resources and infrastructure management available to the customer as needed. For example, forecasting services, price calculation services, prediction services, etc.
Back-end services for responsive client-side web application where data could be coming from multiple channels or different data sources.
Highly agile applications or applications demanding speed of delivery or time to market or innovation pilots, etc.
Applications that got polyglot, multi-language, cloud application development.

Make the Choice

Before going for microservice architecture, make sure you know the challenges and benefits. Otherwise, your application design could end up with a design that fits the style but does not achieve its full potential. Adopt microservices only if you see enough value for your applications. Also note sometimes relaxing a constraint is better than insisting on architectural purity.

— Karthikeyan Shanmugam