> Microservices allow independent deployments. (Is that actually a requirement for your team, or just a nice-to-have?)

Only one of my friends has worked at a place that had a "microservices" architecture. I put that in quotes, because he said that none of them could be deployed independently of each other. (He didn't say if it was formerly a monolith.) I wonder how prevalent that is.

Very, because building a service that is backwards compatible and / or has API guarantees is a lot of work. And a lot of these microservices share data model definitions in one way or another, because it's perceived wasteful to try and keep them stable or duplicate them across API boundaries.

Which in turn led to a push for monorepos, so these changes can be deployed across multiple services in one merge, and the multiple services deployed at once.

In such an architecture, the people working on it acknowledge that using a network as a domain boundary is kinda inconvenient, but they spent a lot of effort on minimizing the inconvenience / overhead.

some engineers really struggle with making backwards compatible changes. they probably have a lot of dependencies across their service landscape (doubly/triply so in orgs that have gone through acquisitions/mergers).

it's pretty classic... you have the same problem with other architectures too, whether it's a monolith, event driven, SOA, distributed monolith, etc... bad design and ill defined dependencies have literally nothing to do with micro services anymore than any other architecture.

blaming some specific architecture pattern for bad design is silly. bad design is bad design. lack of the ability to evolve a system over time is bad design, it has nothing to do with the architecture necessarily.

that being said, I do generally dislike microservices personally, for large complex systems anyway; you end up with piles and piles of HTTPS/JSON/JWT overhead.

using any kind of architecture pattern can of course have these problems, to be fair... it's just more prevalent with microservices because it becomes a catch all universal tool, just add another "microservice".

before long you have competing services that have the same purpose just because people can't evolve systems in place. worse are saga patterns and phased commits, etc...

there's an XKCD for that I'm sure, the one about standards would fit.

anyway, I appreciate the points in the article that gesture towards Conway's law or inverse Conway maneuver; it's best when your org/team/project structure align w/ architecture, and vice versa. architecture isn't just about software and deployments, it's also about process, alignment, and evolution.