6 ms·

Scalability and stability. You need to process more requests? Launch more virtual machines, easy. Your microservice is a shit and it crashes every second? Don't

Scalability and stability. You need to process more requests? Launch more virtual machines, easy. Your microservice is a shit and it crashes every second? Don't care, it will be relaunched automatically.

esailija 4y ago
Every single endpoint in a monolith can be deployed and scaled independently. In a single such deployment the rest of the endpoints are just dead code not costing anything except larger image. Also in many cases work should not be performed synchronously in response to http requests but in a background queue to keep your service robust and responsive. When taking a new order you should just place it in some queue and respond ASAP so there is zero chance you miss a customer order because of some error. In that case there is no difference in scaling a monolith or microservice as you can indepedently deploy 25 consumers for module X events or 10 consumers for module Y events and so on.
nicolaslem 4y ago
Monoliths can also scale horizontally and be restarted automatically when they fail. No need for microservices for that.
- thatwasunusual 4y ago
  > Monoliths can also scale horizontally At a (potentially much) bigger cost.
  - speed_spread 4y ago
    Running costs or development costs? If you have a low-request / high complexity persistent application you may want to optimize for maintainability. Having all the code in one place _can_ make things easier to figure out in the long term.
    - 0x445442 4y ago
      Also there’s configuration management costs to consider, which usually ends up being a biggie.
    - JAlexoid 4y ago
      > maintainability Sir this is HN, half of the people here will quit their team well before maintainability is even uttered.
      - speed_spread 4y ago
        In the words of a friend and former colleague: "shit fast, shit hard, and then leave"
    - thatwasunusual 4y ago
      > Running costs Running costs. > Having all the code in one place _can_ make things easier to figure out in the long term. My experience is the exact opposite. A huge monolith makes it harder for developers - especially new ones - to get a grasp of how everything is connected. A separation of concern into micro services is sometimes a good solution.
  - dagss 4y ago
    You mean the few extra megabytes of RAM for some extra compiled code on each node? If you refer to databases: Splitting one service into two services can at most give you a 2x scale-up potential (usually a lot less), and the effect diminishes for 3th, 4th service. Mathematically and logically. Splitting services = vertical scaling. If you want 100x, 1000x scaling you need to invest in true horizontal scaling anyway, and that works pretty much the same way for monoliths as microservices.
    - thatwasunusual 4y ago
      > You mean the few extra megabytes of RAM for some extra compiled code on each node? Few extra? Have you not considered applications where you need to spin up/down _extremely_ resource intensive instances? A year++ ago I worked on a health-related application which used a system for processing X-ray images. During typical work hour (6 am-6 pm) it required a _huge_ amount of CPU and RAM instances. By shifting those specific services out to specialised instanced, we saw a $50K/month saving. The rest of the application is a lot more lightweight, but of course has to run 24/7, but being able to spin up/down required instances, and just pay for what you use, is a huge benefit for a lot of companies and organisations.
      - nicolaslem 4y ago
        A monolith is not a giant blob that has to run fully on one instance or else nothing works. Although I'm sure plenty of horrible enterprise software works that way, it is not a property of a monolith. I maintain a SaaS written as a monolith and I can absolutely spin instances that only load one part of the code and do a single thing, for example some instances only handle MQTT messages while others only serve HTTP endpoints. That does not make it microservices, it is all one code base sharing one database.
  - roflyear 4y ago
    Overhead is way worse with microservices once you talk about network latency, database cost, infra for logging and monitoring, labor to manage that, and developer cost. Way, way, way, more than spinning up ten more identical webapps.
  - NorwegianDude 4y ago
    Could just as well be at no additional cost. If your monolith separates services somewhat cleanly then you can run them on every node and not even touch the part of the codebase that's not related to the current task.
    - thatwasunusual 4y ago
      I wasn't talking about the cost of touching the codebase, but rather running a monolith horizontally with an overhead in terms of CPU-, disk- and RAM-usage. For big companies it might me a miniscule difference, but for smaller companies it can be a deal-breaker.
- jason-phillips 4y ago
  Having worked in both, I'll never work on a true monolith again.
  - faeyanpiraat 4y ago
    Why?
    - KyeRussell 4y ago
      Because almost nobody has ever worked on a true monolith. It’s just “services abstractions people are comfortable with” and “everything else”.
quonn 4y ago
We learned in the 90s to not distribute the objects and instead just spin up more copied of the whole application. And if only scalability is the point this is still valid.
- marcosdumay 4y ago
  It's not much that we learned it at the 90's. It's that it became true at around the 90's. It used to be false, but computers became faster, memory more plentiful, and the fundamental physical limitations of networks didn't change a bit (well, fundamental physical limitations never do). It has become more and more true each passing year.
- jameshart 4y ago
  Weird flex to claim not to have learned anything new since the nineties though.
  - quonn 4y ago
    Where did I say this? All I said is that it's usually effective to spin up more instances of the system - a conclusion we arrived at long ago. Regarding your point, most other disciplines gain knowledge over time, such as civil engineering, chemistry or biology and we don't discard results from the past with this kind of strawman argument of there supposedly not being anything to learn since. If things were like that, any progress would be impossible.
  - dahfizz 4y ago
    And Calculus was invented 300 years ago. It still works. This attitude is extremely toxic to the development community. "Its old" is NOT valid criticism. "Its new" is NOT valid praise.
  - JAlexoid 4y ago
    What I learned since the 90ies, is that software engineers don't learn from previous years... let alone from previous decades. This "microservices are better" argument was made in the 90ies and top dog is still Linux kernel (the one that was on the monolith side of that debate). So yeah - microservice advocates haven't learned anything since the 90ies, or from the SOA era, etc... (but I suspect they were in secondary/high school then) An anecdote: When I joined my current company had more code to orchestrate services, than the actual business value generating code in the services. We still produce an inordinate amount of code that exists just to facilitate microservice architecture. (it's also untested code, because we just don't have the money to spend time on testing it)
keewee7 4y ago
>Your X is a shit and it crashes every second? Companies that repeatedly fail to detect and solve this type of problem using automated testing and QA are exactly the companies that lack the sophistication to do distributed microservice architecture. Learn to do proper CI/CD, end-to-end testing, and logging/metrics on your monolith before you decide to transition to microservices.
- jeffbee 4y ago
  Disagree. At well-run companies with highly available services that you have certainly heard of I have routinely discovered microservice backends that are just crashing all over the place with no consequences to the user whatsoever. You can never say that about crashy monoliths.

esailija 4y ago

Every single endpoint in a monolith can be deployed and scaled independently. In a single such deployment the rest of the endpoints are just dead code not costing anything except larger image. Also in many cases work should not be performed synchronously in response to http requests but in a background queue to keep your service robust and responsive. When taking a new order you should just place it in some queue and respond ASAP so there is zero chance you miss a customer order because of some error. In that case there is no difference in scaling a monolith or microservice as you can indepedently deploy 25 consumers for module X events or 10 consumers for module Y events and so on.

nicolaslem 4y ago

Monoliths can also scale horizontally and be restarted automatically when they fail. No need for microservices for that.

thatwasunusual 4y ago
> Monoliths can also scale horizontally At a (potentially much) bigger cost.
- speed_spread 4y ago
  Running costs or development costs? If you have a low-request / high complexity persistent application you may want to optimize for maintainability. Having all the code in one place _can_ make things easier to figure out in the long term.
  - 0x445442 4y ago
    Also there’s configuration management costs to consider, which usually ends up being a biggie.
  - JAlexoid 4y ago
    > maintainability Sir this is HN, half of the people here will quit their team well before maintainability is even uttered.
    - speed_spread 4y ago
      In the words of a friend and former colleague: "shit fast, shit hard, and then leave"
  - thatwasunusual 4y ago
    > Running costs Running costs. > Having all the code in one place _can_ make things easier to figure out in the long term. My experience is the exact opposite. A huge monolith makes it harder for developers - especially new ones - to get a grasp of how everything is connected. A separation of concern into micro services is sometimes a good solution.
- dagss 4y ago
  You mean the few extra megabytes of RAM for some extra compiled code on each node? If you refer to databases: Splitting one service into two services can at most give you a 2x scale-up potential (usually a lot less), and the effect diminishes for 3th, 4th service. Mathematically and logically. Splitting services = vertical scaling. If you want 100x, 1000x scaling you need to invest in true horizontal scaling anyway, and that works pretty much the same way for monoliths as microservices.
  - thatwasunusual 4y ago
    > You mean the few extra megabytes of RAM for some extra compiled code on each node? Few extra? Have you not considered applications where you need to spin up/down _extremely_ resource intensive instances? A year++ ago I worked on a health-related application which used a system for processing X-ray images. During typical work hour (6 am-6 pm) it required a _huge_ amount of CPU and RAM instances. By shifting those specific services out to specialised instanced, we saw a $50K/month saving. The rest of the application is a lot more lightweight, but of course has to run 24/7, but being able to spin up/down required instances, and just pay for what you use, is a huge benefit for a lot of companies and organisations.
    - nicolaslem 4y ago
      A monolith is not a giant blob that has to run fully on one instance or else nothing works. Although I'm sure plenty of horrible enterprise software works that way, it is not a property of a monolith. I maintain a SaaS written as a monolith and I can absolutely spin instances that only load one part of the code and do a single thing, for example some instances only handle MQTT messages while others only serve HTTP endpoints. That does not make it microservices, it is all one code base sharing one database.
- roflyear 4y ago
  Overhead is way worse with microservices once you talk about network latency, database cost, infra for logging and monitoring, labor to manage that, and developer cost. Way, way, way, more than spinning up ten more identical webapps.
- NorwegianDude 4y ago
  Could just as well be at no additional cost. If your monolith separates services somewhat cleanly then you can run them on every node and not even touch the part of the codebase that's not related to the current task.
  - thatwasunusual 4y ago
    I wasn't talking about the cost of touching the codebase, but rather running a monolith horizontally with an overhead in terms of CPU-, disk- and RAM-usage. For big companies it might me a miniscule difference, but for smaller companies it can be a deal-breaker.
jason-phillips 4y ago
Having worked in both, I'll never work on a true monolith again.
- faeyanpiraat 4y ago
  Why?
  - KyeRussell 4y ago
    Because almost nobody has ever worked on a true monolith. It’s just “services abstractions people are comfortable with” and “everything else”.

quonn 4y ago

We learned in the 90s to not distribute the objects and instead just spin up more copied of the whole application. And if only scalability is the point this is still valid.

marcosdumay 4y ago
It's not much that we learned it at the 90's. It's that it became true at around the 90's. It used to be false, but computers became faster, memory more plentiful, and the fundamental physical limitations of networks didn't change a bit (well, fundamental physical limitations never do). It has become more and more true each passing year.
jameshart 4y ago
Weird flex to claim not to have learned anything new since the nineties though.
- quonn 4y ago
  Where did I say this? All I said is that it's usually effective to spin up more instances of the system - a conclusion we arrived at long ago. Regarding your point, most other disciplines gain knowledge over time, such as civil engineering, chemistry or biology and we don't discard results from the past with this kind of strawman argument of there supposedly not being anything to learn since. If things were like that, any progress would be impossible.
- dahfizz 4y ago
  And Calculus was invented 300 years ago. It still works. This attitude is extremely toxic to the development community. "Its old" is NOT valid criticism. "Its new" is NOT valid praise.
- JAlexoid 4y ago
  What I learned since the 90ies, is that software engineers don't learn from previous years... let alone from previous decades. This "microservices are better" argument was made in the 90ies and top dog is still Linux kernel (the one that was on the monolith side of that debate). So yeah - microservice advocates haven't learned anything since the 90ies, or from the SOA era, etc... (but I suspect they were in secondary/high school then) An anecdote: When I joined my current company had more code to orchestrate services, than the actual business value generating code in the services. We still produce an inordinate amount of code that exists just to facilitate microservice architecture. (it's also untested code, because we just don't have the money to spend time on testing it)

keewee7 4y ago

>Your X is a shit and it crashes every second? Companies that repeatedly fail to detect and solve this type of problem using automated testing and QA are exactly the companies that lack the sophistication to do distributed microservice architecture. Learn to do proper CI/CD, end-to-end testing, and logging/metrics on your monolith before you decide to transition to microservices.

jeffbee 4y ago
Disagree. At well-run companies with highly available services that you have certainly heard of I have routinely discovered microservice backends that are just crashing all over the place with no consequences to the user whatsoever. You can never say that about crashy monoliths.