SCALING FROM MONOLITH TO MICROSERVICES
The theme of microservices, distributed architecture is becoming more and more discussed by developers And there are some reasons for that.
In this Article I will try to shed some light on the subject. I had chance to work in startups which then grew to companies with few thousand employees. The more customers they had, the more features were requested, the greater product load was, the more people were hired to handle features. After some time It became much harder to maintain it all together and deliver product releases frequently on time. Customers were complaining about application bad performance. So they came up with solution which was a vertical scaling. More powerful server, available to serve more application threads, doing adjustments on db level: procedures tuning, data denormalization, moving to olap (and other DBAs can do their magic), ordering SQL servers.
As a result they had better performance (not the one that customer would be happy with, but much better than it was before). But performance tuning costs hold by the company were still quite high (time spend by dev. teams, licensing for database servers and so on).
In this case the vertical scaling was a quick and easy solution. Quite expensive though.
Plus the need to manage the cooperation between increased numbers of software engineers, working on same product, merging conflicts, framework limitations, common dll dependency and many others.
In this aspect microservices have some strong advantages:
• Each development team works on it’s own set of microservices (product features) which is area of their own responsibility.
• Product delivery timelines are significantly shortened, since instead of deploying the whole product we just deploy microservice or few instead.
• Development teams are independent of framework and tools limitations of each other. They are aligned just with contracts they provide for their microservices and that’s it.
• Development Team becomes more flexible to satisfy business and customer needs.
• Performance wise and failover tolerant it is much easier to deploy microservice or set of microservices on extra server instead of tuning monolith application.
However there are following disadvantages:
The CI process in microservices is more complicated (here where DevOps saves us), infrastructure issues, blocking microservices interaction and issue tracing. It’s quite hard to trace an issue which has passed through the flow of several microservices to identify root cause.
So if you decide to go with microservices. Here are some good practices:
• Do it for single feature, not cross-cutting for the application flow. You will have tons of calls to this ms through over your app. Cross cutting feature is better to have on app level itself.
• Never change contract Extend it if needed, other teams are using it and expecting it be the same.
• Make microservice be immutable. This means that on same call it should respond the same.
• Stateless. Try to avoid the state. Once you have multiple instances running with load balancing, you may avoid tricky bugs here
• Try to avoid storages for microservice, unless you actually need it make it microDb. Each db call is time consuming. You have to store some value, read some value (especially if it is loaded database).
That is all for now, hope you enjoyed my article. Good luck fox.
Team Leader at AllStars-IT Ukraine