By the end of the lesson, you can explain what SOA means, how it is similar to and different from microservices, and why it is regarded as a historical precursor of splitting into services.
Why is it worth knowing SOA?
"Service" as a building block did not appear with microservices. SOA was the first widespread attempt to assemble larger systems from separate, network-accessible capabilities. Whoever wants to understand microservices needs to see what was considered the problem of SOA.
What is SOA?
SOA (service-oriented architecture) is, according to the OASIS (Organization for the Advancement of Structured Information Standards) reference model, "a paradigm for organizing and utilizing distributed capabilities" that may be under the control of different ownership domains. A service is the means by which the needs of a consumer are brought together with the capabilities of a provider. The three key concepts of the model are visibility, interaction and real world effect.
SOA is therefore primarily an approach, not a single concrete technology. In practice, enterprise SOA was often realised with a central message broker (ESB, enterprise service bus), standard protocols and centrally governed service contracts.
flowchart LR
A["Application A"] --> E["Central broker (ESB)"]
B["Application B"] --> E
E --> S1["Service 1"]
E --> S2["Service 2"]
How does it relate to microservices?
According to Fowler and Lewis, the microservices style is very similar to what advocates of SOA also proposed, but the word "SOA" means many different things. The difference is typically in where the implementation puts the intelligence:
Aspect
Typical enterprise SOA
Microservices
Where is the "smartness"?
In the central broker (routing, transformation, rules)
In the endpoints; the channel is simple ("smart endpoints, dumb pipes")
Governance
Central, standardised contracts
Distributed, per team
Service size
Often large, an enterprise capability
One business capability, owned by a small team
Data
Often shared data stores
Data per service
According to the critique of Fowler and Lewis, SOA implementations often hid the complexity in the ESB, and the central standards reached a complexity that is "frankly, breathtaking". This central broker became both a bottleneck and an obstacle to change.
By aspect
Aspect
Typical SOA
Coupling
Contractual, but strong dependence can develop through the broker
Deployability
Per service, but the central layer is a shared release point
Data management
Often shared data
Failure handling
The central broker can be a single point of failure
Cost
High organisational and tooling cost
Common misconceptions
Statement
Clarification
"SOA equals web services."
SOA is an approach; a web service is only one possible implementation.
"SOA always means an ESB."
A common implementation, but not a necessity.
"SOA is obsolete, microservices are completely different."
The two styles have common roots; the difference is the degree of centralisation.
In short
SOA is the approach of organising distributed capabilities through services.
Enterprise implementations were often based on a central broker (ESB) and central standards.
The microservices style realises the principles of SOA in a more decentralised way.
The central layer can be a bottleneck and an obstacle to change.
Review questions
What does it mean that SOA is an approach, not a technology?
Where is the "smartness" in an ESB-based SOA, and where in a microservices system?
SOA: Service-Oriented Architecture
Objectives
By the end of the lesson, you can explain what SOA means, how it is similar to and different from microservices, and why it is regarded as a historical precursor of splitting into services.
Why is it worth knowing SOA?
"Service" as a building block did not appear with microservices. SOA was the first widespread attempt to assemble larger systems from separate, network-accessible capabilities. Whoever wants to understand microservices needs to see what was considered the problem of SOA.
What is SOA?
SOA (service-oriented architecture) is, according to the OASIS (Organization for the Advancement of Structured Information Standards) reference model, "a paradigm for organizing and utilizing distributed capabilities" that may be under the control of different ownership domains. A service is the means by which the needs of a consumer are brought together with the capabilities of a provider. The three key concepts of the model are visibility, interaction and real world effect.
SOA is therefore primarily an approach, not a single concrete technology. In practice, enterprise SOA was often realised with a central message broker (ESB, enterprise service bus), standard protocols and centrally governed service contracts.
How does it relate to microservices?
According to Fowler and Lewis, the microservices style is very similar to what advocates of SOA also proposed, but the word "SOA" means many different things. The difference is typically in where the implementation puts the intelligence:
According to the critique of Fowler and Lewis, SOA implementations often hid the complexity in the ESB, and the central standards reached a complexity that is "frankly, breathtaking". This central broker became both a bottleneck and an obstacle to change.
By aspect
Common misconceptions
In short
Review questions
Learning resources