6 ms·

It seems over time some nuance has been lost in translation on this. Microservices weren't 'more scalable' than monoliths, they were 'more appropriately scalabl

It seems over time some nuance has been lost in translation on this. Microservices weren't 'more scalable' than monoliths, they were 'more appropriately scalable'. In other words, you could scale parts independently and shape your infrastructure more effectively for your workload. e.g. If your bottleneck is logins, you scale the LoginService and don't need extra copies of the AppointmentService running to keep up.

aflag 5y ago
Sure, but I think the point is that it's unlikely the bottleneck will be in the web server, but in whatever database you're using for your logins. Just because you have a single program, it doesn't mean it is required to use a single database. But even if the webserver is the problem, it feels unlikely that you'll end up saving much in infrastructure cost by scaling just the login service rather than just deploying more copies of your webserver. Not saying it is impossible, but it's unlikely for that to be a good justification to adopt microservices. I'm not saying that there aren't good reasons to use microservices, but I agree that scalability is not a good selling point. I'd actually argue that it's harder to build scalable microservices than monoliths.
- JamesSwift 5y ago
  Im not arguing for or against (I'm pretty against micro services), I'm just explaining what the arguments are
- darkwater 5y ago
  > Just because you have a single program, it doesn't mean it is required to use a single database. I would challenge that. Obviously a well written "monolith" with well insulated modules, separation of concerns etc can use different databases but I heard too many times when I ask "why can't we shard the database" the answer "the data model is one and it's way easier to develop on one single data model that on N models inside the monolith".
twic 5y ago
Even this premise is fundamentally mistaken. If you have a monolith, and the LoginModule is overloaded, you add more hardware, and it's the LoginModule which makes use of the additional resources. The AppointmentModule isn't going to suddenly start using more resources just because they're available.
- JamesSwift 5y ago
  Not really, the load gets spread out across your nodes so if you go from 1 -> 2 then the new AppointmentModule is handing 50% of the previous load. Thats just CPU. RAM tends to be stickier and you can easily cost yourself a lot more than "needed" to overprovision in this manner.
  - Nextgrid 5y ago
    How/why would the AppointmentModule suddenly start using CPU? Where does it get called from? Unless a web request comes in that requires it, it shouldn't be called at all. If all your incoming requests call the LoginModule, the AppointmentModule shouldn't enter the picture.
    - JamesSwift 5y ago
      The load balancer routes requests to all nodes. So each node will have some load (approximately 50% of the prescale load as I said)

aflag 5y ago

Sure, but I think the point is that it's unlikely the bottleneck will be in the web server, but in whatever database you're using for your logins. Just because you have a single program, it doesn't mean it is required to use a single database. But even if the webserver is the problem, it feels unlikely that you'll end up saving much in infrastructure cost by scaling just the login service rather than just deploying more copies of your webserver. Not saying it is impossible, but it's unlikely for that to be a good justification to adopt microservices. I'm not saying that there aren't good reasons to use microservices, but I agree that scalability is not a good selling point. I'd actually argue that it's harder to build scalable microservices than monoliths.

JamesSwift 5y ago
Im not arguing for or against (I'm pretty against micro services), I'm just explaining what the arguments are
darkwater 5y ago
> Just because you have a single program, it doesn't mean it is required to use a single database. I would challenge that. Obviously a well written "monolith" with well insulated modules, separation of concerns etc can use different databases but I heard too many times when I ask "why can't we shard the database" the answer "the data model is one and it's way easier to develop on one single data model that on N models inside the monolith".

twic 5y ago

Even this premise is fundamentally mistaken. If you have a monolith, and the LoginModule is overloaded, you add more hardware, and it's the LoginModule which makes use of the additional resources. The AppointmentModule isn't going to suddenly start using more resources just because they're available.

JamesSwift 5y ago
Not really, the load gets spread out across your nodes so if you go from 1 -> 2 then the new AppointmentModule is handing 50% of the previous load. Thats just CPU. RAM tends to be stickier and you can easily cost yourself a lot more than "needed" to overprovision in this manner.
- Nextgrid 5y ago
  How/why would the AppointmentModule suddenly start using CPU? Where does it get called from? Unless a web request comes in that requires it, it shouldn't be called at all. If all your incoming requests call the LoginModule, the AppointmentModule shouldn't enter the picture.
  - JamesSwift 5y ago
    The load balancer routes requests to all nodes. So each node will have some load (approximately 50% of the prescale load as I said)