[jamestenglish]

I am an older dev that did a lot of "SOA" work back in the 2000's and I disagree that microservices are a "reinvention". In my opinion they are a further refinement of those SOA ideas (which is a good thing to keep moving forward as an industry).

A lot of the SOA work I did was putting REST/SOAP interfaces on various monolithic APIs. This was generally a good step forward and decoupled things (especially the front-end) but it was far from perfect. You still had the monolith and a lot of the code-smell that gets built into a monolith of spaghetti dependencies making it hard to write new features and move forward.

Now the argument is always "well if you and your team were just better coders and more disciplined that wouldn't happen" but in the real world it is shown to be incredibly difficult to actually have a team that is that disciplined and microservices give a real hard barrier to enforce that discipline.

I very rarely see things that are truly reinvented, and I think that is some serious ego bias essentially saying: back in my day we did it right and you dummies are just figuring it out.

Instead I see every new generation of developers refining good ideas over and over again which improves our industry and products.

[lmm]

> Now the argument is always "well if you and your team were just better coders and more disciplined that wouldn't happen" but in the real world it is shown to be incredibly difficult to actually have a team that is that disciplined and microservices give a real hard barrier to enforce that discipline.

I agree that you need enforcement. But by having a multi-module project in a good build system you can enforce decoupling at build time, without the overhead of a network bourdary.

[jamestenglish]

Very true, but decoupling is only 1 of the benefits of microservice. Polygot environments, scalability, etc also come with microservices vs modules.

As with everything its about the right tool for the job and a lot of organizations are more than happy to trade network overhead for the other bullet points microservices offer.

[lmm]

Polyglot I've concluded is more trouble than it's worth - you always end up wanting to reuse code between modules, so a good general-purpose language for everything is much better than multiple languages. Scaling is a nice problem to have - it makes sense to split out services when you need to do so to scale, but it's not worth the overhead until you need it (particularly if you have enforced decoupling already, because that ensures that you will be able to cleanly factor out services when the time comes).

The more experience I get the more I think "right tool for the job" is bad advice. It makes it sound like tool choice is always 50-50, whereas actually in a lot of cases it's more like 95-5. I've worked at a number of organizations using various architectures, but the one that was most gung-ho for microservices was by far the least successful, I think as a direct result of their approach to microservices.