The author’s complaints are about abstraction, not scale. Microservices exist to be an abstraction. They have some properties that allow for scaling horizontally in certain ways, but scale is not their primary purpose. The same goes for many cloud services.

Risk mitigation is the primary reason that hard architectural boundaries are used. And by risk, I refer to business risk.

What are the chances a given change will negatively impact the business? How broad might the impact be? Can service be restored quickly without critical data loss?

Microservices allow a business to limit risk by placing very hard architectural boundaries on different requirements. For example, having a billing service that only receives updates when billing logic changes is much lower risk to the business than a billing service that updates because someone needed a newer version of Go to import a package used by their unrelated image compression function elsewhere in the application. What if the update causes the application to crash unexpectedly? What if the update causes a performance problem that starves other work on the machine? What if a supply chain attack was accidentally introduced by the new package version? What if the server configuration changed to support that new runtime version, and it broke other functionality?

The author’s example of managing a Python codebase with custom tooling to enforce certain interface boundaries in the code is not a very broad solution for mitigating business risk. What happens when you need to update Python? The entire application is affected. Perhaps the author’s application is trivial to test, but in my experience, testing complex applications is very costly.

I think microservices are cool, but silly. It’s rare when you actually need them.