5 ms·

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

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.
    - sagichmal 6y ago
      Scale the whole thing. The cost of doing that is usually orders of magnitude less than the true CapEx and OpEx of microservices. edit: If breaking out one service from your monolith worked for your use case, that's great. I'm not trying to deny your experience. It is atypical, however.
      - scarface74 6y ago
        We are talking about a 16x difference in resources. Would you also suggest scaling a database that was more read heavy than write heavy instead of splitting reads and writes when you can deal with eventual consistency and just autoscale the read replicas?
        sagichmal 6y ago
        The comparison is not equivalent.
        cutemonster 6y ago
        Agreed, I think the comparison is not equivalent, because a read replica actually is the same database application (same "monolith") just started with different parameters, to behave as a replica
        scarface74 6y ago
        The database is the same but you have to then separate your code into reader and writer services with different connection strings, you have to make sure that anything that can’t be eventually consistent uses the writer connection string, etc. It’s not just a matter of spinning up a database. Also, since many enterprise apps live stores procedures and putting business logic in the database, that’s another ball of wax you have to untangle.

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.
  - sagichmal 6y ago
    Scale the whole thing. The cost of doing that is usually orders of magnitude less than the true CapEx and OpEx of microservices. edit: If breaking out one service from your monolith worked for your use case, that's great. I'm not trying to deny your experience. It is atypical, however.
    - scarface74 6y ago
      We are talking about a 16x difference in resources. Would you also suggest scaling a database that was more read heavy than write heavy instead of splitting reads and writes when you can deal with eventual consistency and just autoscale the read replicas?
      - sagichmal 6y ago
        The comparison is not equivalent.
        cutemonster 6y ago
        Agreed, I think the comparison is not equivalent, because a read replica actually is the same database application (same "monolith") just started with different parameters, to behave as a replica
        scarface74 6y ago
        The database is the same but you have to then separate your code into reader and writer services with different connection strings, you have to make sure that anything that can’t be eventually consistent uses the writer connection string, etc. It’s not just a matter of spinning up a database. Also, since many enterprise apps live stores procedures and putting business logic in the database, that’s another ball of wax you have to untangle.