From Microservices Patterns by Chris Richardson In this article, excerpted from Microservice Patterns, discusses the definition of the microservice architecture and why it’s important to software development.

Save 37% on Microservices Patterns. Just enter code fccrichardson into the discount code box at checkout at manning.com.

Let’s imagine that you’ve been give the job of defining the architecture for what’s anticipated to be a large, complex application. Your boss, the CIO, has heard that microservices are a necessary part of accelerating software development. He has strongly suggested that you consider the microservice architecture.

When defining a microservice architecture it’s essential that you use the microservices pattern language. The pattern language consists of patterns that solve numerous problems including deployment, inter-process communication and strategies for maintaining data consistency. The essence of the microservice architecture is functional decomposition. The first and most important aspect of the architecture is, therefore, the definition of the services. As you stand in front of that blank whiteboard in the project’s first architecture meeting, you’ll most likely wonder how to do that!

Don’t panic, in this article, you’ll learn how to define a microservice architecture for an application. But first, let’s take a look at the purpose of architecture.

The purpose of architecture

The microservice architecture is obviously a kind of architecture. But what is it and why does it matter? To answer that these question lets first look at what is meant by architecture. Len Bass and colleagues define architecture as follows:

The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

– Bass et al

This is obviously a quite abstract definition. More concretely, an application’s architecture can be viewed from multiple perspectives, in the same way that a building’s architecture can be viewed from the structural, plumbing, electrical, etc., perspectives. Phillip Krutchen (in his classic paper Architectural Blueprints-The “4+1” View Model of Software Architecture) designed the 4+1 view model of software architecture. The 4+1 model defines four different views of a software architecture, each of which describes a particular aspect of the architecture.

Each view consists of a particular set of (software) elements and relationships between them. Figure 1 shows the 4 + 1 view model.

Figure 1. 4+1 view model

The four views are:

• Logical view – classes, state diagrams, etc.
• Process view – the processes and how they communicate
• Physical view – the physical (virtual machines) and network connections
• Development view – components

In addition to these four views, there are the scenarios – the +1 in the 4+1 model – that animate views. Each scenario describes how the various architectural components within a particular view collaborate in order to handle a request. A scenario in the logical view, for example, shows how the classes collaborate. Similarly, a scenario in the process view shows how the processes collaborate.

The 4+1 view model is an excellent way to describe an application’s architecture. Each view describes an important aspect of the architecture. The scenarios illustrate how the elements of a view collaborate. Let’s now look at why architecture is important.

Why architecture matters

An application has two categories of requirements. The first category consists of the functional requirements, which define what the application must do. They’re usually in the form of use cases or user stories. Architecture has little to do with the functional requirements. You can implement functional requirements with almost any architecture, even a big ball of mud.

Architecture is important because it enables an application to satisfy the second category of requirements, its non-functional requirements. These are also known as quality attributes and are the -ilities. The non-functional requirements define the runtime qualities such as scalability, and reliability. They also define development time qualities including maintainability, testability, extensibility and deployability. The architecture that you choose for your application determines how well it meets these quality requirements.

The microservice architecture is an architectural style

The microservice architecture is what’s known as an architectural style. David Garlan and Mary Shaw define an architectural style as follows:

“An architectural style, then, defines a family of such systems in terms of a pattern of structural organization. More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined.”

– An Introduction to Software Architecture

A particular architectural style provides a limited palette of elements (a.k.a components) and relationships (a.k.a. connectors) from which you can define your application’s architecture. The microservice architecture structures an application as a set of loosely coupled services. The components are services and the connectors are the communication protocols that enable those services to collaborate. Figure 2 shows a possible microservice architecture for the FTGO application.

Figure 2. Example microservice architecture

Each service in this example application corresponds to a different business function such as that in an Order management like micros mobile which may also deal with some aspects of restaurant management. The connectors between services are implemented using REST APIs. One of these restaurant management needs may incorporate an ipad pos system, which will need checking and updating regularly to make sure it is working to its highest level.

A key constraint imposed by the microservice architecture is that the services are loosely coupled. Consequently, there are restrictions how the services collaborate. In order to understand those restrictions, let’s attempt to define the term service and describe what it means to be loosely coupled.

What’s a service?

Intuitively, we think of a service as a standalone, independently deployable software component, which implements some useful functionality. But in reality, the term service is one of those words that we use daily without having a precise definition of its meaning. For example, OASIS has a remarkably vague definition for a service:

“A mechanism to access an underlying capability.”

– OASIS https://en.wikipedia.org/wiki/Service_(systems_architecture)

A service has an API, which provides its clients with access to its functionality. Figure 3 shows an abstract view of a service.

Figure 3. Abstract view of a service

A service’s clients invoke the API. The implementation of its functionality is hidden.

Typically, the API uses an inter-process communication mechanism such as a messaging or RPC but this isn’t always the case. A service can take many forms. It might be a standalone process, a web application or OSGI bundle running in a container, or a serverless cloud function. An essential requirement is that a service’s independently deployable.

What is loose coupling?

An important characteristic of the microservice architecture is that the services are loosely coupled. All interaction with a service is via its API, which encapsulates its implementation details. This enables the implementation of the service to change without impacting its clients. Loosely coupled services are key to improving an applications development time attributes including its maintainability and testability. Small, loosely coupled services are much easier to understand, change and test.

The requirement for services to be loosely coupled and to collaborate only via APIs prohibits services from communicating via a database. A service’s persistent data is equivalent to the fields of a class and must kept private. Keeping data private helps ensure that the services are loosely coupled. It enables a developer to change their service’s schema without having to coordinate with developers working on other services. It also improves runtime isolation. For example, it ensures that one service can’t hold database locks that block another service. A downside of not sharing databases is that maintaining data consistency and querying across services is more complex.

The microservice architecture structures an application as a set of small, loosely coupled services. As a result, it improves the development time attributes – maintainability, testability, deployability, etc. – and enables an organization to develop better software faster. It also improves an application’s scalability although it isn’t the main goal. To develop a microservice architecture for your application you need to identify the services and determine how they communicate.

That’s all for this article.

If you want to learn more about the book, check it out on liveBook here.