5 ms·

> In other words, organizations adopt microservices for an operational benefit at the expense of performance. ...no, not at all. There are a couple of operatio

> In other words, organizations adopt microservices for an operational benefit at the expense of performance. ...no, not at all. There are a couple of operational benefits, but vastly more drawbacks, and on balance microservices are phenomenally harder to operate than monoliths. Organizations adopt microservices when the logistical overhead of coordinating teams against a monolith becomes so large that it starts affecting product velocity. Microservices are a way to release that organizational/logistical friction, at great technical cost. With that said, the domain-oriented bounded context is indeed the right way to think about service delineation.

rumanator 6y ago
> Organizations adopt microservices when the logistical overhead of coordinating teams against a monolith becomes so large that it starts affecting product velocity. That's certainly one of the operational limits, but arguably not the most important one. You distribute your system so that parts of it may scale independently, for example. Traffic fluctuates along time and the only option you have to scale your system is adding nodes as you go.
- sagichmal 6y ago
  The ability to scale services independently is not as impactful as many people believe, and changing your entire architecture for no other reason than to get that specific benefit is a mistake in the vast majority of cases. Microservices are a solution to organizational problems, not technical problems. On balance they create far more technical issues than they solve.
scarface74 6y ago
The last company I worked for was very much an “API first” company. We were a B2B company and our APIs were used by our relatively lightly used website. But they were also used for sporadic and large ETL jobs when files from customers came in and most importantly we sold access to our APIs that were used for our customer’s mobile apps and heavily trafficked website. We went microservices for the canonical reason you should - to be able to release and scale independently.
- sagichmal 6y ago
  That reason is oft touted but experience has pretty unambiguously revealed that it never pans out in practice. I mean you do get that benefit but the price you pay for it is absolutely disproportionate if that's the only thing you want. Opting in to microservices purely for presumed technical benefits is absolutely a mistake.
  - scarface74 6y ago
    How is it a “presumed” benefit when we actually did sell access to our APIs to clients? Some of our APIs initially had very low usage during the day until a batch job came in, others saw a spike in usage by over 100% when we bright a new client in. We were used by health care networks. Can you imagine the increased use post-Covid? We even had some that were both hosted on Fargate (Serverless Docker) with lower latency, more expensive but slower scaling for online use and hosted on Lambda for internal batch use - higher latency, faster scaling, less expensive for batch use. The CI/CD pipeline deployed to both.
    - sagichmal 6y ago
      My point is that you don't need to rearchitect your application in an entirely different style to be able to scale in response to load.
      - scarface74 6y ago
        If only part of your “application” has more load than others what do you suggest? That instead of being able to granular take part of the application that had a larger load, and run it on a Firecracker micro VM (the underlying VM for lambda and Fargate) with 256MB RAM and 1 core, we add enough VMs to scale a monolithic app - even the parts that don’t need it on a full scale VM with 8GB RAM and four cores? We did actually have to do something similar for a legacy Windows app. We scaled the entire process up based on the number of messages in the queue. It was extremely wasteful. It required at least a 4GB/2 CPU VM compared.

rumanator 6y ago

> Organizations adopt microservices when the logistical overhead of coordinating teams against a monolith becomes so large that it starts affecting product velocity. That's certainly one of the operational limits, but arguably not the most important one. You distribute your system so that parts of it may scale independently, for example. Traffic fluctuates along time and the only option you have to scale your system is adding nodes as you go.

sagichmal 6y ago
The ability to scale services independently is not as impactful as many people believe, and changing your entire architecture for no other reason than to get that specific benefit is a mistake in the vast majority of cases. Microservices are a solution to organizational problems, not technical problems. On balance they create far more technical issues than they solve.

scarface74 6y ago

The last company I worked for was very much an “API first” company. We were a B2B company and our APIs were used by our relatively lightly used website. But they were also used for sporadic and large ETL jobs when files from customers came in and most importantly we sold access to our APIs that were used for our customer’s mobile apps and heavily trafficked website. We went microservices for the canonical reason you should - to be able to release and scale independently.

sagichmal 6y ago
That reason is oft touted but experience has pretty unambiguously revealed that it never pans out in practice. I mean you do get that benefit but the price you pay for it is absolutely disproportionate if that's the only thing you want. Opting in to microservices purely for presumed technical benefits is absolutely a mistake.
- scarface74 6y ago
  How is it a “presumed” benefit when we actually did sell access to our APIs to clients? Some of our APIs initially had very low usage during the day until a batch job came in, others saw a spike in usage by over 100% when we bright a new client in. We were used by health care networks. Can you imagine the increased use post-Covid? We even had some that were both hosted on Fargate (Serverless Docker) with lower latency, more expensive but slower scaling for online use and hosted on Lambda for internal batch use - higher latency, faster scaling, less expensive for batch use. The CI/CD pipeline deployed to both.
  - sagichmal 6y ago
    My point is that you don't need to rearchitect your application in an entirely different style to be able to scale in response to load.
    - scarface74 6y ago
      If only part of your “application” has more load than others what do you suggest? That instead of being able to granular take part of the application that had a larger load, and run it on a Firecracker micro VM (the underlying VM for lambda and Fargate) with 256MB RAM and 1 core, we add enough VMs to scale a monolithic app - even the parts that don’t need it on a full scale VM with 8GB RAM and four cores? We did actually have to do something similar for a legacy Windows app. We scaled the entire process up based on the number of messages in the queue. It was extremely wasteful. It required at least a 4GB/2 CPU VM compared.