1. Company starts out with a monolith. The monolith is badly managed, the code isn’t modular, the tests are poorly written and take forever to run. Everyone thinks the solution is microservices.
2. Huge effort to break up the monolith that takes years and never really ends.
3. Everyone thinks, Well since it took so long to break up the previous monolith, next time we need to add new functionality, let’s just put it in a microservice to begin with to “save time.” Bonus points for promotions being way easier to achieve when you can say you built a new service.
4. Often the abstractions and boundaries between the new microservices are poor (because, as you pointed out, no one can predict the future)
4a. Also, sometimes the migrations from a monolith to a collection of services don’t fully complete because of priority shifts!
5. Small refactors that would be have been completely trivial in a monolith now take weeks or are just impossible. Teams move super slowly. Teams use complicated distributed systems patterns to achieve goals that would be trivial with simple, readable code in a monolith. Unit tests become integration tests. Instead of being able to manually test a change by spinning up a simple monolith in your laptop or in a cloud dev env, you now need to spin up dev/staging versions of multiple services to test changes. Staging becomes unstable.
6. As a bonus, the operational load becomes higher with every service, debugging becomes more difficult, etc. And God help you if you work at a company with multiple backend languages and you end up with functionality that should be all in one service spread across multiple microservices with poorly-defined domain models and boundaries, each of which is in a different language.
I’ve seen this happen at multiple jobs and it is really sad.
This DHH article from 2016 made me question the wisdom of microservices a long time ago. I wish I had pushed back harder against them in multiple situations: https://signalvnoise.com/svn3/the-majestic-monolith/
I’ve seen this problem in every job I’ve had:
1. Company starts out with a monolith. The monolith is badly managed, the code isn’t modular, the tests are poorly written and take forever to run. Everyone thinks the solution is microservices.
2. Huge effort to break up the monolith that takes years and never really ends.
3. Everyone thinks, Well since it took so long to break up the previous monolith, next time we need to add new functionality, let’s just put it in a microservice to begin with to “save time.” Bonus points for promotions being way easier to achieve when you can say you built a new service.
4. Often the abstractions and boundaries between the new microservices are poor (because, as you pointed out, no one can predict the future)
4a. Also, sometimes the migrations from a monolith to a collection of services don’t fully complete because of priority shifts!
5. Small refactors that would be have been completely trivial in a monolith now take weeks or are just impossible. Teams move super slowly. Teams use complicated distributed systems patterns to achieve goals that would be trivial with simple, readable code in a monolith. Unit tests become integration tests. Instead of being able to manually test a change by spinning up a simple monolith in your laptop or in a cloud dev env, you now need to spin up dev/staging versions of multiple services to test changes. Staging becomes unstable.
6. As a bonus, the operational load becomes higher with every service, debugging becomes more difficult, etc. And God help you if you work at a company with multiple backend languages and you end up with functionality that should be all in one service spread across multiple microservices with poorly-defined domain models and boundaries, each of which is in a different language.
I’ve seen this happen at multiple jobs and it is really sad.
This DHH article from 2016 made me question the wisdom of microservices a long time ago. I wish I had pushed back harder against them in multiple situations: https://signalvnoise.com/svn3/the-majestic-monolith/
this comment is so gold, it should be considered part 3 of the series