The pattern was sound. The history is clear. What broke microservices wasn't the architecture — it was practitioners who applied the deployment unit without the engineering discipline the original authors said it required.
There is a version of the microservices post-mortem that treats the pattern itself as the problem. Distributed systems are hard. Eventual consistency is hard. Operational overhead compounds. Better to stay with the monolith. This is the wrong conclusion, drawn from the wrong evidence, by people who perhaps should never have adopted microservices in the first place.
Microservices did not fail. A generation of engineers adopted an architectural pattern without the domain modelling discipline it demands, kept the synchronous call patterns from the systems they were supposed to be replacing, and then blamed the architecture when the complexity became unmanageable. That is not a failure of microservices. It is a failure of craft.
What the Original Authors Actually Said
Fred George was talking about micro-services — note the hyphen, the original form — at conferences as early as 2012. His framing was specific and unambiguous: very small services, a hundred or two hundred lines of code, communicating asynchronously, each doing one thing and signalling when done. He called the underlying philosophy programmer anarchy — not because it was chaotic, but because it required engineers senior and capable enough to operate without the management scaffolding that larger, less capable teams depend on.
