Microservices

framework · computer science · organizing-schema

Architectural style decomposing applications into small, independently deployable services.

Microservices is the architectural style in which an application is composed of small, independently deployable services that communicate through well-defined APIs (typically HTTP/REST or message-based), each owned by a small team and responsible for a single business capability. The term was popularized by James Lewis and Martin Fowler's 2014 article 'Microservices' (martinfowler.com), which articulated nine characteristics including componentization via services, organized around business capabilities, products not projects, smart endpoints and dumb pipes, decentralized governance and data management, infrastructure automation, design for failure, and evolutionary design. The style emerged from earlier service-oriented architecture (SOA) but with deliberately lighter-weight communication, smaller services, and stronger team-ownership ('you build it, you run it'), enabled by container technology (Docker), orchestration (Kubernetes), and continuous-deployment practices. Conway's Law — that organizations design systems mirroring their communication structures — is essential to thinking about microservices: the architecture both reflects and shapes team boundaries.

Originators

James Lewis; Martin Fowler (codification); Adrian Cockcroft (Netflix architecture lead, foundational practice); broader practice at Netflix, Amazon, Spotify, and Etsy in early 2010s high

Year / Decade

Early 2010s practice emergence; 2014 (Lewis-Fowler codification article) high

Primary sources

Lewis, J. & Fowler, M. (2014). 'Microservices' (martinfowler.com), Newman, S. (2015). Building Microservices, Newman, S. (2019). Monolith to Microservices high

Core components

Small services owned by small teams
Independent deployment
Business-capability decomposition (often via DDD bounded contexts)
Service communication via well-defined APIs (HTTP/REST or async messaging)
Decentralized governance and data ownership
Infrastructure automation (containers, orchestration)
Design for failure (circuit breakers, retries, timeouts)
Polyglot persistence and polyglot programming
Conway's Law alignment with team structure

Primary use case

Large-scale internet applications with substantial development teams; organizations enabling independent team velocity; complex domains where bounded contexts naturally decompose; applications requiring independent scaling of components; foundation for cloud-native development; basis for many DevOps and Site Reliability Engineering practices.

Common criticisms

Substantial operational complexity that smaller organizations struggle to manage — distributed systems, distributed tracing, service discovery, secrets management, monitoring complexity all become essential
risk of distributed monolith (services tightly coupled at runtime despite separate deployment)
inappropriate decomposition (too small services, wrong boundaries) is common and difficult to reverse
data consistency across services is hard, often requiring eventual consistency or distributed transactions
teams without DevOps and platform engineering capability often fail to operate microservices effectively
many organizations adopting microservices for organizational reasons (scaling teams) attempt complexity their problem doesn't justify
recent counter-trend toward modular monolith for many domains.

Lineage

Child of: Service-Oriented Architecture
Siblings: Service-Oriented Architecture, Domain-Driven Design, Twelve-Factor App, Event-Driven Architecture
Derived from: Service-Oriented Architecture