Comparing Architectural Characteristics of Microservices and SOA

Comparing Architectural Characteristics

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

Understanding architectural patterns helps make these decisions. Each pattern defines a topology that describes component relationships, communication, and collaboration. By analyzing topologies you can choose the pattern that best fits your application.

This chapter focuses on the differences between microservices and SOA in overall topology, decisive pattern attributes, component sharing degree, communication level, and typical remote access methods. It also compares the message‑middleware commonly used in SOA with the optional API layer found in microservices.

Component Sharing

SOA follows a "share‑as‑much‑as‑possible" style, while microservices adopt a "share‑as‑little‑as‑possible" approach. In SOA, shared components (enterprise services) are central; for example, a large retailer may have separate Order services for each application, leading to duplicated business logic and multiple databases.

SOA would introduce a shared Enterprise Order service that all applications use, but the service still accesses each application's database, creating tight coupling and higher change risk. Microservices, by contrast, use bounded contexts to keep services and their data tightly coupled within a self‑contained unit, exposing only well‑defined interfaces.

Even though some foundational services may be shared, microservices minimize sharing, sometimes duplicating functionality across services or compiling shared modules into libraries. This reduces inter‑service dependencies, simplifies deployment, and improves stability.

Service Orchestration and Choreography

Orchestration involves a central coordinator (e.g., an integration hub like Mule, Camel, or Spring Integration) that directs service interactions, analogous to a conductor leading an orchestra. Choreography relies on peer‑to‑peer service calls without a central controller, similar to dancers synchronizing without a director.

Microservices tend to favor choreography because their topology lacks a central middleware component. Excessive choreography can increase efferent coupling, leading to performance degradation and reliability issues due to multiple remote calls.

To mitigate this, fine‑grained services can be merged into coarse‑grained services, reducing remote calls, improving performance, stability, and simplifying deployment.

Middleware and API Layer

SOA uses message‑middleware (enterprise service bus) for service coordination, providing mediation, routing, message enhancement, transformation, and protocol conversion. Microservices replace this with an API layer that abstracts service locations and shields clients from changes in service granularity.

The API layer enables clients to remain unchanged when a service is split into multiple finer services. Conversely, SOA’s middleware can perform advanced functions such as message enrichment (e.g., converting CUSIP codes to SEDOL) and protocol translation, capabilities that microservices typically lack.

Remote Service Access

Microservices usually standardize on REST (and simple messaging protocols) for remote access, keeping the protocol landscape simple. SOA imposes fewer restrictions and often supports multiple protocols (SOAP, JMS, AMQP, etc.), allowing heterogeneous communication but adding complexity.

Both styles require mechanisms for clients to invoke remote services, but their differing philosophies on sharing, coordination, and protocol usage lead to distinct trade‑offs in performance, development effort, testing, and operational overhead.