Oh My Learning

SOA and Microservices

fundamentals/18 senior drafted · 5 min read

Fundamentals of Software Architecture (Richards & Ford, O'Reilly 2nd ed. 2025), Chapter 18

Prerequisites fundamentals/09 fundamentals/10

SOA and Microservices#

TL;DR#

Service-Oriented Architecture (SOA) and Microservices are both distributed, service-based styles. However, they represent opposing philosophies. SOA focus on enterprise reusability through a centralized broker, whereas Microservices prioritizes extreme service decoupling and team autonomy.

The idea#

Many engineers assume SOA and Microservices are identical because both split code into services. This is a critical misconception. They serve completely different goals and organizational structures.

SOA is an enterprise-wide integration style. It focuses on reusability, aiming to make legacy mainframe applications and modern web tools talk to each other. A central service broker accomplishes this by translating protocols and orchestrating complex business processes.

Microservices is an application-specific style. It focuses on rapid feature delivery and team autonomy. Instead of relying on a central coordinator, it enforces absolute isolation. Services remain tiny, communicate over lightweight network protocols, and must own their databases.

How it works#

Let's examine how both styles handle coordination, databases, and governance.

Service-Oriented Architecture (SOA)#

SOA organizes resources into a collection of coarse-grained services. These services share a single database to avoid the pain of copying or syncing data.

The key to SOA is the Enterprise Service Bus (ESB). This smart middleware layer connects all services. It translates protocols (e.g. turning old SOAP XML requests into JSON), handles security, and routes traffic.

Governance in SOA is highly centralized. A central steering committee must approve any API changes, making updates slow but highly standardized.

Microservices Architecture#

Microservices rejects the ESB completely. It follows a "smart endpoints, dumb pipes" philosophy. Services communicate directly using simple, lightweight protocols like REST, gRPC, or event streams.

Crucially, this style enforces strict database isolation. Each service owns its data store, and no other service can access it directly. This boundary prevents database-level coupling but forces the team to manage eventual consistency.

Governance is decentralized. Teams are autonomous, choosing their own programming languages, databases, and release schedules.

Comparison#

Below is an ASCII diagram showing the architectural differences:

SOA PHILOSOPHY:                              MICROSERVICES PHILOSOPHY:
+---------------+                           +-------+       +-------+
|  Enterprise   |                           | Service|     | Service|
|  Service Bus  | (Centralized ESB)         +---+---+       +---+---+
+---+---+---+---+                               |               |
    |   |   |                                   v               v
    v   v   v                               +-------+       +-------+
  [Coarse Services]                         | PrivDB|       | PrivDB| (Strict Isolation)
        |                                   +-------+       +-------+
        v
 [Shared Database]

Architectural characteristics analysis#

Let's analyze how both styles perform across key architectural characteristics:

1. Deployability#

  • SOA: Low. Since services share databases and connect through a central ESB, changes often require coordinated releases across multiple teams.
  • Microservices: High. Strict isolation allows teams to deploy changes independently at any time.

2. Scalability#

  • SOA: Medium. You can scale coarse services, but the central ESB and shared database often become major bottlenecks.
  • Microservices: High. You can scale individual tiny services horizontally without affecting the rest of the application.

3. Elasticity#

  • SOA: Low. Coarse services and heavy middleware have slow startup times, preventing quick automatic scaling.
  • Microservices: High. Small, lightweight containers can spin up in seconds to absorb sudden traffic bursts.

4. Reliability#

  • SOA: Medium. If the ESB goes down, the entire enterprise network collapses.
  • Microservices: Medium to High. While network calls are fragile, excellent fault isolation prevents a crash in one service from taking down the whole system.

5. Performance#

  • SOA: Medium. Message transformations inside the ESB and database locks on shared tables introduce latency.
  • Microservices: Medium to Low. While in-memory speed is absent, network overhead and distributed serialization across multiple hops can slow down requests.

6. Simplicity#

  • SOA: Low. Setting up and configuring enterprise integration patterns inside an ESB is highly complex.
  • Microservices: Low. Managing a distributed network of independent databases, eventual consistency, and distributed tracing is extremely difficult.

7. Cost#

  • SOA: High. Licensing fees for commercial ESBs and powerful database servers are substantial.
  • Microservices: High. Running thousands of independent container instances, API gateways, and distributed monitoring networks requires significant cloud spending.

8. Testability#

  • SOA: Medium. Integrated test environments are needed to test flows through the central ESB.
  • Microservices: Medium to Low. While unit testing a single service is simple, testing an end-to-end distributed transaction is extremely difficult.

9. Team Fit#

  • SOA: Best for traditional hierarchical organizations with separate development, DBA, and middleware teams.
  • Microservices: Best for modern, product-centric organizations with highly autonomous, cross-functional teams.

Pros#

  • SOA:
  • Reusability of legacy systems across the entire enterprise.
  • Simplified data access with standard database sharing.
  • Microservices:
  • Maximum team autonomy and rapid release cycles.
  • Excellent fault isolation and targeted scalability.

Cons#

  • SOA:
  • Centralized bottlenecks in the ESB.
  • Low development velocity due to coordination overhead.
  • Microservices:
  • High complexity of eventual consistency and sagas.
  • Massively increased operational overhead.

Alternatives#

  • Service-Based Architecture: A middle ground that uses coarser-grained services and shares databases without the complexity of an ESB or hundreds of microservices.
  • Modular Monolith: Modules are logically separated inside a single process, avoiding the pain of distributed networking altogether.

When to use it#

Choose SOA when integrating a vast ecosystem of legacy mainframes and modern applications across an entire enterprise.

Choose Microservices when building a large, rapidly growing, web-scale application that demands continuous deployments and highly autonomous development teams.

When NOT to use it#

Avoid SOA for building a brand new, agile web application that needs fast feature releases.

Avoid Microservices for small systems with simple business domains and tiny development teams, where a monolith would save significant operational time and money.

Key takeaways / mental model#

SOA is about enterprise integration and reuse; Microservices is about application decoupling and autonomy. SOA uses smart pipes (ESB) and dumb endpoints; Microservices uses dumb pipes (light network protocols) and smart endpoints.

Self-check questions#

  1. Why does Microservices reject the concept of an Enterprise Service Bus (ESB)?
  2. How does the requirement of database ownership differ between SOA and Microservices?
  3. Why is Microservices considered an application-level style, while SOA is considered an enterprise-level style?

References#

  • Fundamentals of Software Architecture (Richards & Ford, O'Reilly 2nd ed. 2025), Chapter 18