4 ms·

The cost of being able to efficiently deploy 5 or so services is probably 5x the cost of deploying your single Monolith (this can be a mostly manual process onl

The cost of being able to efficiently deploy 5 or so services is probably 5x the cost of deploying your single Monolith (this can be a mostly manual process only doable by 1 or 2 people). However the cost of deploying 100 services is still only about 5x the cost of deploying the single Monolith. There's certainly a size threshold below which a microservices approach hurts more than helps.

elliotec 11y ago
How do you figure that deploying 5 services vs 100 is the same cost? Also how do you take into account maintenance and configuration of each individual service and tying them together as a whole? From my experience, even at large enterprise scale, microservices have been a hinderance at the very least when compared to entrenched monoliths. The effort to keep all the individual pieces working properly and harmoniously has never been worth it in any situation I've personally been in.
- julian_1 11y ago
  > How do you figure that deploying 5 services vs 100 is the same cost? By using generalizable deployment configuration tools - ansible, chef puppet perhaps?. The configuration complexity would probably depend a lot on what exactly those services do. For example - if they are all tomcat containers - with standard integration endpoints then there would be diminishing cost associated with each additional node/service deployment.
  - chrstphrhrt 11y ago
    Relevant: here's a reply I made to a similar question on the original post: https://medium.com/@chrstphrhrt/thanks-1b19b2e3ec09#.g493c33u7 https://medium.com/@chrstphrhrt/thanks-1b19b2e3ec09#.g493c33...
joesmo 11y ago
Maybe, but the increased development costs are incredibly high as soon as you move from a monolith, so much so that the deployment costs, no matter how large, will be dwarfed. For example, in my current setup, having a "mini" services architecture (typical monolith split up into three parts + supporting services) is probably costing us about 25% of our time. In other words, if we had a monolith, we'd be able to spend 3 extra months a year developing or refactoring that are now wasted in the slow development process that is caused slowly by the boundaries between applications.
- nickpsecurity 11y ago
  You sure it's not the mainstream tools supporting microservices that are the problem? The E language, Fabric secure middleware, and even embedded on OKL4 with Camkes were straight forward. Small teams supported stuff like that because tools do almost all the work. It's like a modular, monolithic app with some parameters to tune and fault isolation. Just seems like development, deployment, and support tooling could knock out issues people describe easily.
- ktRolster 11y ago
  > having a "mini" services architecture > is probably costing us about 25% of our time. Wow, that's actually quit a bit. What would you estimate is taking most of that time?
- mej10 11y ago
  How is having microservices vs monolith increasing your development time? We have a lot of microservices, and I feel like having each piece of functionality silo'd with proper service boundaries only speeds up development.
  - mvc 11y ago
    Do you work on more than one in a given week? How do you test a feature which requires co-ordination between several of your services?
  - joesmo 11y ago
    Here's an example of equivalent operations: Monolith: * make db call Microservices: * send request * receive request * process request (equivalent to monolith db call above) * send response back * receive response * decode response Every single one of these steps needs to be debugged or at least tested every single time. Debugging itself becomes extremely difficult because you have to stop in one program and continue in another. You need a system for mocking data between the apps to reliably reproduce problems and debug them. There are problems that are silent between the two applications. You need to figure out a system for transactions. Or worse, distributed transactions. You have to deal with possibly sending out ridiculously huge amounts of data from app to app over a slow, unreliable network. You have to deal with service discovery. I could go on and on. Every single one of these things adds complexity. For a small team or uncomplicated infrastructure (or both) this slows down the project immensely. That 25% that I'm quoting is from my current job and it's not overinflated. If you have enough people to handle it and your app is incredibly complex, then I have no doubt that your claims of speeding up development are true. If you're not at that scale/complexity, the opposite is true.
Florin_Andrei 11y ago
> The cost of being able to efficiently deploy 5 or so services is probably 5x the cost of deploying your single Monolith I don't know. As soon as you have reasonable Ansible templates for everything, it doesn't matter that much that you're deploying 1, 2, 5, or 50 services.

elliotec 11y ago

How do you figure that deploying 5 services vs 100 is the same cost? Also how do you take into account maintenance and configuration of each individual service and tying them together as a whole? From my experience, even at large enterprise scale, microservices have been a hinderance at the very least when compared to entrenched monoliths. The effort to keep all the individual pieces working properly and harmoniously has never been worth it in any situation I've personally been in.

julian_1 11y ago
> How do you figure that deploying 5 services vs 100 is the same cost? By using generalizable deployment configuration tools - ansible, chef puppet perhaps?. The configuration complexity would probably depend a lot on what exactly those services do. For example - if they are all tomcat containers - with standard integration endpoints then there would be diminishing cost associated with each additional node/service deployment.
- chrstphrhrt 11y ago
  Relevant: here's a reply I made to a similar question on the original post: https://medium.com/@chrstphrhrt/thanks-1b19b2e3ec09#.g493c33u7 https://medium.com/@chrstphrhrt/thanks-1b19b2e3ec09#.g493c33...

joesmo 11y ago

Maybe, but the increased development costs are incredibly high as soon as you move from a monolith, so much so that the deployment costs, no matter how large, will be dwarfed. For example, in my current setup, having a "mini" services architecture (typical monolith split up into three parts + supporting services) is probably costing us about 25% of our time. In other words, if we had a monolith, we'd be able to spend 3 extra months a year developing or refactoring that are now wasted in the slow development process that is caused slowly by the boundaries between applications.

nickpsecurity 11y ago
You sure it's not the mainstream tools supporting microservices that are the problem? The E language, Fabric secure middleware, and even embedded on OKL4 with Camkes were straight forward. Small teams supported stuff like that because tools do almost all the work. It's like a modular, monolithic app with some parameters to tune and fault isolation. Just seems like development, deployment, and support tooling could knock out issues people describe easily.
ktRolster 11y ago
> having a "mini" services architecture > is probably costing us about 25% of our time. Wow, that's actually quit a bit. What would you estimate is taking most of that time?
mej10 11y ago
How is having microservices vs monolith increasing your development time? We have a lot of microservices, and I feel like having each piece of functionality silo'd with proper service boundaries only speeds up development.
- mvc 11y ago
  Do you work on more than one in a given week? How do you test a feature which requires co-ordination between several of your services?
- joesmo 11y ago
  Here's an example of equivalent operations: Monolith: * make db call Microservices: * send request * receive request * process request (equivalent to monolith db call above) * send response back * receive response * decode response Every single one of these steps needs to be debugged or at least tested every single time. Debugging itself becomes extremely difficult because you have to stop in one program and continue in another. You need a system for mocking data between the apps to reliably reproduce problems and debug them. There are problems that are silent between the two applications. You need to figure out a system for transactions. Or worse, distributed transactions. You have to deal with possibly sending out ridiculously huge amounts of data from app to app over a slow, unreliable network. You have to deal with service discovery. I could go on and on. Every single one of these things adds complexity. For a small team or uncomplicated infrastructure (or both) this slows down the project immensely. That 25% that I'm quoting is from my current job and it's not overinflated. If you have enough people to handle it and your app is incredibly complex, then I have no doubt that your claims of speeding up development are true. If you're not at that scale/complexity, the opposite is true.

Florin_Andrei 11y ago

> The cost of being able to efficiently deploy 5 or so services is probably 5x the cost of deploying your single Monolith I don't know. As soon as you have reasonable Ansible templates for everything, it doesn't matter that much that you're deploying 1, 2, 5, or 50 services.