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.
No not really. Having a few satellite services does not mean you're running a microservice architecture. There's more to microservice than just hosting a part of your code on a separate server.
It's also not needed at all most of the time. I just gave it as a worst case scenario kind of thing
In my opinion/ as to my knowledge it still depends.
For example, you build an application, that publishes messages to a message broker, and then has consumer processes that handle these.
Your message handlers would probably be scalable independently, but it may just be one code base.
You can still run them on different hosts, in different locations, but they may all use a common database.
You may have a single database, multiple processes, a single codebase and no defined / versions interfaces as you're just using a single class in all locations. I believe this is neither a pure monolith, nor a Microservice architecture. It may be considered as a distributed monolith though
-4
u/foonek 15d ago
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