Service-based architecture and service-oriented architecture

Between the monolith and microservices

Much of the industry conversation presents a choice between one monolith and many microservices. In practice a large share of real systems sit in between: a handful of separately deployed services, each covering a whole business area, often still sharing one database. Mark Richards and Neal Ford named this style service-based architecture in Fundamentals of Software Architecture and argue that it is one of the most pragmatic distributed styles available. This section describes it, contrasts it with the older service-oriented architecture (SOA) that it is often confused with, and shows where microservices differ from both.

Service-based architecture: the topology

A service-based system has three parts. One or more user interfaces call a set of separately deployed domain services, each covering a large, coherent business area such as ordering or payments. Richards and Ford observe that such systems usually have between 4 and 12 domain services, about 7 on average. The services usually share a database, and an optional API layer (a reverse proxy or gateway) may sit between the user interfaces and the services to handle routing, authentication and rate limiting.

Each domain service is coarse-grained: it contains everything needed for its domain, from the API to the business logic to the data access, and it is internally structured like a small monolith, often in layers or in modules (Chapter 5). A service is typically deployed as a few instances behind a load balancer.

Two consequences follow. First, most business workflows run entirely inside one service, so they can use an ordinary local database transaction with full ACID guarantees (Chapter 0). Second, domain services rarely need to call each other: a request from the user interface goes to the one service that owns the domain. This keeps synchronous chains short, which matters for the reasons calculated in Section 6.1.

The shared database and how to tame it

Sharing a database is what makes service-based architecture cheap and simple: no data synchronisation between services, no eventual consistency, reporting by ordinary SQL. It is also its main weakness. If every service reads and writes the same tables, a change to one table's columns may break several services, all of which must then be tested and redeployed together. Chapter 5's definition applies: services sharing a database are bound into one architecture quantum, so they share one level of availability and one schema release cadence.

Practitioners use three techniques to reduce the coupling. The first is logical partitioning: give each service its own schema (or set of tables) and forbid it to touch anyone else's, enforced by database permissions as well as by convention. The second is to keep the shared database's entity classes in small, per-domain libraries rather than one large shared library, so that a change to restaurant tables only affects the services that use them. The third is to give a service its own database when it has a strong reason, such as security scope, a very different load pattern or a different kind of data store. Teams that apply these consistently find that a later move to separate databases, if it ever becomes necessary, is much easier.

Classic service-oriented architecture

Service-oriented architecture is older and broader. The term entered the industry through a 1996 Gartner report by Roy Schulte and Yefim Natis, and from the early 2000s it became the dominant model for enterprise integration. Its central idea was sound: expose business capabilities as services with explicit, technology-neutral contracts, so that applications across a large organisation can be assembled from them instead of being rebuilt or integrated point to point.

What most enterprises actually built, however, was what Richards and Ford call orchestration-driven SOA. Services were arranged in technical layers: business services describing processes (place order, open account), shared enterprise services providing reusable capabilities (customer, pricing, invoice), and application and infrastructure services wrapping existing systems and technical concerns. At the centre sat an enterprise service bus (ESB): middleware that routed messages, transformed them between formats, mediated between protocols and, through an orchestration engine, ran the business processes themselves.

Two further ideas completed the picture. A canonical data model defined one enterprise-wide representation of each business entity (one Customer, one Order), and every message was translated to and from it in the bus. And a family of web-service standards, usually called WS-*, defined how services described and called each other: SOAP for messages, WSDL for interface descriptions, UDDI for registries, WS-Security, WS-ReliableMessaging and WS-AtomicTransaction for qualities, and WS-BPEL (version 2.0 approved by OASIS in 2007) for executable process definitions.

Why classic SOA fell out of favour

By the late 2000s many SOA programmes had disappointed. Anne Thomas Manes of the Burton Group captured the mood in a widely read January 2009 post titled SOA is Dead; Long Live Services: the label had become toxic, but the idea of services survived. The reasons are worth knowing, because each is a trap that modern architectures can fall into again.

Reuse created coupling. A shared enterprise Customer service used by forty applications could not change without forty consumers agreeing; reuse, the main goal, turned every change into a negotiation. The bus became the bottleneck. Putting routing, transformation and process logic into a central ESB, usually owned by one integration team, meant that almost every business change needed that team, and the bus became a single point of failure and of delay. The canonical model was too big. One definition of Customer that satisfies sales, billing, support and logistics is either enormous or wrong for most of them; Chapter 5's bounded contexts explain why a term legitimately means different things in different parts of a business. The standards were heavy. WS-* specifications were complex, tooling was expensive, and distributed transactions across services proved fragile. Technical partitioning meant a simple feature crossed several layers of services owned by different groups.

The lasting lessons are the ones microservices were built on: explicit service contracts, services owned by the people who build them, logic in the services rather than in the middleware, and data owned by one service rather than shared across the enterprise.

How microservices differ

Microservices, covered in depth in the next section, keep SOA's idea of services with explicit contracts and reverse most of its implementation choices. James Lewis and Martin Fowler summarised one reversal as smart endpoints and dumb pipes: the network only transports messages, and all logic lives in the services. Services are organised around business capabilities rather than technical layers, reuse is deliberately secondary to independence, each service owns its data, and governance is decentralised.

Compared with service-based architecture, microservices are finer-grained, far more numerous, and insist on separate data. That buys more independence, more targeted scaling and more fault isolation, and it costs much more in operations, consistency and coordination. Service-based architecture can be seen as the point on the spectrum where most of the deployment and team benefits arrive for a fraction of the cost.

When service-based architecture is the pragmatic middle ground

Choose it when the system has a few clear business domains, when two to perhaps eight teams need to release independently, when most workflows naturally stay inside one domain, and when strong consistency within a domain is valuable. It is also an excellent migration step out of a monolith: carving a well-modularised monolith into a handful of domain services is far less risky than leaping to fifty microservices, and the result is often good enough to stop there.

Avoid it, or plan to move beyond it, when parts of a domain need very different scalability or availability (they belong in separate quanta), when dozens of teams need autonomy, when the shared database has become the bottleneck for writes, or when the domain services keep calling each other to complete ordinary requests, which is a sign that the boundaries are wrong.