Overstated. Makes the usual "I hate blah blah" essay mistake of confusing the way something is understood and implemented in the general dev community with what

Overstated. Makes the usual "I hate blah blah" essay mistake of confusing the way something is understood and implemented in the general dev community with what it actually is. Most of the time, things start off for good reason and represent good practices. We just butcher the hell out of them when we start selling them to one another. (Same thing happens in reverse; once enough people destroy any goodness left in a buzzword, people oversell how bad the idea is when they start pitching their plan to get rid of it) To be clear, I don't disagree with the premise that lots of microservices implementations are a clusterfuck of monumental proportions. It's just ranting and raving about devs and dev shops screw up stuff isn't exactly news to anybody. That's the natural state of affairs no matter what your flavor-of-the-week. We get close to something useful near the end, "...focus on the right criteria for splitting a service instead of on its size, and apply those criteria more thoughtfully..." The rest of this looks like a rehash of generally-accepted architectural principles, most of which were misapplied and resulted in us getting here in the first place. I'm not going to line-by-line critique this. There are far too many points to counter and I can't imagine the discussion keeping any sort of reasonable cohesion (hardy har har) if it spreads out that wide. Oddly enough, I find this discussion of why monoliths might be a preferable default state too monolithic to split up into reasonable chunks to analyze. Much irony there. We got to microservices (or I might rather say we _returned_ to microservices) by following good code organization principles. Instead of starting with the resulting implementation (such as the DAGs and various models in this essay) and trying to argue first principles, it's better to start with first principles and then come up with criteria for evaluating various results. I feel I would be neglectful if I didn't add this: if your code is right, whether you're deploying as a microservice or a monolith shouldn't matter. That's a deployment decision. If it's not an easy deployment decision, if you can't change by flipping a bit somewhere, then either your first principles are off somewhere or you made a mistake in implementing them. The way you code should all be about solving a real problem for your users. How you chunk your code and where those chunks go are hardly ever one of those problems.