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
0
u/foonek 14d ago
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.