The Mystery Of Microservices

Sushil Kumar Tripathi, AVP - Technology, Kellton Tech Solutions Limited | Friday, 06 October 2017, 12:54 IST

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 to 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 architects. Every architect wants to design his/her applications 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 as microservices.

Micro services 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 every definition has many common 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.

"Gather things together those change for same reason, and separate things that change for different reasons"

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 evolutionary vision for the architecture, where the system is allowing changes needed in future. For example you can start with monolithic modular approach with clearly separated module boundaries, respecting bounded contexts and using domain driven design. After some time when you are able to rightly put all the components in right place, start converting few of these modules in to microservices and once done you can identify certain modules to be split to more fine-grained microservices. You can follow the single responsibility principle, which says “Gather things together those change for same reason, and separate things that change for different reasons”. Beware to split the system in too many microservices as it might increase the chattiness between the application services and hence will introduce latency in 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. There fore be careful about the granularity of the microservices and finding the right granularity is possible with the evolutionary vision only.

Another complaint I here from enterprises those have created their applications in micro services style that 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 becomes difficult to mange in terms monitoring debugging and finding bottlenecks, though having a good devops practice all of this can be handled. It is a fact that economics plays a very big role in development, operation and maintenance of any application, do your cost benefit analysis and then decide your approach.

Don't Miss ( 1-5 of 25 )