6 ms·

I never got the “scalability” argument of microservices. You can trivially deploy multiple instances of your monolithic web application - chances are you’re alr

I never got the “scalability” argument of microservices. You can trivially deploy multiple instances of your monolithic web application - chances are you’re already doing so by running multiple workers/threads in your application server. Spreading that to other machines is trivial. The real issue is in scaling the data store. Microservices typically work around that problem by each having their own separate database, but nothing prevents your monolith from also talking to different DBs.

baash05 5y ago
Totally.. and adding read replicas in the mix too. Even rails allows you to stipulate the DB each model lives in, in a rather trivial manner.
- pas 5y ago
  And there are DB proxies that can hide this complexity from the application (to a degree).
pas 5y ago
Monolith becomes a problem when it becomes too big to build/test/deploy/debug in a sane fashion. And when you have alternatives, great. But for example game devs don't. Or operating system devs. Though of course these are all active areas of ongoing research (for decades!). If the problem/subject were that easy we would have already solved it and it wouldn't be a hot topic. And since it's likely a nonlinear problem it's hard to map the problem-solution space, hard to get a good mental model for it, so we use the next best thing: stories. We have success stories and parables on what not to do. (And whole conferences dedicated to telling them :))
- marcosdumay 5y ago
  Building, ok, but for testing or debugging microservices aren't really an alternative. Just like scalability, they add no new capability here. The most they can do is adapt better to some set of procedures than a monolith. For deploying they are nothing but a very large hindrance.
  - pas 5y ago
    Is it not better to debug one microservice than the whole monolith? Easy to run locally, easy to reproduce errors, etc. (My last two weeks was working in such an environment hunting a production bug. Debugging it was a pleasure. Clear interfaces, etc. Of course when a small feature requires changing 3-4 microservices the pleasure is definitely less :D) It's much easier to test them in separation also. Deployments are low risk, not much need for coordination with other teams, etc. There are components that have a heavier load, so we run more of those. Not really a big difference compared to simply running a few more monoliths and configuring them to only handle certain requests... but that's already a given here. I don't have strong opinions either way. Teams/companies should do what works for them, and they should spend some time on improving it so they can be more effective. (Because most people/teams/companies have a "good enough" complacency inertia/bias.) And most solutions work in both setups. (Eg. making builds fast requires a divide and conquer strategy anyway. Do you build modules/packages separately and link them in the end? Do you build containers separately? Same thing. Do whatever works.)
    - marcosdumay 5y ago
      > Is it not better to debug one microservice than the whole monolith? As long as your bug is well behaved and decided to keep itself into a single microservice... and you somehow know what microservice it is, then yes, it's much easier.
Tehnix 5y ago
It's in fact exactly in Horizontal scalability that it becomes important to have control over exactly what resources you need to scale :) Let's take a typical monolith. You'll be serving endpoints that: - Are CPU intensive - Are memory intensive - Are I/O intensive They are almost always heavy on some part, but not all. And definitely they are not uniformly all relying on the same amount of resources. Now, you scale out horizontally, adding instances of the same size because each of these monolithic instances need to be capable of serving the entire domain without impacting tail latencies. Some part of your application becoming more resource intensive? You'll be bumping up the sizes of the entire monolith because you are essentially needing to do the equivalent of provisioning for peak load. Contrast this with microservices (which I'm not arguing are a silver bullet), you can run your memory intensive part of memory optimized instances, and run your compute intensive parts on compute optimized instances. That's the part about scalability. Now, the more interesting part (for me, personally) is reliability. You are decreasing your blast radius of a bad component/thread/process taking down your entire monolith service, and instead compartmentalizing it into limited subparts of your entire API or application. Finally, as you mentioned, microservices do help guide you towards better choices when it comes to structuring your data. You can do this with monoliths as well (and should), but it doesn't come naturally, and having a single data store is the main reason I see teams run into scalability issues :) --- Addition: Some thing I don't see many people talk about is the ability to address tech-debt in Microservices. My experience has been that it is an enormous benefit to have made you domain smaller for when it comes to making changes that require sweeping across the whole codebase. Examples include upgrading language versions (e.g. Scala 2 -> 3, Haskell 8.10 -> 9.2), upgrading frameworks, introducing stricter compilation checks (e.g. TypeScript and strict: true). These easily end up being either insurmountable or year-long projects in a monolith, where it's very hard to incrementally benefit from the work because they are often by nature all or nothing changes.

baash05 5y ago

Totally.. and adding read replicas in the mix too. Even rails allows you to stipulate the DB each model lives in, in a rather trivial manner.

pas 5y ago
And there are DB proxies that can hide this complexity from the application (to a degree).

pas 5y ago

Monolith becomes a problem when it becomes too big to build/test/deploy/debug in a sane fashion. And when you have alternatives, great. But for example game devs don't. Or operating system devs. Though of course these are all active areas of ongoing research (for decades!). If the problem/subject were that easy we would have already solved it and it wouldn't be a hot topic. And since it's likely a nonlinear problem it's hard to map the problem-solution space, hard to get a good mental model for it, so we use the next best thing: stories. We have success stories and parables on what not to do. (And whole conferences dedicated to telling them :))

marcosdumay 5y ago
Building, ok, but for testing or debugging microservices aren't really an alternative. Just like scalability, they add no new capability here. The most they can do is adapt better to some set of procedures than a monolith. For deploying they are nothing but a very large hindrance.
- pas 5y ago
  Is it not better to debug one microservice than the whole monolith? Easy to run locally, easy to reproduce errors, etc. (My last two weeks was working in such an environment hunting a production bug. Debugging it was a pleasure. Clear interfaces, etc. Of course when a small feature requires changing 3-4 microservices the pleasure is definitely less :D) It's much easier to test them in separation also. Deployments are low risk, not much need for coordination with other teams, etc. There are components that have a heavier load, so we run more of those. Not really a big difference compared to simply running a few more monoliths and configuring them to only handle certain requests... but that's already a given here. I don't have strong opinions either way. Teams/companies should do what works for them, and they should spend some time on improving it so they can be more effective. (Because most people/teams/companies have a "good enough" complacency inertia/bias.) And most solutions work in both setups. (Eg. making builds fast requires a divide and conquer strategy anyway. Do you build modules/packages separately and link them in the end? Do you build containers separately? Same thing. Do whatever works.)
  - marcosdumay 5y ago
    > Is it not better to debug one microservice than the whole monolith? As long as your bug is well behaved and decided to keep itself into a single microservice... and you somehow know what microservice it is, then yes, it's much easier.

Tehnix 5y ago

It's in fact exactly in Horizontal scalability that it becomes important to have control over exactly what resources you need to scale :) Let's take a typical monolith. You'll be serving endpoints that: - Are CPU intensive - Are memory intensive - Are I/O intensive They are almost always heavy on some part, but not all. And definitely they are not uniformly all relying on the same amount of resources. Now, you scale out horizontally, adding instances of the same size because each of these monolithic instances need to be capable of serving the entire domain without impacting tail latencies. Some part of your application becoming more resource intensive? You'll be bumping up the sizes of the entire monolith because you are essentially needing to do the equivalent of provisioning for peak load. Contrast this with microservices (which I'm not arguing are a silver bullet), you can run your memory intensive part of memory optimized instances, and run your compute intensive parts on compute optimized instances. That's the part about scalability. Now, the more interesting part (for me, personally) is reliability. You are decreasing your blast radius of a bad component/thread/process taking down your entire monolith service, and instead compartmentalizing it into limited subparts of your entire API or application. Finally, as you mentioned, microservices do help guide you towards better choices when it comes to structuring your data. You can do this with monoliths as well (and should), but it doesn't come naturally, and having a single data store is the main reason I see teams run into scalability issues :) --- Addition: Some thing I don't see many people talk about is the ability to address tech-debt in Microservices. My experience has been that it is an enormous benefit to have made you domain smaller for when it comes to making changes that require sweeping across the whole codebase. Examples include upgrading language versions (e.g. Scala 2 -> 3, Haskell 8.10 -> 9.2), upgrading frameworks, introducing stricter compilation checks (e.g. TypeScript and strict: true). These easily end up being either insurmountable or year-long projects in a monolith, where it's very hard to incrementally benefit from the work because they are often by nature all or nothing changes.