Microservices

Noun · Development · Origin: 2011

Definitions

  1. Microservices is an architectural style that structures an application as a collection of small, independent services, each running in its own process and communicating over lightweight protocols such as HTTP or message queues. Each service is focused on a single business capability, owns its own data store, and can be developed, deployed, and scaled independently by a small team. This contrasts with monolithic architecture, where all functionality resides in a single deployable unit. Microservices offer benefits including independent deployability, technology flexibility (different services can use different languages and databases), fault isolation (a failure in one service does not bring down the entire application), and the ability to scale individual components based on their specific load patterns. However, microservices introduce complexity in areas like distributed data management, inter-service communication, network latency, monitoring, and debugging. Teams typically adopt supporting infrastructure including API gateways, service meshes, centralized logging, distributed tracing, and container orchestration platforms like Kubernetes to manage the operational overhead.

    In plain English: Building software as many small, separate pieces that each do one thing, instead of one big program that does everything. Easier to update individually, harder to keep track of.

    Example: "We broke the monolith into 47 microservices. Now instead of one thing to fix, we have 47 things that can break."

Etymology

2005
Peter Rodgers presents 'micro-web-services' at a conference, proposing fine-grained service decomposition.
2011
A workshop near Venice coins the term 'microservices.' Martin Fowler and James Lewis later formalize the definition.
2013
Netflix, Amazon, and other web-scale companies publicly share microservices architecture patterns, driving widespread adoption.
2020s
The complexity costs of microservices become clearer. Teams adopt modular monoliths and debate when microservices are actually warranted.

Origin Story

Small, independent services that replaced the monolith (and added new problems)

The term **microservices** was discussed at a software architecture workshop near Venice in May 2011, where several attendees realized they were all converging on the same architectural pattern: building applications as suites of small, independently deployable services. **James Lewis** and **Martin Fowler** wrote the definitive blog post defining the pattern in March 2014.

The concept evolved from **Service-Oriented Architecture** (SOA), which had similar goals but was associated with heavyweight enterprise middleware (SOAP, ESBs, XML schemas). Microservices shed this baggage: services communicated over simple HTTP/JSON, were small enough for one team to own, and could be deployed independently. Netflix, Amazon, and other web-scale companies were already doing this; the architecture workshop gave it a name.

Microservices solved the monolith's scaling and deployment problems but introduced new ones: distributed tracing, service discovery, network failures, eventual consistency, and the operational complexity of managing dozens or hundreds of services. The industry joke became: "We replaced our monolith's problems with 200 microservices' problems."

Coined by: James Lewis, Martin Fowler (defined); Venice workshop participants (named)

Context: Software architecture workshop, Venice area, May 2011

Fun fact: Amazon's transition to microservices was driven by a 2002 mandate from Jeff Bezos requiring all teams to communicate exclusively through service interfaces. This 'Bezos API Mandate' is considered one of the most consequential internal memos in tech history.

Related Terms