4 ms·

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

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.