Why should you do microservices (or maybe you shouldn’t)
In this article Aviran Mordo, the head of back-end engineering at Wix, weighs in on the benefits of microservices and debunks some myths about what they can and cannot do.
Microservices architecture is really hyped these days (I should know, I have been talking about it in many conferences), however not many things have been written about the actual reason why microservices should be used in the first place.
In the stories I tell during my public talks, I try to explain that microservices architecture comes to solve a problem, and the main issue it comes to solve is SCALE, but not the scale that you think. Microservices mainly solve engineering scale.
We all know that small teams work faster and better than large teams. The bigger your team, the larger the project; you inevitably end up with a huge monolith and with many people working on the same code base. It becomes very hard to release a version as you need to synchronize the work of many people and package it into a releasable version.
By breaking your monolith into small microservices, you allow the creation of small engineering teams that can release and deploy on their own time with loose coupling between different artifacts and other teams.
Another great benefit is the ability to roll back small changes without affecting other areas in your system. If you have a monolith, it is almost impossible to roll back a bad version because it bundled many features and if one feature is bad you cannot roll it back since you will essentially roll back all the other new features. If you break it to microservices, you decouple these parts and each can deploy and roll back without affecting the entire system.
With microservices you basically increase your development velocity and can scale your engineering teams by giving each team a set of microservices to own.
Another scalability problem is different SLA for different parts of your system. You may have parts of your system that need to be highly performant and highly available running in multiple data centers or zones, while other parts that have a lesser requirement for performance and availability, for instance off-line batch processing.
If you have one monolith, you have to scale the entire system based on your highest SLA, which can be costly.With microservices you can split these services and have different SLA to different parts of your system, thus reducing your operational cost. You can also have different middleware for different parts of your system, thus choosing the best solution to solve different issues.
The third reason for choosing microservices is risk management. If you have a monolith and you have issues with it in production, whether it is a production issue, bad deployment or simply a bug, you can bring your whole system down. The fact that microservices are independent and decoupled means that you only have partial downtime for the affected microservice.
Now don’t get me wrong —microservices represent a great solution but when it comes to solving a problem, there are many other issues and complexities. If you are totally fine with a simple monolith, stick with it, when you feel the (scalability) pains in having a monolith, then microservices can help you solve some of your pains, but be prepared for different pains of running a distributed system.
This post was originally published on Aviran’s Place.