5 ms·

>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

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

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.