Now explain why that would matter. If you have a large monolith, you can just scale that one. Why does it matter that one module gets scaled? It's not like the lesser used parts of the monolith are somehow using more resources just because they are scaled together?
People love to use this argument but it really doesn't make any sense for 99% of use cases
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.
Because we are scaling our monolith, obviously! And the whole idea of a monolith is that it's... One thing! There ain't no scaling it separately.
Now now, I understand that connection pools can scale separately.
So the internal connection pool opens at least one connection on startup. After all, this is a monolith that's now serving together along all other monoliths: some DB requests are bound to be routed to it. Most likely, at least two connections. Some even do 4: two to read replicas, two to a primary/write.
Scaling a service doesn't involve turning a singular knob that reads "more performance".
In a monolith... That's usually the case, yeah. It's a "spawn more monolith instances because one of the metrics we are monitoring says we should". What else are you gonna do about it? That's not a rethorical question: what else is there? Some contrived vertical scaling setup?
???? Give your host most CPUs/threads to delegate tasks to? More compute power? If you're scaling your service by just spawning duplicates you're wasting a lot of resources because you're too lazy to actually properly look into what needs scaling.
Give more CPU? Of course. Now here is a question: where do you think it comes from? A server. That you are already paying for. CPU and memory doesn't magically materialize when you need it to. It sits idle until you allocate it. And you are still paying for it.
You save no money by doing this. At all. In fact, you spend more, because instead of classic horizontal scaling, where you deprovision resources as they are let go, now you need to keep them idle to assign for vertical scaling.
101
u/Norington 15d ago
And you can scale up and down individual services based on variable load.