The article that named microservices
By the time Martin Fowler and James Lewis sat down to write about microservices in the spring of 2014, Netflix had already been running hundreds of them for years. The company had broken its streaming platform into a constellation of small, independent services — each one deployable on its own schedule, each one ignorant of the others’ internals. Adrian Cockcroft, Netflix’s cloud architect, had taken to calling this approach “fine-grained SOA,” which was accurate in the way that “horseless carriage” was accurate: technically correct, entirely missing the point.
The gap between a practice and its name is one of the peculiar problems in software. You can build a system for a decade before someone hands you the word that makes it discussable at scale. That word surfaced at an informal workshop of software architects near Venice in May 2011. James Lewis — then as now a principal consultant at ThoughtWorks — was in the room. So were practitioners from Netflix, Amazon, and a handful of shops that had all arrived at similar designs without comparing notes. They tried terms. They came back a year later, in May 2012, and agreed on “microservices.” Lewis had already aired the idea publicly that March, at the 33rd Degree conference in Kraków, in a talk he titled “Microservices — Java, the Unix Way.” The audience was interested. The industry was not yet ready to be.
Two more years passed. By early 2014, the pattern had spread — to The Guardian, to the UK Government Digital Service, to dozens of engineering organisations that had inherited the same structural frustrations from large, tightly coupled codebases. Lewis and Fowler began publishing the article that would stick, adding sections to martinfowler.com across the first three weeks of March. The complete version appeared on 25 March 2014.
What the article accomplished was largely taxonomic. It identified nine characteristics that microservice systems tend to share: services built around single business capabilities, independently deployable, communicating through lightweight HTTP rather than heavyweight middleware, with decentralized governance that let teams choose their own languages and databases, designed to fail without cascading, and expected to evolve rather than be designed up front in full. It rooted all of this in the UNIX philosophy — small composable tools that do one thing and can be wired together without one needing to know the source code of another.
The authors were fastidious about not claiming credit. The article explicitly cited Cockcroft, Joe Walnes, Daniel Terhorst-North, and Graham Tackley — practitioners who had been running microservices before the term existed. It also reached back to Mel Conway’s 1968 paper in Datamation, which observed that organizations produce system architectures that mirror their own communication structures. If your engineers are sorted into database teams, front-end teams, and back-end teams, Conway’s Law predicts the architecture they will build. Microservices, the article suggested, were as much an organizational choice as a technical one.
Within a year the backlash had begun — conference talks about “distributed monoliths,” post-mortems on blast-radius incidents, measured essays arguing that most teams should stay with the monolith until forced to leave. The vocabulary the article had created was now doing enough work to be argued about. That is the most reliable sign that a vocabulary has arrived.
Microservices gave developers a word for what they were building. The word eventually gave them something to blame.
Sources
- Microservices — martinfowler.com (Lewis & Fowler, 25 March 2014) — Primary source: full text of the article, nine characteristics, publication timeline, practitioner citations, and the Conway’s Law framing.
- Microservices: yesterday, today, and tomorrow — arXiv (Dragoni et al., 2016) — Academic survey tracing the May 2011 Venice workshop, James Lewis’s 33rd Degree talk in Kraków (March 2012), and the spread of the pattern before and after the Fowler-Lewis article.