1. Independent releases 2. Easier for on-boarding new engineers 3. Scale micro-services independently
The rest of the article is about how to use the breakout opportunity to make major changes to the code and the data-structure. The goal is for the users of the service to have an aha moment of "Search is so much faster after the breakout!".
There is common release process, but with proper infra in place, that shouldn't be a problem.
Suppose you'd like to push code change to production for your monolith - how do you know that someone else's change 1) is ready to to production together with yours 2) does not affect your module. Typically these can't be answered easily - and so release process is converted to manual testing and scheduled (and often slow) releases.
- Multiple execution environments
- Complexity in communication between services
- Managing the versioning of each service and it's dependent services.
Although services are easily to scale and change independently, they are hard to reconfigure globally, which means the application as a whole is hard to change...
Often switching to microservices means reducing the complexity of communication between teams at the expense of increasing the complexity of communication between services.
If each team are given their own microservice to manage the way they choose, things can work smoothly.
But if those things are constantly in flux, it really isn't a good candidate for splitting into a microservice in the first place.
Otherwise it's probably the opposite, takes a lot longer for new engineers to understand the full system. Perhaps even reduces the bus factor, since less people understand all the moving parts.
But search/merchandising is a small fraction of the team. We have 2 dedicated backend engineers on the search team.
We are growing rapidly. We are aiming to double the size of the eng org in the next 8 months.