Start with a Monolith, break into services when it starts to hurt.
Staying with a Monolith when it's causing you pain is bad.
Starting with Microservices without a good idea of where your pain will be is also bad.
As is usually the case, nuance is what's most important here. Both are great, and bad. Picking the right great, and bad, is totally subjective.
In general, for scale, logically breaking things into small-ish pieces is a great idea. Keeping their data isolated is also a great idea. Communicating between services asynchronously is yet another great idea.
Note that none of the above are owned entirely by the Microservices umbrella. You can do a lot of it without breaking your monolith up at all.
For context, my current situation: We need to rewrite and rearchitect a very large, and old, monolith. Here we already know what hurts from years of development experience, so we start with a good idea of what needs to sit in isolation. We also know that we have really ambitious delivery goals, a very large team of technologists (100+), and need teams and services to be able to work and deploy with as few dependencies as possible.
This is the type of situation the concept of Microservices was created to enable. So, like a cat on the internet, if I fits, I sits.
Start with a Monolith, break into services when it starts to hurt.
Staying with a Monolith when it's causing you pain is bad.
Starting with Microservices without a good idea of where your pain will be is also bad.
As is usually the case, nuance is what's most important here. Both are great, and bad. Picking the right great, and bad, is totally subjective.
In general, for scale, logically breaking things into small-ish pieces is a great idea. Keeping their data isolated is also a great idea. Communicating between services asynchronously is yet another great idea.
Note that none of the above are owned entirely by the Microservices umbrella. You can do a lot of it without breaking your monolith up at all.
For context, my current situation: We need to rewrite and rearchitect a very large, and old, monolith. Here we already know what hurts from years of development experience, so we start with a good idea of what needs to sit in isolation. We also know that we have really ambitious delivery goals, a very large team of technologists (100+), and need teams and services to be able to work and deploy with as few dependencies as possible.
This is the type of situation the concept of Microservices was created to enable. So, like a cat on the internet, if I fits, I sits.
Such applause.
Got nothing to add to the debate. This opinion is better written than mine and covers everything I'd write