Why Microservices Really Matter: From SOA to Scalable Architecture

Since early last year I have been learning microservices concepts and decided to adopt them for the fourth major version of our system. Recent discussions on microservices have grown because leading internet companies like Amazon and Netflix have successfully applied this large‑scale architecture methodology, which theorists now call Microservices.

Microservices vs. Service‑Oriented Architecture (SOA)

You should instead think of microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.

Before the term microservices was coined, we used the well‑known concept of Service‑Oriented Architecture (SOA). My earlier article on SOA and microservices only gave a vague definition, but a year of practice has clarified their relationship: microservices are essentially a concrete implementation of SOA.

Why Choose Microservices

The main reason is the proven success of this architectural style. “Micro” emphasizes service miniaturization—each service focuses on a single business capability, achieving high cohesion and autonomy.

In previous large applications we used a modular layered architecture with a single codebase deployed together. This caused blurred module boundaries, making high cohesion and loose coupling difficult, and any change often required updates across many modules—an “onion architecture” that tears up like cutting an onion.

Microservices avoid “fat services” that arise from poorly modeled SOA, enforce one process per service, and isolate codebases, reducing accidental cross‑service coupling.

Our system grew to over 400,000 lines of code maintained by a 20‑person team, making bug fixes and feature additions painful. Splitting the system into many microservices keeps each service within a comfortable maintenance size for an average developer.

Implementing Microservices

Deploying one application process on one host has a complexity of 1 × 1 = 1; with 200 hosts it becomes 1 × 200 = 200. Splitting into 50 microservice processes raises the complexity to 50 × 200 = 10,000, increasing deployment and monitoring effort.

Thus microservices entail high cost and are suitable only for sufficiently large systems, which is why they originated in large internet companies. Automation culture—automated build, test, and deployment—is essential to control the multiplicative increase in operational complexity.

Key implementation points include:

Automation culture and environment: automated build, test, deployment.

Model services around business capabilities: loose coupling, high cohesion, expose interfaces while hiding implementation.

Service collaboration models: centralized (orchestra) vs. decentralized (dance) patterns.

Unified service interaction methods: RPC, REST, WS, etc.

Independent deployment, failure isolation, observability.

Flow control: degradation, rate limiting.

Recovery: focus on rapid fault recovery rather than fault avoidance.

Release strategies: canary/gray deployments.

One‑service‑per‑host model supported by virtualization or containerization (Docker, LXC).

Centralized configuration service.

Conway’s Law: architecture reflects organizational communication structure.

Berstaller’s Law: be conservative when sending, open when receiving.

Self‑Evolving Microservice Architecture

Software differs from buildings: it continuously changes throughout its lifecycle. Microservices embrace this by allowing incremental additions, improvements, or replacements of individual services, avoiding costly full‑system rewrites.

Architects act more like city planners, partitioning software into logical zones. Poor early planning can inflate maintenance costs later, just as misplaced facilities in a city create inefficiencies.

Each historic city develops its own character; similarly, microservice ecosystems evolve naturally with changes in people, time, and technology.

Microservices and the Architect

Architects make technical decisions, balancing trade‑offs. Microservices delegate many decisions to service owners, reducing the overall architect’s burden while requiring oversight of service interactions and system health.

When should architects intervene? Like supervising a child learning to ride a bike, they should step in only when a service’s implementation threatens the whole system’s safety.

Architecture serves organizational strategic goals.

Practices evolve into principles that improve efficiency and reduce marginal costs.

Principles should enhance developers’ experience, not make it miserable.

Stay abreast of new technologies to make timely trade‑offs.

Help developers understand the impact of technical decisions, sometimes down to code level.

This is our fourth major version upgrade; previous upgrades resembled moving an entire old city to a new one. Microservices’ natural evolution may indicate this is the final major overhaul—there is no eternal architecture, only evolving architecture, and microservices are not a silver bullet.