I guess this article just resonates with me as a member of an organization in the process of "transforming" itself by migrating to a containers-and-services architecture with the goal of "continuously delivering" components of what has historically been a very monolithic and tightly integrated product. Lets just say it's in the class of products one might consider "big iron", but not strictly. This transformation sounds like an admirable goal on paper and in meetings, but the system we are building today is even more complex than what preceded it, because it has to do all the stuff it did before, and more, but now I have to worry about containers and a half dozen ways to orchestrate them, and whatever some other team has decided to replace their API with because now nobody is supposed to make assumptions about what anybody else is supporting, or we're all supposed have our software spend a bunch of cycles negotiating versions and APIs or something. This is way more complex. I guess the idea is now we can release patches for individual components, instead of having to do roll-up releases or something? But there's really no reason we had to do those anyways - dynamically linking to a library isn't much different conceptually than attaching to a "service API" when it's all happening internally to some box.<p>People go read about what Amazon, or Netflix, or Facebook are doing and see how successful they've been (in both the financial and technical), and say "we can be like that too if we use the same stuff they're using!". Some manager reads a book which makes broad generalizations about "the right tools and behaviors", and starts building a cargo cult around them. Some kid in the valley whose never worked with a codebase larger than 10,000 SLoC writes a blog post about it, and everyone makes a toast with the koolaid. "More than 10,000 SLoC is an anti-pattern!" you say.<p>This may be a bit of stretched analogy, but just as communism or other socio-economic ideologies have given some people a framework for uprooting their broken incumbent governments and power culture, technological fads like "DevOps", etc, sometimes just give people the framework to uproot their broken incumbent tools and technology culture. The problem is, most of the time what you needed wasn't communism per-se, or DevOps, but just some framework to mobilize and guide your culture into fixing its fucked up status quo. It would have been better if you looked at your problems, instead of looking at the other guys solutions. The unique pitfall technological transformation encounters in this regard, is often the social framework (i.e. DevOps) gets conflated with the tools (i.e. containers and microservices), and leadership tends to focus on the latter - because changing tools is easier than changing people. What you needed was a better culture, and I think in most cases - a culture of reducing complexity - but what you got instead was microservices and "containers.