Going from a monolith to microservices has some advantages, but it violently shifts the company in terms of what becomes the focus, and requires an entirely new set of expertises that they may not be prepared for. And you don’t mention it at all. This is why you don’t sound honest, you only mention the good parts and none of the extremely difficult parts.

If you have an existing monolith, you only care about keeping the monolith up. Every time you split out a new service, you need to worry about keeping that single service up, in addition to every other service. This requires expertise in devops, distributed computing, etc, that may not currently exist with the company. So now, instead of worrying about adding new features, they need to worry about keeping the entire company up and running. It’s not as easy as saying “Just stick it on AWS.” Because a company that currently has a monolith may go completely down when 1 out of 10 services go down, which will affect all their customers. They need to worry about HAProxy, data consistency, etc, which is something that didn’t exist before.

This nirvana of “no code changes” requires strict version control, which is also something the company may not be prepared for. And what if an upstream customer doesn’t want to change versions? Your service is stuck maintaining 2+ versions of an API in production, which now turns into a nightmare.

What about deployment? What about security? What about coordinating between different groups when they plan a huge migration?

The article has a lot to be desired.