MicroservicesvsService-Oriented Architecture

SOA became popular in the 2000s as a way to connect large enterprise systems. Business functions, such as customer records or billing, are offered as reusable services, often described with SOAP and WSDL and connected through an enterprise service bus (ESB) that routes, transforms and orchestrates messages. Microservices took off in the 2010s at companies like Netflix and Amazon: one application is split into many small services, each built, deployed and scaled by its own team.

The differences are scope and coupling. SOA services are often large and shared across the whole organization, and the ESB holds much of the integration logic, so the bus becomes central and hard to change. Microservices follow the motto "smart endpoints, dumb pipes": each service keeps its own logic and database, and services talk over simple HTTP APIs or message brokers.

Microservices are often described as a refined form of SOA, and they share its core idea of building systems from services with clear interfaces. What changed is the tooling and the culture: containers, Kubernetes, CI/CD and cloud platforms made it practical to deploy hundreds of small services independently, which was hard in the SOA era.

A common misconception is that microservices are always the modern, better choice. They bring network failures, distributed data and operational overhead, and many teams do better with a well-structured monolith, while some SOA ideas, such as reusable shared services, still make sense across a large organization.