4 ms·

Any microservices discussion that does not take into account both infrastructure complexity and team size is incomplete. For small teams and small/not complex i

by joesmo 11y ago

Any microservices discussion that does not take into account both infrastructure complexity and team size is incomplete. For small teams and small/not complex infrastructures, it's always a bad idea. The premium that is paid for switching to microservices is great indeed and it's paid in much slower development and deployment times. This happens as soon as you start breaking an application apart, so even with only a couple of "mini" services, much of the price has been paid. Since the author doesn't mention either, I can't conclude anything, but it's very possible that the team he was advising didn't follow his advice because it was stupid and didn't take into account the above two factors. See obligatory reading: http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MicroservicePremium.html http://martinfowler.com/bliki/MicroservicePremium.html EDIT: Spacing

jeffasinger 11y ago
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
- 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.
chrstphrhrt 11y ago
Author here, the project I was referring to is a massive unwieldy Scala project using the Play framework (nothing inherently wrong with those choices). It has 177k LOC. It is a matter of months old. It is complete spaghetti and it's impossible to find what does what without learning IDE tricks. Guess I could have mentioned that. So actually my experience confirms the observations of Fowler about breaking up existing things rather than starting out with bunch of different services because fads. That said, I would still start breaking up services that are orthogonal to one another in the same way as one might break up db tables. Iff the interface for writing new services is comprised entirely of a spec for endpoints and their corresponding data schemas. If instead you're thinking of how risky it would be to have a handful of separate services all with their own pile of fragmenting boilerplate to maintain, then yeah, I'd agree a monolith is better still if that's the only option.
- ktRolster 11y ago
  The writing style of the article was very dense. I would have liked it if you could have condensed out the the sogginess so the main points came through more clearly.
- pjmlp 11y ago
  Speaking from my own experience, if the team is not able to properly design modular software using the programming language features to write well defined APIs, hiding packages/modules/whatever behind RPC call isn't going to turn them into good API designers anyway. Plus now they need to be good at distributed computing as well.
- twic 11y ago
  Could you expand on what "IDE tricks" you found necessary? They sound like something I need up my sleeve!
qyv 11y ago
The part I love about microservices, and something that I think doesn't get enough attention, is that is strongly enforces separation of concerns across micro-projects. API boundaries are very clear and very rigid, it takes very little effort or oversight to prevent leaking across them. Essentially, you are moving some of the software 'best-practices' up a level form modules to applications themselves. This means that you don't need to spend a lot of effort writing great, best-practices following, future-proof, software upfront for fear of collecting horrible technical debt down the road. Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application. And that is the other thing that I think microservices are great at: They are pragmatically easier to change. Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary, and developers are less likely to want to make changes to monoliths because of that. Microservices are easy to understand because they are small, discrete systems with well understood interface contracts. Making changes to them without breaking the entire app is not scary because it is easier to throughly understand the implications of what is being changed.
- elliotlarson 11y ago
  I'm sort of playing devil's advocate here, but: > Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application. But that's also true of a monolith. Got a piece of your system that isn't maintainable any more. Rewrite it! 2 weeks later you have erased... you get the point. I like the idea of microservices. I like the idea of the clean boundaries. As a developer, the separation seems correct to me. But, unless you're actually feeling the pain point of the monolith, it just seems like more work that falls into the category of YAGNI. You also said this: > Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary... I mean, it's hard and scary if you don't have a high level of test coverage. If you have great coverage in the old monolith, you should be able to change pieces of it with confidence, no?
pnathan 11y ago
Don't forget.... - debugging - networking - service discovery - distributed system fallacy list I've become persuaded that generally microservices are an antipattern largely related to weak technical leadership. They bring incredible weight onto an organization, both technically and socially.
- aikah 11y ago
  - latency - eventual consistency of data - ...

by joesmo 11y ago

jeffasinger 11y ago

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
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.

chrstphrhrt 11y ago

Author here, the project I was referring to is a massive unwieldy Scala project using the Play framework (nothing inherently wrong with those choices). It has 177k LOC. It is a matter of months old. It is complete spaghetti and it's impossible to find what does what without learning IDE tricks. Guess I could have mentioned that. So actually my experience confirms the observations of Fowler about breaking up existing things rather than starting out with bunch of different services because fads. That said, I would still start breaking up services that are orthogonal to one another in the same way as one might break up db tables. Iff the interface for writing new services is comprised entirely of a spec for endpoints and their corresponding data schemas. If instead you're thinking of how risky it would be to have a handful of separate services all with their own pile of fragmenting boilerplate to maintain, then yeah, I'd agree a monolith is better still if that's the only option.

ktRolster 11y ago
The writing style of the article was very dense. I would have liked it if you could have condensed out the the sogginess so the main points came through more clearly.
pjmlp 11y ago
Speaking from my own experience, if the team is not able to properly design modular software using the programming language features to write well defined APIs, hiding packages/modules/whatever behind RPC call isn't going to turn them into good API designers anyway. Plus now they need to be good at distributed computing as well.
twic 11y ago
Could you expand on what "IDE tricks" you found necessary? They sound like something I need up my sleeve!

qyv 11y ago

The part I love about microservices, and something that I think doesn't get enough attention, is that is strongly enforces separation of concerns across micro-projects. API boundaries are very clear and very rigid, it takes very little effort or oversight to prevent leaking across them. Essentially, you are moving some of the software 'best-practices' up a level form modules to applications themselves. This means that you don't need to spend a lot of effort writing great, best-practices following, future-proof, software upfront for fear of collecting horrible technical debt down the road. Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application. And that is the other thing that I think microservices are great at: They are pragmatically easier to change. Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary, and developers are less likely to want to make changes to monoliths because of that. Microservices are easy to understand because they are small, discrete systems with well understood interface contracts. Making changes to them without breaking the entire app is not scary because it is easier to throughly understand the implications of what is being changed.

elliotlarson 11y ago
I'm sort of playing devil's advocate here, but: > Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application. But that's also true of a monolith. Got a piece of your system that isn't maintainable any more. Rewrite it! 2 weeks later you have erased... you get the point. I like the idea of microservices. I like the idea of the clean boundaries. As a developer, the separation seems correct to me. But, unless you're actually feeling the pain point of the monolith, it just seems like more work that falls into the category of YAGNI. You also said this: > Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary... I mean, it's hard and scary if you don't have a high level of test coverage. If you have great coverage in the old monolith, you should be able to change pieces of it with confidence, no?

pnathan 11y ago

Don't forget.... - debugging - networking - service discovery - distributed system fallacy list I've become persuaded that generally microservices are an antipattern largely related to weak technical leadership. They bring incredible weight onto an organization, both technically and socially.

aikah 11y ago
- latency - eventual consistency of data - ...