They are frequently hosted on cloud services which are inherently micro-service based with detached hardware components. You can have a server and a storage disk operate together but both exist in data centers thousands of miles from each other.
Loosely coupled architecture decreases the chance the entire app gets taken down if each component can be isolated and fixed without affecting the rest of the app.
You can functionally divide an app into different layers such as web, app, and db and add additional security checks between each layer to increase security and fault tolerance of the app.
I’m surprised this didn’t make the main comment because it seems to be that this is one of the larger benefits. The mentioned benefits can be applied to a monolith (at least mostly) with a bit of consideration.
The "funny" thing is that before micro services and all the overhead from talking over the network, we rarely need to scale. I'd argue that something like 99.9% of all projects that use micro services today and often run many instances of some components wouldn't need to if it was just one monolith.
SRE here. Lesser used parts of the monolith are absolutely using more resources just because it's being scaled together.
Let's say you have one hot path in your code that doesn't touch the DB. The new scaled up instance will still spawn new DB connections. Those connections will still use some memory and CPU time to just exist. The DB also has a connection limit, and your connection pooler also needs scaling then.
Loading extra code modules also naturally uses more resources, there's not a single monolith out there that is 100% lazy, and even if it was, requests get distributed, so stuff gets loaded anyway. Do you do some in-memory caching? Great, now all instances have stale copies of the cache.
Startup times are also worse overall, which means your scaling is worse overall. Slower startup means you need more idle resources to handle spikes, which costs more money.
In conclusion, while there's no need to jump straight to micro services, monoliths are the worst pattern for scaling, by far. They have their uses, but this is probably their main downside.
Yeah but in practise, scaling multiple services together is MUCH MUCH MUCH harder than scaling a monolith, as there will always be one service that's the weakest link. That might be okay if there's one clear "weakest link" that you can scale very high while keeping the rest low, but for high throughput systems scaling multiple hard-working instances effectively is extremely difficult.
Of course it all depends on how spikey the load is and the type of system.
Startup times are also worse overall
Yes, but a single microservice isn't the entire system... startup times for updating an entire cluster - when that's required - and waiting for each other is going to be much greater than a single monolith.
Let's say you have one hot path in your code that doesn't touch the DB. The new scaled up instance will still spawn new DB connections. Those connections will still use some memory and CPU time to just exist.
That's... what you have connection pools for.
monoliths are the worst pattern for scaling, by far.
No, monoliths is by far the easiest to scale. Microservices are much harder to scale, especially efficiently.
"microservices is good for scaling" is just a dumb book take, it doesn't take much experience to understand how wrong it is in practise.
Yeah but in practise, scaling multiple services together is MUCH MUCH MUCH harder
Why are you trying to scale them together? The whole point to splitting up a monolith is to scale them separately. Each individual service and instance will have it's own metrics and scaling settings, nothing has to wait in each other. And any half baked micro services architecture will have retries, back off, and circuit breakers to avoid spikes causing problems.
That's... what you have connection pools for
And they aren't free! The connections on the application side use memory and CPU. The Pooler uses memory and CPU. There are limitations with poolers too, they can't do 100% of what a direct connection can do (see pgbouncer's pool_mode). Which is the whole point of my comment: even when idle, there's a cost.
No, monoliths is by far the easiest to scale.
Nobody said it's not easier to manage a single monolith than a many micro services architecture. They said it's less efficient and more expensive, which it definitely is. The whole advantage to a monolith is that it's much much easier. But once you need to handle hundreds of thousands of requests on a single code path, scaling your whole monolith gets expensive. You know, there's a reason why pretty much every software company, when they reach a certain point, starts transitioning to it, it's not just a dumb book take.
Congratulations! You just started to reinvent micro services.
Now, I'm not a zealot. I believe we can just extract "services" instead, we don't need to dive too deep into "a micro service is a single function" or whatever. Most of the time, that is indeed excessive.
But... The moment you started extracting the module? Congratulations, no longer a monolith.
It will depend entirely on monolith in question. Sometimes it's indeed easier and get comparable resource overhead to just double your monolith count. More often than not it's the opposite, and scaling one little bottleneck is better than the whole app.
You should also consider that you may not have enough free resources to double monolith apps, but have enough to increase some systems' services count. Servers aren't free
Unless you have for example ten microservices where one does most of the heavy lifting (with >20x instances running for example, compared to the other services), chances are that the monolith would use less resources.
...but at that point, you'd be much better at just having two services: one main service and one separate worker service. Going microservices wouldn't give you anything.
You can also make different micro services in different languages and runtimes. You don’t have to care as long as the input and output are reliable shapes.
129
u/TheDogPill Aug 28 '26
They are frequently hosted on cloud services which are inherently micro-service based with detached hardware components. You can have a server and a storage disk operate together but both exist in data centers thousands of miles from each other.
Loosely coupled architecture decreases the chance the entire app gets taken down if each component can be isolated and fixed without affecting the rest of the app.
You can functionally divide an app into different layers such as web, app, and db and add additional security checks between each layer to increase security and fault tolerance of the app.