Microservices vs SOA – Chap3. Comparing Architecture Characteristics

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

Component Sharing

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.).

3.3 - Service orchestration

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.

3.4 - 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 efferent 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

Message enhancement

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

Message transformation

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.

Protocol transformation

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


2 thoughts on “Microservices vs SOA – Chap3. Comparing Architecture Characteristics

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.