Microservices is the architectural pattern that dominated the 2010s — breaking monolithic applications into small, independently deployable services that communicate through APIs — and my relationship to it has been one of genuine appreciation paired with deep skepticism about how the industry approached it. At its core, the microservices idea is sound and APIs are central to it: instead of one giant application, you build a collection of small, focused services, each owning a clear responsibility, each exposing an API, each deployable on its own. When done well, this produces systems that are more scalable, more resilient, and easier to evolve. But “done well” is the catch, and most of my writing about microservices has been a warning against the ways organizations get it wrong — because microservices, like SOA before it, became a hype-driven movement that promised more than it delivered for most who chased it.
The relationship between microservices and APIs is fundamental, and it’s the lens through which I’ve always understood the pattern. APIs are how microservices communicate — each service exposes an API, and the system is the composition of those services calling each other through their APIs. I wrote in 2015 on APIs and microservices that you can’t really separate the two: a microservice without a well-designed API is just a small application, and the discipline of microservices is fundamentally the discipline of API design applied at the service boundary. OpenAPI is the contract for your microservice, as I argued in 2018 — the machine-readable definition that specifies what each service does, what it expects, and what it returns, which is exactly what you need to compose services reliably. Everything I know about good API design — clear contracts, consistent interfaces, proper versioning, dependency management — applies directly to microservices, because microservices are an architecture built out of APIs.
The “you will repeat SOA’s mistakes” warning is the one I sounded most insistently, because the parallel was so obvious and so ignored. Microservices is, in important ways, SOA reborn — the same fundamental idea of decomposing systems into services, dressed in new clothes. I wrote in 2015, “here we go again, SOA and API, we have already done this,” and in 2017 that your microservices effort will fail just like your API and SOA initiatives. The reason for the warning is that the enterprise that botched SOA was poised to botch microservices the same way, because the failures weren’t technical — they were organizational. SOA failed not because the technology was wrong but because organizations couldn’t do the hard work of defining boundaries, decoupling systems, and aligning teams. Microservices faced the exact same challenge, and most organizations approached it as a technical fad rather than the organizational discipline it actually required. The hype cycle around microservices repeated the SOA hype cycle almost beat for beat, and the same lessons went unlearned.
The deeper insight, which I returned to repeatedly, is that microservices failure is organizational, not technical. I wrote in 2018 that your microservices effort will fail because you will never decouple your business — meaning that the technical decomposition of your systems into microservices is meaningless if you can’t also decouple the organizational structures, the business logic, and the team boundaries that the services are supposed to reflect. Conway’s Law looms over all of this: your services will mirror your organization, and if your organization is a tangled monolith of dependencies and unclear ownership, your microservices will be too. The hardest part of microservices was never the technology — it was the business and organizational decoupling that the architecture demands and that most enterprises were unwilling or unable to do. I kept making this point because the industry kept selling microservices as a technical solution to what is fundamentally an organizational problem.
The Amazon model is the proof that microservices can work, and it’s the counterexample that proves the rule about organizational discipline. The Bezos mandate that I wrote about — every team exposing its capabilities through service interfaces, with no exceptions — is the microservices pattern executed with the organizational discipline it requires. Amazon’s success with internal APIs and the architecture that became AWS demonstrates that microservices, done with genuine organizational commitment to decoupling and service ownership, produces extraordinary results. But Amazon did it by mandate, by changing the organization, not just the technology. The new AWS API Gateway in 2015 and the serverless composition it enabled showed how the microservices pattern, supported by the right infrastructure, could scale. The lesson of Amazon is that microservices work when the organization is genuinely restructured around services — and that’s exactly the hard work most organizations skip while adopting the technical trappings of microservices.
The governance and organization challenges of microservices are real, and they’re where I focused a lot of practical attention. How should we organize all our microservices, I asked in 2018 — because a sprawl of dozens or hundreds of microservices creates genuine problems of discovery, dependency management, consistency, and governance. The monorepo-versus-multirepo debates, the question of how to track dependencies across services, the challenge of keeping APIs consistent across a fleet of independently-developed services — these are the operational realities of microservices at scale. GitHub became your asynchronous microservice showroom, as I put it, the place where the documentation and definitions of all your services could live and be discovered. The microservices sprawl is, in essence, the same API sprawl and landscape problem I’ve written about extensively, just at the granularity of internal services. Governing a microservices architecture is governing a large, distributed collection of APIs, with all the discovery, consistency, and lifecycle challenges that implies.
The honest, mature assessment, which I reached in writing about what comes after microservices, is that microservices was a useful idea that the industry overapplied, and the pendulum has swung. By 2023 I was asking what comes after microservices, because the industry had begun to recognize that microservices weren’t right for everyone — that many organizations had created distributed monoliths, added enormous operational complexity, and gotten the worst of both worlds by chasing microservices without the organizational discipline or the actual need. The reaction against microservices, the return to “majestic monoliths” and more pragmatic middle grounds, is the healthy correction to the hype. My settled view is that microservices is a genuinely valuable architectural pattern for organizations that have a real need for independent scalability and deployment and that are willing to do the organizational decoupling it requires — and a costly mistake for organizations that adopt it as a fad without that need or that discipline. The APIs are central to it either way; microservices is an architecture built out of APIs, and the quality of a microservices implementation is fundamentally the quality of its API design and its organizational discipline. The technology was never the hard part. It never is.
References
- The Secret To Amazon’s Success: Internal APIs
- Here We Go Again: SOA And API — We Have Already Done This
- On APIs And Microservices
- Are Your APIs Ready For The Coming Containerization Evolution Of The API Space
- Your Microservices Effort Will Fail Just Like Your API And SOA Initiatives
- Your Microservices Effort Will Fail Because You Will Never Decouple Your Business
- OpenAPI Is The Contract For Your Microservice
- GitHub Is Your Asynchronous Microservice Showroom
- How Should We Be Organizing All Of Our Microservices
- What Comes After Microservices
