Chapter 1 - Escaping monolithic hell - Microservices Pattern

Scale cube and microservices

definition of the microservice architecture is inspired by Martin Abbott and Michael Fisher’s excellent book, The Art of Scalability (Addison-Wesley, 2015). This book describes a useful, three-dimensional scalability model: the scale cube, shown in figure 1.3.

X-AXIS SCALING LOAD BALANCES REQUESTS ACROSS MULTIPLE INSTANCES

X-axis scaling is a common way to scale a monolithic application. Figure 1.4 shows how X-axis scaling works. You run multiple instances of the application behind a load balancer. The load balancer distributes requests among the N identical instances of the application. This is a great way of improving the capacity and availability of an application

Z-AXIS SCALING ROUTES REQUESTS BASED ON AN ATTRIBUTE OF THE REQUEST

X-axis scaling is a common way to scale a monolithic application. Figure 1.4 shows how X-axis scaling works. You run multiple instances of the application behind a load balancer. The load balancer distributes requests among the N identical instances of the application. This is a great way of improving the capacity and availability of an application

Comparing the microservice architecture and SOA (Service-oriented-architecture)

Some critics of the microservice architecture claim it’s nothing new—it’s service-oriented architecture (SOA). At a very high level, there are some similarities. SOA and the microservice architecture are architectural styles that structure a system as a set of services. But as table 1.1 shows, once you dig deep, you encounter significant differences.

Benefits of the microservice architecture

The microservice architecture has the following benefits:

• It enables the continuous delivery and deployment of large, complex applications.

• Services are small and easily maintained.

• Services are independently deployable.

• Services are independently scalable.

• The microservice architecture enables teams to be autonomous.

• It allows easy experimenting and adoption of new technologies.

• It has better fault isolation.

(IMPORTANT:: 45-47)

Drawbacks of the microservice architecture

Certainly, no technology is a silver bullet, and the microservice architecture has a number of significant drawbacks and issues. Indeed most of this book is about how to address these drawbacks and issues. As you read about the challenges, don’t worry. Later in this book I describe ways to address them.

Here are the major drawbacks and issues of the microservice architecture:

• Finding the right set of services is challenging.

• Distributed systems are complex, which makes development, testing, and deployment difficult.

• Deploying features that span multiple services requires careful coordination.

• Deciding when to adopt the microservice architecture is difficult.

(IMPORTANT:: 47-49)

Why patterns in microservices

One reason why patterns are valuable is because a pattern must describe the con- text within which it applies. The idea that a solution is specific to a particular context and might not work well in other contexts is an improvement over how technology used to typically be discussed. For example, a solution that solves the problem at the scale of Netflix might not be the best approach for an application with fewer users.

The value of a pattern, however, goes far beyond requiring you to consider the context of a problem. It forces you to describe other critical yet frequently overlooked aspects of a solution. A commonly used pattern structure includes three especially valuable sections:

• Forces

• Resulting context

• Related patterns

(51-)

What are the 3 Pattern structures

The value of a pattern, however, goes far beyond requiring you to consider the context of a problem. It forces you to describe other critical yet frequently overlooked aspects of a solution. A commonly used pattern structure includes three especially valuable sections:

• Forces

• Resulting context

• Related patterns

Grouping patterns organization

you can organize patterns that tackle issues in a particular problem area into groups. The explicit description of related patterns provides valuable guidance on how to effectively solve a particular problem. Figure 1.9 shows how the relationships between patterns is visually represented.

A collection of patterns related through these relationships sometimes form what is known as a pattern language. The patterns in a pattern language work together to solve problems in a particular domain. In particular, I’ve created the Microservice architecture pattern language. It’s a collection of interrelated software architecture and design patterns for microservices. Let’s take a look at this pattern language.

Microservice architecture pattern language

The Microservice architecture pattern language is a collection of patterns that help you architect an application using the microservice architecture.

Figure 1.10 shows the high-level structure of the pattern language. The pattern language first helps you decide whether to use the microservice architecture. It describes the monolithic architecture and the microservice architecture,

The 3 patterns layers

The rest of the pattern language consists of groups of patterns that are solutions to issues that are introduced by using the Microservice architecture pattern. The patterns are also divided into three layers:

• Infrastructure patterns—These solve problems that are mostly infrastructure issues

• outside of development.

• Application infrastructure—These are for infrastructure issues that also impact development.

• Application patterns—These solve problems faced by developers.

These patterns are grouped together based on the kind of problem they solve. Let’s look at the main groups of patterns.

Patterns for decomposing an application into services

Deciding how to decompose a system into a set of services is very much an art, but there are a number of strategies that can help. The two decomposition patterns shown in figure 1.11 are different strategies you can use to define your application’s architecture.

Communication patterns

An application built using the microservice architecture is a distributed system. Conse- quently, interprocess communication (IPC) is an important part of the microservice architecture. You must make a variety of architectural and design decisions about how your services communicate with one another and the outside world. Figure 1.12 shows the communication patterns, which are organized into five groups:

• Communication style—What kind of IPC mechanism should you use?

• Discovery—How does a client of a service determine the IP address of a service instance so that, for example, it makes an HTTP request?

• Reliability—How can you ensure that communication between services is reliable even though services can be unavailable?

• Transactional messaging—How should you integrate the sending of messages and publishing of events with database transactions that update business data?

• External API—How do clients of your application communicate with the services?

Data consistency patterns for implementing transaction management

As mentioned earlier, in order to ensure loose coupling, each service has its own database. Unfortunately, having a database per service introduces some significant issues. I describe in chapter 4 that the traditional approach of using distributed transactions (2PC) isn’t a viable option for a modern application. Instead, an application needs to maintain data consistency by using the Saga pattern. Figure 1.13 shows data-related patterns.

Patterns for querying data in a microservice architecture

The other issue with using a database per service is that some queries need to join data that’s owned by multiple services. A service’s data is only accessible via its API, so you can’t use distributed queries against its database. Figure 1.14 shows a couple of patterns you can use to implement queries.

Sometimes you can use the API composition pattern, which invokes the APIs of one or more services and aggregates results. Other times, you must use the Command query responsibility segregation (CQRS) pattern, which maintains one or more easily queried replicas of the data.

Service deployment patterns

In comparison, deploying a microservices-based application is much more complex. There may be tens or hundreds of services that are written in a variety of languages and frameworks.

There are many more moving parts that need to be managed. Figure 1.15 shows the deployment patterns.

Observability patterns provide insight into application behavior

A key part of operating an application is understanding its runtime behavior and trouble-shooting problems such as failed requests and high latency.

understanding and diagnosing problems in a microservice architecture is much more complicated. A request can bounce around between multiple services before a response is finally returned to a client. Consequently, there isn’t one log file to examine. Similarly, problems with latency are more difficult to diagnose because there are multiple suspects.

Patterns for the automated testing of services

The microservice architecture makes individual services easier to test because they’re much smaller than the monolithic application.

it’s important to test that the different services work together while avoiding using complex, slow, and brittle end-to-end tests that test multiple services together.

patterns for handling cross-cutting concerns

In a microservice architecture, there are numerous concerns that every service must implement, including the observability patterns and 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 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.

Security patterns

In a microservice 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 to apply the Access token pattern. The API gateway passes an access token, such as JWT (JSON Web Token), to the services, which can validate the token and obtain information about the user.

Beyond microservices: Process and organization

For a large, complex application, the microservice architecture is usually the best choice. But in addition to having the right architecture, successful software development requires you to also have organization, and development and delivery processes. Figure 1.16 shows the relationships between process, organization, and architecture.