Microservices vs. the monolith

Microservices is a software architecture that brings together some of the styles used in SOA (service-oriented architecture) but without the standard dependency on ESB and centralized governance. Instead, Microservices is an architectural style for building distributed applications made up of lightweight components communicating via "smart endpoints and dumb pipes."

Martin Fowler and James Lewis described Microservices in an introductory article published this spring:

In short, 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 [...] There is a bare mininum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

A microservices architecture is easily contrasted to what Fowler and Lewis call a monolithic architecture -- the traditional server-side Java system. Whereas a monolithic architecture puts all of its functionality into a single process, which it then replicates across multiple servers, a microservices architecture puts its functionality into different processes, which are distributed across as many servers as the system requires.

While Microservices is closely related to SOA, Fowler and Lewis argue that its different enough to merit having its own name, as defined by these qualities:

  • Componentization via services
  • Organized around business capabilities
  • Products not projects
  • Smart endpoints and dumb pipes
  • Decentralized governance
  • Decentralized data management
  • Infrastructure automation
  • Design for failure
  • Evolutionary design

Learn more about the Microservices architectural style, starting with the overview by Fowler and Lewis. Also see "Microservices are not a free lunch!" (Benjamin Wootton, September 2013), which addresses some of the challenges of Microservices, including operations overhead, duplicated efforts, and the inherent asynchronicity of the architecture.

This story, "Microservices vs. the monolith " was originally published by Java Everywhere.