Microservices Patterns Overview

1. What a pattern is, and how patterns are structured

A pattern is a reusable solution to a problem that occurs in a particular context. Microservices patterns are high-level design patterns, where the solution consists of collaborating services. The module’s overview is based on chapter 1 of Richardson’s Microservices Patterns [MP].

Each pattern has a standard structure:

• Forces — the issues that you must address when solving a problem in a given context.
• Resulting context — the consequences of applying the pattern, including:
  • Benefits — the forces that have been resolved;
  • Drawbacks — the unresolved forces;
  • Issues — the new problems introduced by applying the pattern.
• Related patterns — the relationships between patterns: successor, predecessor, specialization, generalization, grouping.

2. The pattern catalogue and its three layers

The patterns are grouped based on the kind of problem they solve:

1. Patterns for decomposing an application into services
2. Communication patterns
3. Data consistency patterns for implementing transaction management
4. Patterns for querying data in a microservice architecture
5. Service deployment patterns
6. Observability patterns providing insight into application behaviour
7. Patterns for the automated testing of services
8. Patterns for handling cross-cutting concerns
9. Security patterns

The catalogue is divided into three layers, according to who is affected:

3. Patterns for decomposing an application into services

The strategies to decompose a system into a set of services were discussed in module 2.2 (Chapter 9):

• Decomposition by business capabilities — define a service for each business capability or group of related capabilities.
• Decomposition by subdomains — apply DDD and define a service for each subdomain, with its own domain model and bounded context.

Both are themselves patterns in the catalogue — and the module points out that they are only the first step: the rest of the catalogue exists because decomposing an application creates a whole family of new problems.

4. Communication patterns

Communication patterns cover a variety of architectural and design decisions about how your services communicate with one another and the outside world. The module groups them into five communication groups:

The first group — communication style — was already covered in Chapter 9 (interaction styles and IPC technologies: REST, gRPC, messaging, GraphQL). The remaining four groups give the questions the patterns answer: discovery (how a client of a service determines the IP address of a service instance so that it can make an HTTP request), reliability (how to keep communication reliable even though services can be unavailable — the Circuit Breaker pattern), transactional messaging (how to integrate the sending of messages and publishing of events with the database transactions that update business data), and external API (how the application’s clients communicate with the services — the API Gateway pattern).

5. Data consistency patterns for transaction management

In microservices, to ensure loose coupling, each service has its own database — which poses the problem: how to preserve data consistency across services? The traditional approach of using distributed transactions (two-phase commit) isn’t a viable option for a modern application.

Among the patterns in this group:

• Saga — preserves data consistency across services: a sequence of local transactions coordinated using messaging; sagas are eventually consistent.
• Event Sourcing — models persistence using events: the state of a business entity is derived from the sequence of events that happened to it, instead of being stored as a single snapshot.

6. Patterns for querying data

Often in microservices, queries need to query and join data owned by multiple services — and we can’t use distributed queries against the services’ databases. Among the patterns:

• API composition — invokes the APIs of one or more services and aggregates the results.
• Command Query Responsibility Segregation (CQRS) — maintains one or more easily queried replicas of the data, updated through events.

7. Service deployment patterns

Deploying a microservices-based application is complex: there may be tens or hundreds of services written in a variety of languages and frameworks, and many more moving parts to manage. The traditional — and often manual — way of deploying applications in a language-specific packaging format (for example WAR files) doesn’t scale to support a microservice architecture: a highly automated deployment infrastructure is needed. Ideally, a deployment platform should provide the developer with a simple UI (command-line or GUI) for deploying and managing their services.

Several patterns exist for deploying microservices:

• the traditional approach: deploy services in a language-specific packaging format;
• two modern approaches:
  1. deploy services as VMs or containers;
  2. the serverless approach — we simply upload the service’s code and the serverless platform runs it.

In any case, a service deployment platform is needed: an automated, self-service platform for deploying and managing services.

8. Observability patterns

A key part of operating an application is monitoring and understanding its runtime behaviour — observability — for diagnosing and troubleshooting problems (failed requests, high latency) and, more generally, for ensuring quality attributes. Observability is more challenging in microservices systems than in monolithic ones: a request can bounce around between multiple services before a response is finally returned to a client, so there isn’t one log file to examine, and latency problems are harder to diagnose because there are multiple suspects.

The patterns to design observable services:

• Health check API — expose an endpoint that returns the health of the service.
• Log aggregation — log service activity and write logs into a centralized logging server, which provides searching and alerting.
• Distributed tracing — assign each external request a unique ID and trace requests as they flow between services.
• Exception tracking — report exceptions to an exception tracking service, which deduplicates exceptions, alerts developers, and tracks the resolution of each exception.
• Application metrics — maintain metrics, such as counters and gauges, and expose them to a metrics server.
• Audit logging — log user actions.

9. Patterns for the automated testing of services

The microservices architecture makes individual services easier to test because they are much smaller than the monolithic application. At the same time, it is important to test that the different services work together — while avoiding complex, slow and brittle end-to-end tests that test multiple services together. The patterns simplify testing by testing services in isolation:

• Consumer-driven contract test — verifies that a service meets the expectations of its clients.
• Consumer-side contract test — verifies that the client of a service can communicate with the service.
• Service component test — tests a service in isolation.

10. Patterns for handling cross-cutting concerns

In a microservices architecture there are numerous concerns that every service must implement — including the observability patterns and the discovery patterns. It must also implement the Externalized Configuration pattern, which supplies configuration parameters such as database credentials to a service at runtime.

When developing a new service, it would be far too time-consuming to reimplement these concerns from scratch: a much better approach is to apply the Microservice Chassis pattern and build services on top of a framework that handles these concerns for them.

11. Security patterns

In a microservices architecture, users are typically authenticated by the API gateway. It must then pass information about the user — such as identity and roles — to the services it invokes. A common solution is the Access Token pattern: the API gateway passes an access token, such as a JWT (JSON Web Token), to the services, which can validate the token and obtain information about the user.

12. Architecture, process and organisation

Besides choosing the right architecture, a main concern of software architects is process and organisation: an architecture succeeds only if the teams and the delivery process fit it.

Software development and delivery organisation

Large teams have communication trouble: Fred Brooks noted in The Mythical Man-Month that the communication overhead of a team of size N is O(N²). If the team gets too large it becomes inefficient — imagine trying to do a daily standup with 20 people. The solution is to refactor a large single team into a team of teams:

• each team is small, no more than 8–12 people;
• it has a clearly defined business-oriented mission — developing and possibly operating one or more services that implement a feature or a business capability;
• the team is cross-functional and can develop, test and deploy its services without having to frequently communicate or coordinate with other teams.

Small teams bring two benefits. Higher velocity: the microservices architecture enables the teams to be autonomous — each team can develop, deploy and scale its services without coordinating with others, and it is very clear who to contact when a service isn’t meeting its SLA. Higher scalability of the organisation: we grow the organisation by adding teams; if a team becomes too large, we split it and its associated service or services; because teams are loosely coupled, we can add people without impacting productivity.

Software development and delivery process

Several approaches exist in the literature; the natural choices when developing an application with the microservice architecture are agile development and deployment practices (such as Scrum or Kanban) and DevOps, to practise continuous delivery/deployment. The microservice architecture directly supports them:

• Continuous delivery — the ability to get changes of all types (new features, configuration changes, bug fixes, experiments) into production safely and quickly in a sustainable way. A key characteristic: software is always releasable. It relies on a high level of automation, including automated testing.
• Continuous deployment — takes continuous delivery one step further: automatically deploying releasable code into production. High-performing organisations deploy multiple times per day, have far fewer production outages, and recover quickly from any that do occur.

The goal of continuous delivery/deployment — and, more generally, of DevOps, “move fast without breaking things” — is to deliver software rapidly yet reliably. Four useful metrics assess software development:

In a traditional organisation the deployment frequency is low and the lead time is high; a DevOps organisation releases frequently, often multiple times per day, with far fewer production issues. The module’s data points: Amazon deployed changes into production every 11.6 seconds in 2014, and Netflix had a lead time of 16 minutes for one software component.

Check your understanding