3 ms·

You need multiple services whenever the scaling requirements of two components of your system are significantly different. That's pretty much it. These are ofte

You need multiple services whenever the scaling requirements of two components of your system are significantly different. That's pretty much it. These are often called micro services, but they don't have to actually be "micro"

twodave 11mo ago
I came here to say the same. If you’re arguing either for or against microservices you’re probably not thinking about the problem correctly. Running one big service may make sense if your resource needs are pretty uniform. Even if they’re not you need to weight the cost of adding complexity vs the cost of scaling some things prematurely or unnecessarily. Often this is an acceptable precursor to splitting up a process.
- Nextgrid 11mo ago
  You can still horizontally scale a monolith and distribute requests equally or route certain requests to certain instances; the only downside is that those instances would technically waste a few hundred MBs of RAM holding code for endpoints they will never serve; however RAM is cheap compared to the labor cost of a microservices environment.
  - rockemsockem 11mo ago
    For those numbers, yeah you should absolutely do that. But you might want to host your database on different machines than your application because the numbers will likely differ by much more than a few hundred MBs.
roncesvalles 11mo ago
That's the most nonsensical reason to adopt microservices imo. Consider this: every API call (or function call) in your application has different scaling requirements. Every LOC in your application has different scaling requirements. What difference does it make whether you scale it all "together" as a monolith or separately? One step further, I'd argue it's better to scale everything together because the total breathing room available to any one function experiencing unusual load is higher than if you deployed everything separately. Not to mention intra- and inter-process comm being much cheaper than network calls. The "correct" reasons for going microservices are exclusively human -- walling off too much complexity for one person or one team to grapple with. Some hypothetical big brain alien species would draw the line between microservices at completely different levels of complexity.
- venturecruelty 11mo ago
  At this point, I'm convinced that too many people simply haven't built software in a way that isn't super Kubernetes-ified, so they don't know that it's possible. This is the field where developers think 32 GB of RAM isn't enough in their laptop, when we went to the moon with like... 4K. There is no historical or cultural memory in software anymore, so people graduate not understanding that you can actually handle 10,000 connections per second now on a five-year-old server.
  - Nextgrid 11mo ago
    Many developers started their career during the ZIRP era where none of the typical constraints of "engineering" (cost control, etc) actually applied and complexity & high cloud bills were seen as a good thing, so no wonder.
    - rockemsockem 11mo ago
      Splitting up responsibilities into separate services should in fact primarily be done to reduce costs.
  - lijok 11mo ago
    You’re focusing on the theoretical and ignoring cost. That’s incompetent engineering.
  - deleted 11mo ago
    [deleted]
  - rockemsockem 11mo ago
    There is in fact software that consumes large amounts of resources for fundamental reasons that saves real dollars when it is split into different units for the purpose of scaling those units independently. Most of that software is not primarily dealing with the number of connections it has.
- rockemsockem 11mo ago
  What are you talking about. When people talk about scaling requirements they are not referring to minutiae like "this function needs X CPU per request and this other function needs Y CPU per request", they are talking about whether particular endpoints are primarily constrained by different things (i.e. CPU vs memory vs disk). This is important because if I need to scale up machines for one endpoint that requires X CPU but the same service has another endpoint requiring Y memory whereas my original service only needs Z memory and Y is significantly larger than Z then suddenly you have to pay a bunch of extra money to scale up your CPU-bound endpoint because you are co-hosting it with a memory-bound endpoint. If all your endpoints just do some different logic and all hit a few redis endpoints, run a few postgres queries, and assemble results then keep them all together!!! EDIT: my original post even included the phrase "significantly different" to describe when you should split a service!!! It's like you decided to have an argument with someone else you've met in your life, but directed it at me
zmmmmm 11mo ago
It has other advantages. Operationally, it is very nice to be able to update one discrete function on its own in a patch cycle. You can try to persuade yourself you will pull it off with a modular monolith but the physical isolation of separate services provides guarantees that no amount of testing / review / good intentions can. However, it's equally an argument for SOA as it is for microservices.
- rockemsockem 11mo ago
  There are some other benefits like having different release cycles for core infrastructure that must never go down vs a service that greatly benefits from a fast pace of iteration. Literally one function per service though is certainly overkill though unless you're pretty small and trying to avoid managing any servers for your application.
siliconwrath 11mo ago
Another case I’ve seen is to separate a specific part of the system which has regulatory or compliance requirements that might be challenging to support for the rest of the larger system, eg HIPAA compliance, PCI compliance, etc. (To clarify, I’m not disagreeing with you!)
- rockemsockem 11mo ago
  Good point, I was primarily thinking of engineering reasons, but alas there are indeed other concerns.

twodave 11mo ago

I came here to say the same. If you’re arguing either for or against microservices you’re probably not thinking about the problem correctly. Running one big service may make sense if your resource needs are pretty uniform. Even if they’re not you need to weight the cost of adding complexity vs the cost of scaling some things prematurely or unnecessarily. Often this is an acceptable precursor to splitting up a process.

Nextgrid 11mo ago
You can still horizontally scale a monolith and distribute requests equally or route certain requests to certain instances; the only downside is that those instances would technically waste a few hundred MBs of RAM holding code for endpoints they will never serve; however RAM is cheap compared to the labor cost of a microservices environment.
- rockemsockem 11mo ago
  For those numbers, yeah you should absolutely do that. But you might want to host your database on different machines than your application because the numbers will likely differ by much more than a few hundred MBs.

roncesvalles 11mo ago

That's the most nonsensical reason to adopt microservices imo. Consider this: every API call (or function call) in your application has different scaling requirements. Every LOC in your application has different scaling requirements. What difference does it make whether you scale it all "together" as a monolith or separately? One step further, I'd argue it's better to scale everything together because the total breathing room available to any one function experiencing unusual load is higher than if you deployed everything separately. Not to mention intra- and inter-process comm being much cheaper than network calls. The "correct" reasons for going microservices are exclusively human -- walling off too much complexity for one person or one team to grapple with. Some hypothetical big brain alien species would draw the line between microservices at completely different levels of complexity.

venturecruelty 11mo ago
At this point, I'm convinced that too many people simply haven't built software in a way that isn't super Kubernetes-ified, so they don't know that it's possible. This is the field where developers think 32 GB of RAM isn't enough in their laptop, when we went to the moon with like... 4K. There is no historical or cultural memory in software anymore, so people graduate not understanding that you can actually handle 10,000 connections per second now on a five-year-old server.
- Nextgrid 11mo ago
  Many developers started their career during the ZIRP era where none of the typical constraints of "engineering" (cost control, etc) actually applied and complexity & high cloud bills were seen as a good thing, so no wonder.
  - rockemsockem 11mo ago
    Splitting up responsibilities into separate services should in fact primarily be done to reduce costs.
- lijok 11mo ago
  You’re focusing on the theoretical and ignoring cost. That’s incompetent engineering.
- deleted 11mo ago
  [deleted]
- rockemsockem 11mo ago
  There is in fact software that consumes large amounts of resources for fundamental reasons that saves real dollars when it is split into different units for the purpose of scaling those units independently. Most of that software is not primarily dealing with the number of connections it has.
rockemsockem 11mo ago
What are you talking about. When people talk about scaling requirements they are not referring to minutiae like "this function needs X CPU per request and this other function needs Y CPU per request", they are talking about whether particular endpoints are primarily constrained by different things (i.e. CPU vs memory vs disk). This is important because if I need to scale up machines for one endpoint that requires X CPU but the same service has another endpoint requiring Y memory whereas my original service only needs Z memory and Y is significantly larger than Z then suddenly you have to pay a bunch of extra money to scale up your CPU-bound endpoint because you are co-hosting it with a memory-bound endpoint. If all your endpoints just do some different logic and all hit a few redis endpoints, run a few postgres queries, and assemble results then keep them all together!!! EDIT: my original post even included the phrase "significantly different" to describe when you should split a service!!! It's like you decided to have an argument with someone else you've met in your life, but directed it at me

zmmmmm 11mo ago

It has other advantages. Operationally, it is very nice to be able to update one discrete function on its own in a patch cycle. You can try to persuade yourself you will pull it off with a modular monolith but the physical isolation of separate services provides guarantees that no amount of testing / review / good intentions can. However, it's equally an argument for SOA as it is for microservices.

rockemsockem 11mo ago
There are some other benefits like having different release cycles for core infrastructure that must never go down vs a service that greatly benefits from a fast pace of iteration. Literally one function per service though is certainly overkill though unless you're pretty small and trying to avoid managing any servers for your application.

siliconwrath 11mo ago

Another case I’ve seen is to separate a specific part of the system which has regulatory or compliance requirements that might be challenging to support for the rest of the larger system, eg HIPAA compliance, PCI compliance, etc. (To clarify, I’m not disagreeing with you!)

rockemsockem 11mo ago
Good point, I was primarily thinking of engineering reasons, but alas there are indeed other concerns.