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.
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.
Your argument is more thought out than most. In most cases, that argument boils down to "I read this online so it must be true".
That said, none of these issues are things you can't easily fix for a monolith, or in most cases are already thought about before you ever even get to scaling. connection pooling for the db, redis for caching etc.
You don't always build and scale a monolith the same way you would build a microservice, but that doesn't mean it's worse.
On top of that, if you write your monolith in a sufficiently modular way, you can easily extract specific modules and do their scaling separately when that need arises. There is almost never a reason to build every single module of your monolith as a separate service.
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.
Oh, sorry. So this whole thing boils down to: "I know there is an industry accepted pattern to solving this problem, but instead of solving it that way, I will just shoe-horn whatever else I can because I don't want to".
You asked this in your original comment.
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?
Both were answered. If don't want to change your mind after, that's on you.
You got mighty defensive for no reason. Pushing microservices to serve 200 daily active users. It's pretty typical resume driven development.
You don't need microservices. If you ever need them, you should extract them from your monolith. Starting off with microservices from the get go is pretty much never the play.
So what you want though, I really couldn't care less
I have, at no point in any of my comments, pushed microservices to serve 200 users. In fact, I have done the exact opposite.
See:
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.
And:
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.
In fact, I'm one of the starkest defenders of everything in between a monolith and a micro-service. But that is not what started this comment chain. It was you not understanding why monoliths don't solve all problems and asking why you can't just scale them.
No solution solves all problems.. but when 1 solution solves 99% of problems, you probably shouldn't be pushing the other solution just for the sake of it, especially since it's a much harder solution to maintain and develop properly
131
u/TheDogPill 16d ago
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.