The Microservice Definition Problem
By late 2013, "microservices" had become a common topic of discussion, but no clear definition existed to anchor those conversations — a problem that had previously caused significant confusion with SOA. Martin Fowler and James Lewis set out to fix that by documenting what they observed in the field, producing a definition based on the common characteristics found in real microservice architectures.
That work yielded the now-standard description: an application built as a collection of small services, each running in its own process, communicating through lightweight mechanisms such as an HTTP resource API. These services are organized around business capabilities, independently deployable through fully automated deployment machinery, and subject to a bare minimum of centralized management. Teams working this way can use different programming languages and data storage technologies for different services.
The defining characteristics identified in that research:
- Componentization via services
- Organization around business capabilities
- Products, not projects
- Smart endpoints and dumb pipes
- Decentralized governance
- Decentralized data management
- Infrastructure automation
- Design for failure
- Evolutionary design
That article also addressed the recurring practical questions, including how large a microservice should be and how the style differs from service-oriented architecture. A short introductory talk (~25 minutes) covers the most important defining characteristics, contrasts microservices with monoliths, and highlights what must be in place before deploying a first microservice system to production.
Evaluating the Trade-Offs
Microservices, like any architectural style, come with strengths and weaknesses that must be weighed against the context in which they are used. Despite the popularity of the style, many — indeed most — situations would be better served by a monolith.
Where Microservices Help
- Strong module boundaries: Microservices reinforce modular structure, which matters most for larger teams.
- Independent deployment: Simpler services are easier to deploy, and because they are autonomous, a failure in one is less likely to bring down the whole system.
- Technology diversity: Teams can mix multiple languages, development frameworks, and data-storage technologies across services.
The Costs That Come With Them
- Distribution: Distributed systems are harder to program; remote calls are slow and always at risk of failure.
- Eventual consistency: Strong consistency is extremely difficult to maintain in a distributed system, so everyone must manage eventual consistency instead.
- Operational complexity: A mature operations team is required to manage many services that are redeployed regularly.
The Microservice Premium
The microservices architectural style generated intense interest, and at times it seemed every session at major architecture conferences was about microservices. That enthusiasm led some teams to adopt the style too eagerly, without recognizing that microservices introduce complexity of their own. That complexity adds a premium to a project's cost and risk — one that frequently gets projects into serious trouble.
