Insights on Microservices - More than just the definition

Microservices has become the new buzz word in the industry today but it's not just about creating loosely coupled services. The real benefits of Microservices can only be achieved only if it is properly architected. Microservices are good but it also comes at a cost. There is a substantial increase in the complexity of the application when it is architected in MSA.

The formal definition of Microservices would be - "Small autonomous services that work together, modeled around a business domain"

Microservices is an architecture pattern where an application is refactored into separate services. Services talk to the rest of the world via APIs. Each Microservice is self-contained and may have a different datastore altogether.

The major need for the evolution of Microservices architecture was to be able to horizontally scale the apps. At this point one might think that even the monoliths can also be horizontally scalable then we do we need Microservices architecture. There are many answers to it few of them are -

1. “Scale What You Need To Scale” - In case of Monolith we try to build all the capability of the system and get it to run, as a single executable, in a single process while MS try to split it up and take every individual component in the complete software, put it in its process and let's them talk via IPCs like REST, Messaging Queues etc. This gives us advantage and flexibility of scaling the individual component of the system as per the demand of the component. For example - In a core banking application, the User Preferences module would generally have less load than Transactions Module, Microservices architecture gives us the ability to scale only the Transactions Module without worrying about other modules.
2. “Uncommon Infrastructure” - In case of Monoliths, the varied kind of modules are deployed onto the same infrastructure. This might not be a very useful strategy because there might be one module which would be CPU intensive and other which might be memory intensive. With Microservices, the deployment infrastructure can be tailor-made according to the functionality of the module.
3. “No central gateway to deployment” - In today’s world, velocity to production is directly proportional to the Business. More the velocity better the business. Microservices comes handy here, each Microservice owner is end to end responsible for its own Microservice. Since the Microservices are loosely coupled, its overall impact on the system is minimum. This gives the loosely coupled component the perfect edge to move to production much faster.

There are a lot many advantages like enablement of polyglot architecture, independent programming languages etc.

In order to adapt to MSA, the main thing to be concerned about is Statelessness in all the services(except for Caching and Persistence services) what that means is you don’t maintain stickiness and then if the node dies, the failover will happen easily. But how can you be sure that you are truly stateless? You can only be sure if you do destructive testing in your cluster with the tools like Chaos Monkey, Chaos Kong etc.

When we are talking about multi-service multi-node deployments there is one thing which we need to worry and that is Cascading Failures - whenever there is a failure due to some fault in one of the nodes in the cluster, the calling node should isolate the failure. If the consumer doesn’t absorb the failure occurred in the subsequent node, there will be rippling effect in the cluster which may lead to all the nodes in the call graph failing one by one. Whenever there is a failure the application has to decide whether it is a critical failure or non-critical failure. If it is a non-critical failure then the application can still go ahead with the functionality. Example of a non-critical failure would be the failure in recommendation service on the product description page. The application may decide to isolate the recommendation service's failure and go ahead with the display of the product information.

Moving to microservices is not a cake walk, in order to unleash the real power of MSA, there are a few supporting infrastructures required - Centralized Logging, Smooth CICD Pipeline, Automation Testing etc.

For instance, Centralized Logging is one of those few things which is mandatory to have. Logging in MSA is very different from traditional applications logging, the application needs to have something like ELK(Elastic Logstash Kibana) stack to forward the logs from the all the nodes in the cluster and dump it onto centralized location be it Datastore, Filesystem or Elasticsearch. I would prefer dumping it into Elasticsearch so that logs could be easily visualized using Kibana or it can be further available for aggregation, modeling etc.

Microservices brings great values to development velocity. Below diagram explains the velocity advantage that MS architecture provides. Each of the team Team A, Team B and Team C can go ahead with the modifications without having to worry about the each other's components in the system. Each of the team here is responsible for their component from cradle to grave.

Everybody wants to migrate to MSA but migration doesn't happen overnight. You cannot migrate your complete monolith overnight. There needs to be a strategy in-place like migrating it component by component and while you are migrating there will be situations where you would be in a hybrid architecture supporting, maintaining two different versions of the same software. Even the tech giants like Netflix took 7 years to move it to MSA.

Microservices is a great architecture pattern but don’t adopt just for the sake of adopting. Be aware of your situation and do what works for you. It has its own complexities but if you solve the complexities then the advantages are big. It is a high-risk high-reward gamble.