We all know the microservices architecture, at its core it has a simple idea, breaking down the system into small components so we can have better control of the overall system.
Control often refers to how easy it is to change your code (maintainability) and test your code (testability), but today I want to focus on a different kind of control that this architecture succeeds at – working with a large number of teams.
A developer’s time is one of the most valuable resources for a company, so when the company grows and the number of teams increases, it’s important that the teams will remain as productive as possible. Teams working in a parallel manner becomes a necessity, and the microservices architecture addresses this point.
Parallel developer’s work made easier – by separating the system into independent logical components developers can divide their work in an easier manner, each team can work on a different component (microservice), without conflicting with other teams code.
Parallel deployments made easier – when two teams are working on one codebase and they want to deploy their code to production they have two options: having two deployments one after the other or merging the deployments into one big deployment.
With microservices, teams can deploy their code independently in parallel since they are working on a different codebase. This is a major benefit, one team does not delay the other team and if a bug shows up in production after deployment, it is easier to know what change caused the issue. In addition, rollback is independent as well so there is no need to roll back all the features that being deployed only because one of them had a bug, only the problematic change is being rollbacked.
So what do you think about the microservices architecture?
Share if you like.