> set hard boundaries on responsibilities and accountability while ensuring independent decision-making
This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly.
And all what you're speaking of can be achieved by properly modularizing the code of a monolithic application. And microservices if you want them can be run on a single machine, you don't need "the cloud" or multiple computers in general to run a bunch of REST apps if your single instance is powerful enough.
And for most web apps it is with the currently available hardware.
> This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly.
I'm not sure you got the point. The need to provide interfaces and establish contracts and pledge SLAs is irrelevant and a non-issue. Naturally, your goal is to have a perfect uptime and never break interfaces, just like your goal when working on a monolith is to not add broken code that crashes the service.
The whole point of microservices is that you are entirely free to make any decision regarding the things you own, and your only constraint is the interfaces you provide and consume, and SLAs. From those interfaces inward, you are totally free to make any decision you think is best without having to bother about anyone else's opinions and technical choices and tastes and permissions. You can run one service behind your interface or hundreds. As long as your interfaces are up, you can do whatever you like. That greatly simplifies your problem domain.
> And all what you're speaking of can be achieved by properly modularizing the code of a monolithic application.
No, no you can't. Think about it for a second: can you pick your software stack? Can you pick what dependencies you adopt? Can you rewrite your code in any other language? Etc etc etc. Your hands are tied left and right.
An even more important consideration is being able to release features (and even more importantly roll back) in isolation when the team is ready. The more teams contributing to a monolith, the harder this becomes. I am sure someone here has seen it done with a 10 million line monolith built by 100 geographically distributed teams, but I suspect that is exceedingly rare.
Microservices aren’t a silver bullet for this, of course. They can be part of a winning recipe though.
While picking any stack you want may sound wonderful to the individual developer, it's less so for the company as a whole that has to maintain different languages and frameworks, when that developer moves on and now they have to find or hire someone else to keep that service running.
> While picking any stack you want may sound wonderful to the individual developer, it's less so for the company as a whole that has to maintain different languages and frameworks
This is orthogonal issue.
You can pick any stack, but you don't have to. There still can be general company wide rules about what is acceptable and what is not. It's just that this is informed and enforced by the actual needs (not being too diverse in the technologies deployed), that can change in time independently from contents of any code repository.
Plus you can still make strategic choices here and there, that don't comply with general rules, and have, say 95% of teams working under stricter limits of what's allowed, and this couple of teams with special needs, where you were free to decide otherwise.
> While picking any stack you want may sound wonderful to the individual developer, it's less so for the company as a whole (...)
Nonsense. Each team owns it's services, and they know best what works and doesn't work. It makes no sense to claim organizational inertia as a valid reason to prevent you from picking the best tool for the job.
To add to that, microservices allow you to gradually upgrade services without having to be blocked by the idea of having to go through major rewrites. You just peel off a concern, get it up and running, and direct traffic to it. Done.
This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly.
And all what you're speaking of can be achieved by properly modularizing the code of a monolithic application. And microservices if you want them can be run on a single machine, you don't need "the cloud" or multiple computers in general to run a bunch of REST apps if your single instance is powerful enough.
And for most web apps it is with the currently available hardware.