5 ms·

There are plenty more reasons than the three you've mentioned... However, the one thing that's not a reason to use microservices and which the article brought

There are plenty more reasons than the three you've mentioned... However, the one thing that's not a reason to use microservices and which the article brought up a lot, is to increase resilience. Microservices do not increase resilience: at best they can avoid reducing it. One of the most compelling reasons for me to use microservices is to limit the potential damage of bad decisions. In a monolithic application, one developer can have a bad day and write some code that eg. leaks a database object into an area of the program which should deal with business logic only. Or perhaps they try out some new technology that turns out to have problems. If that manages to get through code review, and is then copied elsewhere by other developers who are just following the example, you can quickly end up in a situation where fixing the problem requires everyone to stop feature work so that a significant rewrite or at least refactoring can take place. In most cases, the business cannot afford to stop all feature work in this way, and so the problem will persist forever, becoming a permanent drop in productivity. It will also make your developers miserable. In a microservices architecture, a single mistake can only grow to the size of a single service. In the worst case you have to stop feature work on that one service for a period of time, but work on other areas of the product can continue uninterrupted. Of course, you could still make a mistake whilst defining the boundaries between services. Luckily those decisions are much less frequent and involve many more people, so there's less chance of a freak bad decision. And even if you do get it wrong, you're only looking at two or three affected services rather than your whole product.

macspoofing 5y ago
>you can quickly end up in a situation where fixing the problem requires everyone to stop feature work so that a significant rewrite or at least refactoring can take place. But that's normal and expected on any non-trivial codebase that has been evolving over some amount of time. We call that 'maintenance'. You'll never have 100% of your development resources pushing new features out. And if you do, well... we call that 'incurring technical debt'. You should be investing in this kind of maintenance continuously, because as your product evolves, new problem areas will emerge. >In most cases, the business cannot afford to stop all feature work in this way, and so the problem will persist forever, becoming a permanent drop in productivity. Yes.. That's called 'technical debt'. If your business does not invest in maintenance today, then it'll will cost them in the future. This isn't limited to software. If you're maintaining physical infrastructure, same deal. You're always fixing things. Microservices are not a solution to this. >In a microservices architecture, a single mistake can only grow to the size of a single service. Not necessarily. Microservices tend to be tightly coupled to other microservices. I've worked on a system that suffered from sporadic 'failure storms' where a failure in one service propagated across the entire system. It took days for us to track down the root cause. Microservices aren't a panacea. In fact, everything is easier with monolithic systems.
- Diggsey 5y ago
  > But that's normal and expected on any non-trivial codebase that has been evolving over some amount of time. Having to stop all feature work is not normal. A healthy business should be able to have a certain proportion of its engineers working on tech debt at all times, it shouldn't have to stop all feature work to address tech debt.
  - macspoofing 5y ago
    Who says you have to stop all feature work? Like you said, part of your dev resources will (should) be dedicated to maintaining your system.
    - Diggsey 5y ago
      Because in a monolith, the problem can easily extend into all parts of the system, making it very difficult to continue feature work whilst fixing the problem. In a microservice, in the absolute worst case (let's say a foundational technology suddenly becomes unsuitable) you have to rebuild just that service. Work on other services can continue uninterrupted in the meantime.
      - anyfoo 5y ago
        Unless the problem lies in an interface shared across many or all services, or the assumed data model, or other higher level considerations. There are certainly monoliths that are successfully being developed on by many people at the same time (OS kernels for example), and I can see a few arguments why developing and debugging with microservices can be harder. For once, it's much easier to deal with most of your state in one address space instead of multiple.
      - macspoofing 5y ago
        >Because in a monolith, the problem can easily extend into all parts of the system, making it very difficult to continue feature work whilst fixing the problem. You're creating a strawman. That's now how software is written. Monolithic software is modularized as well, but the boundaries are behind interfaces and modules, instead of http services. That makes them easier to work with. >In a microservice, in the absolute worst case (let's say a foundational technology suddenly becomes unsuitable) you have to rebuild just that service. No. Not necessarily. >Work on other services can continue uninterrupted in the meantime. Again, it's a weird hill you're dying on. You can refactor, or rewrite an module without pausing feature development. It happens all.the.time. I don't know what your professional experience is but clearly it is not indicative of the wider reality.
candiddevmike 5y ago
A single mistake can only impact one service? If a microservice depends on said broken microservice, you could experience a cascade of failures, or possibly data corruption, because microservice development is typically predicated on trusting the other components following their API spec.
- Diggsey 5y ago
  See my other reply: I'm not talking about bugs, I'm talking about tech debt and design mistakes.
yxhuvud 5y ago
Well there are different cases of resilience. Creating a separate service for some part that have the potential for network traffic spikes can be fine and can make the system more resilient against that. But you are right in that it makes the code resilience worse, as it makes logic discovery and overview harder.
rualca 5y ago
> In most cases, the business cannot afford to stop all feature work in this way, and so the problem will persist forever, becoming a permanent drop in productivity. It will also make your developers miserable. This scenario is only possible if the project has no automated testing or invests any effort in QA or no one pays any attention whatsoever to whatever is running in prod. Meanwhile, one of the basic features of CICD is automated rollbacks. If this sort of problem happens on a project, the problem was not caused by a developer having a bad day. The problem is caused by an entire team enduring a culture that allows problems to fester without anyone doing anything about it.
- Diggsey 5y ago
  I'm not talking about bugs, I'm talking about tech debt and design problems. Tests can't catch those things, and you can't rollback six months of work...

macspoofing 5y ago

>you can quickly end up in a situation where fixing the problem requires everyone to stop feature work so that a significant rewrite or at least refactoring can take place. But that's normal and expected on any non-trivial codebase that has been evolving over some amount of time. We call that 'maintenance'. You'll never have 100% of your development resources pushing new features out. And if you do, well... we call that 'incurring technical debt'. You should be investing in this kind of maintenance continuously, because as your product evolves, new problem areas will emerge. >In most cases, the business cannot afford to stop all feature work in this way, and so the problem will persist forever, becoming a permanent drop in productivity. Yes.. That's called 'technical debt'. If your business does not invest in maintenance today, then it'll will cost them in the future. This isn't limited to software. If you're maintaining physical infrastructure, same deal. You're always fixing things. Microservices are not a solution to this. >In a microservices architecture, a single mistake can only grow to the size of a single service. Not necessarily. Microservices tend to be tightly coupled to other microservices. I've worked on a system that suffered from sporadic 'failure storms' where a failure in one service propagated across the entire system. It took days for us to track down the root cause. Microservices aren't a panacea. In fact, everything is easier with monolithic systems.

Diggsey 5y ago
> But that's normal and expected on any non-trivial codebase that has been evolving over some amount of time. Having to stop all feature work is not normal. A healthy business should be able to have a certain proportion of its engineers working on tech debt at all times, it shouldn't have to stop all feature work to address tech debt.
- macspoofing 5y ago
  Who says you have to stop all feature work? Like you said, part of your dev resources will (should) be dedicated to maintaining your system.
  - Diggsey 5y ago
    Because in a monolith, the problem can easily extend into all parts of the system, making it very difficult to continue feature work whilst fixing the problem. In a microservice, in the absolute worst case (let's say a foundational technology suddenly becomes unsuitable) you have to rebuild just that service. Work on other services can continue uninterrupted in the meantime.
    - anyfoo 5y ago
      Unless the problem lies in an interface shared across many or all services, or the assumed data model, or other higher level considerations. There are certainly monoliths that are successfully being developed on by many people at the same time (OS kernels for example), and I can see a few arguments why developing and debugging with microservices can be harder. For once, it's much easier to deal with most of your state in one address space instead of multiple.
    - macspoofing 5y ago
      >Because in a monolith, the problem can easily extend into all parts of the system, making it very difficult to continue feature work whilst fixing the problem. You're creating a strawman. That's now how software is written. Monolithic software is modularized as well, but the boundaries are behind interfaces and modules, instead of http services. That makes them easier to work with. >In a microservice, in the absolute worst case (let's say a foundational technology suddenly becomes unsuitable) you have to rebuild just that service. No. Not necessarily. >Work on other services can continue uninterrupted in the meantime. Again, it's a weird hill you're dying on. You can refactor, or rewrite an module without pausing feature development. It happens all.the.time. I don't know what your professional experience is but clearly it is not indicative of the wider reality.

candiddevmike 5y ago

A single mistake can only impact one service? If a microservice depends on said broken microservice, you could experience a cascade of failures, or possibly data corruption, because microservice development is typically predicated on trusting the other components following their API spec.

Diggsey 5y ago
See my other reply: I'm not talking about bugs, I'm talking about tech debt and design mistakes.

yxhuvud 5y ago

Well there are different cases of resilience. Creating a separate service for some part that have the potential for network traffic spikes can be fine and can make the system more resilient against that. But you are right in that it makes the code resilience worse, as it makes logic discovery and overview harder.

rualca 5y ago

> In most cases, the business cannot afford to stop all feature work in this way, and so the problem will persist forever, becoming a permanent drop in productivity. It will also make your developers miserable. This scenario is only possible if the project has no automated testing or invests any effort in QA or no one pays any attention whatsoever to whatever is running in prod. Meanwhile, one of the basic features of CICD is automated rollbacks. If this sort of problem happens on a project, the problem was not caused by a developer having a bad day. The problem is caused by an entire team enduring a culture that allows problems to fester without anyone doing anything about it.

Diggsey 5y ago
I'm not talking about bugs, I'm talking about tech debt and design problems. Tests can't catch those things, and you can't rollback six months of work...