James Lewis and Martin Fowler gave the style its reference description in 2014: a single application developed as a suite of small services, each in its own process, communicating through lightweight mechanisms, often an HTTP resource API. The nine characteristics they listed still define it: services as components, teams organised around business capabilities rather than technical layers, products not projects, smart endpoints and dumb pipes, decentralised governance and data, infrastructure automation, design for failure and evolutionary design. The unit of deployment shrinks from the application to the service, and that one change drives everything else.
Three things change when the application is cut into processes. Deployment becomes independent: the payments team ships on Tuesday without waiting for the search team's release, which is the benefit the style is bought for. Data becomes distributed: each service owns its tables, a report that joined two of them with one SQL statement now needs an API call or a copied dataset, and a transaction across services is no longer a transaction. Failure becomes partial: a call over the network can time out or return an old answer, and every service must decide what to do when a neighbour is down. The last two are the engineering cost of the first.
| Concern | Monolith | Microservices |
|---|---|---|
| Deployment | One artefact, one release train | One artefact per service, released independently |
| Data | One database, joins and transactions | A store per service; joins become API calls |
| Failure | A function call either works or throws | Network calls time out; retries, timeouts and fallbacks are code |
| Team shape | Shared codebase, coordination by review | A team per service, coordination by contract |
| Operations | One process to run and watch | Containers, orchestration, tracing across processes |
The operational overhead is why the style is accompanied by containers, Kubernetes and a tracing system that follows one request through ten processes; a team without those capabilities is not ready, regardless of the architecture diagram. The usual failure is the distributed monolith: services split along the wrong lines that must all be deployed together and share a database, which keeps every cost and discards every benefit. Fowler's advice from 2015 holds: build the monolith first, keep its modules honest, and extract a service when a part of the system needs its own release cadence, its own scaling or its own team. Cloud exams cover the style from the platform side; the AWS Developer Associate scope includes building services and the messaging between them, and the pipeline and delivery courses cover the machinery it requires.