This argument always confuses me. It depends on what you’re doing but if you’re doing web services, as most here are, the crash is limited to the request being served.
The blast radius is a single request, right?
In every likelihood it _is_ a separate process on a separate machine.
Re:Death by a Thousand Microservices
by threeseed on Tuesday September 12, 2023 @02:19AM
(#37477453)
They are talking about deployment.
With micro-services if you screw up a deployment the service is down and if your platform is well designed the system will be degraded but not down.
With a monolith the whole system is down.
Re:Death by a Thousand Microservices
by quickthrower2 on Tuesday September 12, 2023 @02:31AM
(#37477521)
There are a lot of deployments options to mitigate that risk.
Re:Death by a Thousand Microservices
by charcircuit on Tuesday September 12, 2023 @02:36AM
(#37477555)
>With a monolith the whole system is down.
No, you are just at reduced capacity.
The moral of the story is not to roll out to 100% right away.
Re:Death by a Thousand Microservices
by threeseed on Tuesday September 12, 2023 @02:46AM
(#37477601)
Monoliths go hand in hand with a centralised database.
Bit hard to do schema evolution with a staggered rollout.
Re:Death by a Thousand Microservices
by charcircuit on Tuesday September 12, 2023 @02:57AM
(#37477650)
The software should be compatible with both the old and new schema until all of your database servers have moved over to the new schema. All rollouts are going to be somewhat staggered even if you go straight to 100%.
If schema migrations take non-zero time and you want zero-downtime deployments, then the both service versions need to be compatible with either the new schema or the old schema, regardless of service size.
Re:Death by a Thousand Microservices
by ownagefool on Tuesday September 12, 2023 @03:53AM
(#37477989)
The same problem exists in microservoce land, only you now have a load of separate teams managing their own database, perhaps with different solutions.
Wait, micro-service and sharing same DB? Did I miss something?
Re:Death by a Thousand Microservices
by ownagefool on Wednesday September 13, 2023 @03:55AM
(#37493557)
I think you misunderstood what I said, which is you still have databases and ergo need to manage migrations and such, only that this now typically falls to the specific teams.
That said, loads of folks do microservices with a shared dB.
> With micro-services if you screw up a deployment the service is down and if your platform is well designed the system will be degraded but not down.
In theory, but when the getUser service is down, your app is probably broken as well.
Even for a web service, imagine a small feature is causing the app to crash to OOM, or too many file handles or something that will take out the whole process and not just the one request.
If you have long running requests (something beside small rest calls like large data transfers) then they're all taken down.
Just keeping things neat doesn't go nearly as far as a separate process on separate machines. Monolith might be better but I don't think it's a situation where you can have it all.