some engineers really struggle with making backwards compatible changes. they probably have a lot of dependencies across their service landscape (doubly/triply

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.