Other recent blogs
We have been hearing the term “microservices” for the last few years and it has become a buzzword in the field of software architecture design. If you ask software architects that what type of architecture they are working on, most of them will say microservices architecture. The word microservices has become a status symbol for many of the architects. Every architect wants to design their application using microservices without even assessing whether they should use microservices or not. Since microservices architecture is the latest trend, the technology heads and CTOs also want their applications designed using microservices.
Microservices Architecture is broadly termed as a way of designing the software application as a collection of independently deployable services. Though there is no fixed definition of Microservices Architecture but it has characteristics like decentralized control, independently scalable and maintainable, automated deployment, intelligence at the lowest level, easy to enhance. With the advancements in the cloud technologies implementing Microservices has become much easier.
Now the big question comes, whether you should go with Microservices or not?
The answer is, it depends on multiple factors, out of which Domain Complexity, Usage Volume are two most important factors. If usage volume is high i.e. Internet scale and Domain complexity is less then microservices are highly recommended. Similarly, if usage volume is less i.e. enterprise scale and domain complexity is high, going with Modular Monolithic approach makes more sense. These two cases are very much clear but what about the other two cases where usage volume is low and domain complexity is low or usage volume is high and domain complexity is high? In my opinion, we will give the preference to usage volume and will go for microservices if usage volume is above a certain threshold. If we take the example of Netflix where performance takes precedence over all other factors and microservices is inevitable. If you are building a multi-tenant system, which is an Enterprise application but provides as SaaS, having a mix of microservices and modular monolith makes sense.
Another factor that comes in to play is the ability to find out the module/domain boundaries and separating them from each other for loose coupling. Many people ask what should be the size of a microservice in terms of lines of code or effort to be needed to code them or number of tables in the database of a microservice? Once again the answer to this question is also not concrete as it depends on how much you are able to separate the domain models from each other so that they can run as separate services independently. No system can be designed with infinite scalability. You need to follow an evolutionary vision for the architecture, where the system is allowing changes needed in future. For example, you can start with the monolithic modular approach with clearly separated module boundaries, respecting bounded contexts and using domain driven design. After some time when you are able to put all the components in the right place, start converting modules into microservices and once done you can identify certain modules that can be split to more fine-grained microservices. You can follow the single responsibility principle, which says “Gather things together those change for the same reason and separate things that change for different reasons.” Beware to split the system into many microservices as it might increase the chattiness between the application services and hence will introduce latency in the service response. It is always a problem of choosing millions of ants approach VS single elephant approach. I have personally seen some enterprises that followed microservices approach to develop their application and now they are not able to debug why the application is performing poorly. After a thorough audit, it was found that they have implemented excessive chattiness between the APIs and were lacking dependency governance between APIs. Therefore be careful about the granularity of the microservices and finding the right granularity is possible with the evolutionary vision only.
Another complaint I hear from enterprises that have created their applications in the microservices style is they are spending a lot of money on cloud infrastructure because of deployment of every microservice on separate instances. Since every microservice needs its own high availability the number of instances required increases accordingly. Now to bring down the cost of infrastructure they started deploying multiple services on one instance, which once again became difficult to manage in terms of monitoring, debugging, and finding bottlenecks. This can be handled using the DevOps practice. It is a fact that economics plays a very big role in development, operation, and maintenance of any application. You need to do your cost-benefit analysis and then decide your approach.
This article was published in the October 2017 Elite Issue of CIO Review India Magazine (Pg 134).
