3 ms·

Not resource management. Resource efficiency. If you have a monolith, you have less control over the service’s shape—the CPU, RAM, IO footprints. If you break

Not resource management. Resource efficiency. If you have a monolith, you have less control over the service’s shape—the CPU, RAM, IO footprints. If you break it up into smaller microservices, the footprints are smaller and you have more options for how you schedule them. There is a tradeoff here—services that are too small have high overhead. Services that are too large are inefficiently scheduled. Services that are way too large force you to spend money buying the massive machines needed to run them.

jandrewrogers 6y ago
This assertion is making a lot of unwarranted assumptions about the software architecture of a monolith. You can have a monolith and total control over the resources at the scale of an entire machine. This can be extraordinarily resource efficient in a way microservices never are, and is often the default case when designing systems like databases or data infrastructure. A monolith easily achieves 10x throughput of what microservices will do on the same hardware. Which is why people build monoliths, they can be extremely efficient. Microservices are usually about trading resource efficiency for organizational convenience.
- klodolph 6y ago
  It’s “a possible strategy”, and whether the strategy is appropriate depends on the particulars of your service. > A monolith easily achieves 10x throughput of what microservices will do on the same hardware. If we’re gonna talk about unwarranted assumptions, this one takes the cake. I’ve seen services spun up where the resources to run them simply didn’t exist in our data centers. As monoliths, their throughput was effectively zero. The cost tradeoff was “buy bigger servers and wait until they arrive” versus “spend engineering resources and stop buying bigger servers.” Again—this is going to depend on the particulars. The better answer is not necessarily obvious.

jandrewrogers 6y ago

This assertion is making a lot of unwarranted assumptions about the software architecture of a monolith. You can have a monolith and total control over the resources at the scale of an entire machine. This can be extraordinarily resource efficient in a way microservices never are, and is often the default case when designing systems like databases or data infrastructure. A monolith easily achieves 10x throughput of what microservices will do on the same hardware. Which is why people build monoliths, they can be extremely efficient. Microservices are usually about trading resource efficiency for organizational convenience.

klodolph 6y ago
It’s “a possible strategy”, and whether the strategy is appropriate depends on the particulars of your service. > A monolith easily achieves 10x throughput of what microservices will do on the same hardware. If we’re gonna talk about unwarranted assumptions, this one takes the cake. I’ve seen services spun up where the resources to run them simply didn’t exist in our data centers. As monoliths, their throughput was effectively zero. The cost tradeoff was “buy bigger servers and wait until they arrive” versus “spend engineering resources and stop buying bigger servers.” Again—this is going to depend on the particulars. The better answer is not necessarily obvious.