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.

An architecture style is a family of architectures that share certain characteristics. For example, N-tier is a common architecture style. Architecture styles generally don’t dictate the use of particular technologies, but some technologies are well-suited for certain architectures. For example, containers are well suited for microservice since they go hand-in-hand for the deployment.

In this article, you will learn about the typical considerations, challenges and benefits of the microservice architecture style.

Cross posted from : DevOps.com

While microservice applications are built as a set of modular components, they are easier to understand, simpler to test and effortless to maintain over the life of the application. It enables organizations to achieve agility and be able to improve the time it takes to get working enhancements to production.

It also enables the continuous delivery/deployment of large, complex applications and the evolution of its technology stack. Having detailed out on the benefits side there are quite a bit of challenges as well, which we will discuss in the next section.

Quick Snapshot

Constraints imposed by Microservices style
Consider challenges vs benefits
Make the Choice
Useful Resources :

Constraints imposed by Microservices 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 vs 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 and so is easier to understand and change.	Implementing requests that span multiple services is more difficult. Maintaining data consistency between services 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 & 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 challenge.
Eliminates long-term commitment to a technology stack.	Overhead of multiple JVM runtimes (or equivalent) and increase in memory consumption.

Scenarios where you can consider to go for Microservices

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.

Useful Resources :