Microservices vs. SOA: Component Sharing, Service Orchestration, and Middleware Differences

Components are the building blocks of software architectures; in service‑oriented designs they are often called services. When designing an architecture you must decide how components are shared, how they communicate, and how they are integrated to fulfill business requests.

Microservices and SOA differ fundamentally in component sharing: SOA follows a "share‑as‑much‑as‑possible" style, while microservices adopt a "share‑as‑little‑as‑possible" approach, often using bounded contexts to keep services self‑contained with well‑defined interfaces.

Service orchestration (centralized coordination) and choreography (decentralized coordination) are explained with analogies to an orchestra conductor and a dance troupe. Microservices tend to favor choreography because they avoid a central middleware component, whereas SOA commonly relies on orchestration through integration hubs.

The article discusses how excessive choreography in microservices can increase efferent coupling, leading to performance degradation and reliability issues, and suggests merging fine‑grained services into coarse‑grained ones to reduce coupling.

In SOA, a message‑middleware component provides mediation, routing, message enhancement, transformation, and protocol conversion, capabilities that microservices typically lack. Instead, microservices use an API layer as a front‑end abstraction, simplifying client interactions and allowing service granularity to evolve without breaking clients.

Remote service access also differs: microservices usually standardize on REST (and simple messaging) while SOA supports a broader range of protocols, including SOAP, JMS, AMQP, and can mix multiple protocols within the same system.

Overall, the comparison highlights how microservices aim for simplicity, loose coupling, and independent deployment, whereas SOA emphasizes extensive sharing, centralized coordination, and rich middleware capabilities.