3 ms·

> Independent Scalability This reason for microservices comes up over and over but I’ve never understood it. If you scale a monolith, only the hot code paths

> Independent Scalability This reason for microservices comes up over and over but I’ve never understood it. If you scale a monolith, only the hot code paths will use any resources. Having a monolith makes it _easier_ to scale as you can just scale a single app and it will be perfectly utilized. If you have microservices you need to make sure every single one has headroom for increased load. Scaling up a whole monolith only to increase capacity for one code path doesn’t have any unnecessary overhead as far as I can see. Remembering that if your microservice is on a VM then you are scaling up the OS too which has millions of lines of code - something no one (rightly) is concerned about. Am I missing something?

alexnewman 7y ago
back in the day we had a common micro service. it was called pgbouncer. Because database resources are limited it’s nice to have a stable consistent connection limited a set number of processes and then let the application monolith scale independently. Also, when you are scaling across multiple machines you don’t need all of the code of the monolith on every machine. i’ve heard about When amazon switched to a SaaS model, creating aws they were locked into a 32 bit monolith in which code was limited to a few GB and thus scaling resources independent was valuable. Was this useful? I am collecting data on if i’m polite, without snark and helpful.
IneffablePigeon 7y ago
I think you're right that this point is often overstated. It does isolate each service from the scaling _issues_ of the others somewhat - if one service gets overloaded and crashes or hangs then other components are less likely to get brought down with it. In the best case if work is piling onto a queue and the overloaded component can be scaled fast enough even dependent components might not notice too much disruption. Another advantage is that you can scale the hardware in heterogeneous ways - one part of the app may need fast I/O and the rest of the app might not care about disk speed much at all, so you can have different hardware for those components without overspending on the storage for the rest of the app. I think that's a minor advantage in most cases though. A sort of in-between house is to have multiple copies of a monolith which are specialised through load balancing and/or configuration values and put onto different hardware, but all running the same code. Probably not that widely useful a technique but one that we've found useful when running similar long running tasks in both interactive and scheduled contexts.
OJFord 7y ago
Well, the hot path isn't necessarily the good behaviour one you would choose to scale. e.g. login service DoS'd, but logged in users can continue using widget service, rather than it grinding to a halt as the login path heats up and consumes all resources.
Marazan 7y ago
? If you scale a monolith you have to scale the whole thing. You seem to be describing that a monolith is more efficient that a microservice in a non scaling situation, which is true, but I think you have missed the point on scaling.
chungleong 7y ago
You're assuming an app that scales linearly with hardware. That's very hard to engineer. That's in fact the problem we're trying to solve: The hardware's there but the app can't make use of it due to some contention somewhere.

alexnewman 7y ago

back in the day we had a common micro service. it was called pgbouncer. Because database resources are limited it’s nice to have a stable consistent connection limited a set number of processes and then let the application monolith scale independently. Also, when you are scaling across multiple machines you don’t need all of the code of the monolith on every machine. i’ve heard about When amazon switched to a SaaS model, creating aws they were locked into a 32 bit monolith in which code was limited to a few GB and thus scaling resources independent was valuable. Was this useful? I am collecting data on if i’m polite, without snark and helpful.

IneffablePigeon 7y ago

I think you're right that this point is often overstated. It does isolate each service from the scaling _issues_ of the others somewhat - if one service gets overloaded and crashes or hangs then other components are less likely to get brought down with it. In the best case if work is piling onto a queue and the overloaded component can be scaled fast enough even dependent components might not notice too much disruption. Another advantage is that you can scale the hardware in heterogeneous ways - one part of the app may need fast I/O and the rest of the app might not care about disk speed much at all, so you can have different hardware for those components without overspending on the storage for the rest of the app. I think that's a minor advantage in most cases though. A sort of in-between house is to have multiple copies of a monolith which are specialised through load balancing and/or configuration values and put onto different hardware, but all running the same code. Probably not that widely useful a technique but one that we've found useful when running similar long running tasks in both interactive and scheduled contexts.

OJFord 7y ago

Well, the hot path isn't necessarily the good behaviour one you would choose to scale. e.g. login service DoS'd, but logged in users can continue using widget service, rather than it grinding to a halt as the login path heats up and consumes all resources.

Marazan 7y ago

? If you scale a monolith you have to scale the whole thing. You seem to be describing that a monolith is more efficient that a microservice in a non scaling situation, which is true, but I think you have missed the point on scaling.

chungleong 7y ago

You're assuming an app that scales linearly with hardware. That's very hard to engineer. That's in fact the problem we're trying to solve: The hardware's there but the app can't make use of it due to some contention somewhere.