This post is part of a series of posts with my personal notes about the chapters in the book “Microservices vs. Service-Oriented Architecture” by Mark Richards.
In this chapter I explore the differences between microservices and SOA in terms of the overall architecture topology and the defining characteristics of the architecture pattern
SOA is built on the concept of a share-as-much-as-possible architecture style, whereas microservices architecture is built on the concept of a share-as-little-as-possible architecture style.
Microservices architecture, being built on the concept of share-as-little-as-possible, leverages a concept from domain-driven design called a bounded context. microservices architecture is a share-nothing architecture with the exception of two things—how services integrate with one another, and the infrastructure plumbing to ensure engineering consistency.
Service Orchestration and Choreography
The term service orchestration refers to the coordination of multiple services through a centralized mediator such as a service consumer or an integration hub (Mule, Camel, Spring Integration, etc.).
Service choreography refers to the coordination of multiple service calls without a central mediator. The term inter-service communication is sometimes used in conjunction with service choreography.
If you find that you need a lot of service choreography between your functional services, chances are your services are too fine-grained.
Too much service choreography in a microservices architecture can lead to high eﬀerent coupling, which is the degree to which one component is dependent on other components to complete a single business request.
One solution to the issue of service choreography among functional services within a microservices architecture is to combine fine-grained services into a more coarse-grained service.
SOA, being a share-as-much-as-possible architecture, relies on both service orchestration and service choreography to process business requests.
Middle-ware vs. API Layer
The microservices architecture pattern typically has what is known as an API layer, whereas SOA has a messaging middle-ware component.
The microservices pattern does not support the concept of messaging middle-ware (e.g., integration hub or enterprise service bus). Rather, it supports the notion of an API layer in front of the services that acts as a service-access facade.
SOA relies on its messaging middle-ware to coordinate service calls. Using messaging middle-ware (what I like to refer to as an integration hub) provides a host of additional architectural capabilities not found in the microservices architecture style, including mediation and routing, message enhancement, message transformation, and protocol transformation.
Mediation and routing
describes the capability of the architecture to locate and invoke a service (or services) based on a specific business or user request
Both microservices and SOA share this capability, particularly with regard to a service registry or service-discovery component. However, with microservices service orchestration is typically minimized or not used at all, whereas with SOA it is frequently used
describes the capability of the architecture to modify, remove, or augment the data portion of a request before it reaches the service
The microservices pattern does not support this capability, primarily because it doesn’t include a middle-ware component to implement this functionality. SOA fully supports this capability through its messaging middle-ware
describes the capability of the architecture to modify the format of the data from one type to other
Again, microservices architecture does not support this capability, but SOA does through the use of the messaging middle-ware.
describes the capability of the architecture to have a service consumer call a service with a protocol that differs from what the service is expecting
Microservices can support multiple protocol types, but the service consumer and service must use the same protocol. In SOA, you can mix and match them as much as you want.
Accessing Remote Services
Microservices architectures usually rely on only two different remote-access protocols to access services — REST and simple messaging (JMS, MSMQ, AMQP, etc.).
SOA architectures typically rely on messaging (e.g., JMS, AMQP, MSMQ) and SOAP as the primary service remote-access protocols
In chapter 4, we will compare Architecture Capabilities of Microservices and SOA