The term “microservices” was given its canonical definition in a 2014 article by James Lewis and Martin Fowler, published on Fowler’s own site on March 25, 2014. They wrote that “the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.”
The point of contrast is the monolith: a single large application where all the code is built, deployed, and scaled as one unit. In a microservices architecture, the application is instead decomposed into many small services, each built around a business capability, each independently deployable, and each potentially written in a different language or backed by a different data store. Lewis and Fowler stressed that these services require only “a bare minimum of centralized management.”
This independence is the source of the style’s appeal. Teams can deploy and scale individual services without coordinating a release of the whole system, and a failure in one service need not bring down the others. The approach became closely associated with the cloud era, where containers and orchestrators made it practical to run and coordinate large numbers of small services.
Fowler and Lewis were careful not to oversell it. The article and Fowler’s later writing note that microservices carry real operational costs: the complexity of a distributed system, network calls that can fail, data consistency that is harder to maintain across service boundaries, and the monitoring and deployment machinery needed to manage many moving parts. The style trades the simplicity of a monolith for flexibility, and that trade is not always worth making.