Learn With Mainul

Microservices is a software development style that has grown quite a trends in Software development and management practices. You can find a lot of articles and books on this architectural paradigm but yet I think its worth to write another one to keep only the basics of it. This article aims to give a basic insight about microservices, define their essential characteristics, advantages and the pain points we face on practicing the microservices.

What are Microservices?

“A microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies” – by Martin Fowler

In a small word as its name says microservices is all about split the system into micro(small) services. These practices meant to increase the speed and efficiency of developing and managing software solutions at scale. Agile methods, DevOps culture, cloud, containers, and the widespread adoption of CI/CD methods are making it possible to build truly modular large scale service-optimized systems for both internal and commercial use.

In contrast with the Monolithic application approach where most of its functionality within a single process, a Microservice application segregates functionalities into smaller services.

The concept behind microservices is similar to Service-Oriented Architecture (SOA), which is why this style of architecture has been referred to as SOA with DevOps, SOA for hipsters, and SOA 2.0

Key Characteristics of Microservice

Independent DURS (Deploy, Update, Replace, Scale)

Each service can be independently deployed, updated, replaced, and scaled. To guarantee independent deployability, we need to ensure our services are loosely coupled.

Domain-Driven Design 

Microservices are ideal in realising multiple business functions, with each microservice focusing on a single business function or sub-function. Functional decomposition can be easily achieved using Eric Evans’s DDD approach.

Own Their Own Data

Encapsulating the data inside the service gives the best possible way to reduce the coupling between the services. It also reduce the effort need to change the business related functionality. Although in real life it may not be possible to define database for each service. Don’t share databases, unless you really have to. And even then do everything you can to avoid it.

Single Responsibility Principle 

Application is decomposed into a single purpose, highly cohesive and loosely coupled services managed by cross-functional teams. Each service is responsible for a single part of the functionality and does it well.

Lightweight, Smart Endpoints, Event Driven

Each microservice owns its domain logic and communicates with others through simple protocols such as REST over HTTP. Microservice can also be develop in event-driven manner where services produce and consume messages to communicate.

Advantages of Microservice

Technology Heterogeneity

As the services are loosely coupled and resides in its own boundary, we can decide on the technology for each service. This allow each team/squad to decide different technology stack that is better for a particular business domain and achieve the desired performance level. Like the User service can be developed in Golang using the GraphDB as data storage where the Post service can be developed in Java using DocumentDB and Photo Service in NodeJS using Blob Store.

Microservice also allow to adopt technology more quickly and on sync with the advancement of the technologies. 

Scalable

There always a small part of the whole system which are constrained to the overall performance. With smaller and independently deployable services, we can scale only those services that need to scaling. This will also allow us to run other services to run on less powerful hardware.

We can also configure the services for on-demand provision ( like in AWS) . It will allow to scale the services when it needs to scale and reduce a operating cost in great margin.

Reliable

If a specific microservice fails, we can isolate that failure to that single service and prevent cascading failures that would cause the app to crash. This fault isolation means that our critical application can stay up and running even when one of its modules fails.

Pain points on Microservice

Data Consistency

One of the pain points of practicing and developing the microservices is to provide the data consistency on different service. As the data store is distributed in different services there is no central single source of truth. In the distributed manner, data consistency cannot be enforced (refer CAP theorem). Instead, we may enforce the eventual consistency.

Further reading : Data Consistency in Microservices Architecture

Latency

As the services are distributed and it may needs to communicate with a dozens of other services over the network, it may result latency on the system. Its hard to determine the operation latency while the service is being developed. In that case the service can be developed incrementally and checking the latency to find it overall impact. Different distributed tracing tools ( like OpenTelemetry ) can be used to measure the end-to-end latency of the operation.

Testing

Unit testing may be easier with microservices but end-to-end testing can be really hard. The tests become very large as it needs to run over multiple services. Other dependent services need to be deployed and configured for the test scenarios.

Security

The services are distributed over the network and information flows between services. This makes the system vulnerable for possible security breach (like data is being manipulated as part of man-in-the-middle attacks). In microservice, we need to be more careful on protecting the data on transferring between services and ensure the endpoints are protected.

Should we use Microservice?

As we can see microservice is not the silver bullet to solve all architectural problems in our application. Developing distributed system is complex. But still it is worth serious consideration for enterprise applications. Monolithic application is useful when it has a simple business requirement and lightweight in nature. But if the application expands in multiple domains it will be an ideal candidate for the microservice architecture. Microservice by default provides the agile way to develop the complex applications.

For last couple of years we have seen a lot of adaptation in microservices. Introducing cloud computing and on-demand scalability gives the microservice architecture a great boost in all enterprise solutions. Even a lot of distributed tracing and monitoring services are coming up to tackle the issue we faced in maintaining the services.