Microservice architecture pattern

In the previous section, we discussed the monolithic application architecture – in other words, the collection of all modules of an application as a single artifact. There is another architecture pattern that structures an application so that all modules of that application are loosely-coupled, share their services, and are independently deployable. In this approach, each service must be focused on a set of narrowly-related functions and each service runs independently and as a unique process. An application might consist of services, such as the Order Service, the Account Service, and so on. This approach is known as microservice architecture.

Microservice architecture refers to a method of software development in which a large software application is divided into several independently deployable services. These services are small, modular, and follow the single responsibility principle of software development. Each service is treated as a unique process that communicates with each other through a well-defined mechanism. We will discuss this further in Chapter 4, Inter-Service Communication.

In microservice architecture, all services communicate with each other either synchronously, using HTTP or REST, or asynchronously, using AMQP or Kafka. Each service contains its own database. The basic idea behind microservice architecture is to split up your monolithic application into a set of smaller, interconnected services.

A microservice architecture pattern separates concerns on a process level. All processes in this architecture are loosely coupled with each other. They communicate using predefined rules to achieve a business goal. So, let's move on and look at an example of a microservice-based application.

Microservice application example

We discussed a monolithic application in the previous section, in the form of an online book shop. In this section, we are going to discuss the same example using microservice architecture. The online bookshop application has four modules; Account Service, Book Inventory Service, Order Service, and Shipping Service. This application also has a user interface application, the Shop Front UI web application, which serves user requests and sends responses.

The following diagram illustrates the architecture of the application, which consists of a set of services:

As you can see, we have divided the earlier monolithic bookshop application into several independent services: Account Service, Book Service, Order Service, and Shipping Service. This is a microservices architectural style; according to this approach, we can develop a single application as a suite of small services.

Each service is built around a business capability and is independently deployable into the server. For example, the Account Service manages the customer’s account and has its own database, Account DB. Similarly, the Book Service manages the inventory of the books and has the database Inventory DB. The Order Service manages the customer’s orders using a separate database, Order DB. Finally, the Shipping Service manages shipping orders using the Shipping DB. Each module has its own dependency without depending on other services. This means that we can choose different technologies as well as develop separate services.

The server-side application must handle requests coming from various clients, such as desktop or mobile browsers and native mobile apps. The Shop Front UI web application handles the HTTP requests that come from browsers. Some APIs are exposed to the native mobile app, so the app doesn't call these APIs directly – instead, the app communicates through an intermediary known as an API Gateway. The API Gateway is responsible for handling these requests using load balancing. The API Gateway also offers caching, access control, and API monitoring.

We'll discuss the benefits of the microservice architecture pattern in the following section.

Benefits of microservice application architecture

The following are some of the benefits of the microservice architecture pattern:

• Easy to maintain: It is very easy for the developer to understand; this way, you can start development faster, which in turn makes it more productive
• Easy to scale: You can easily scale individual components
• Technology diversity: Microservices allow you to mix libraries, frameworks, data storage, and languages
• Fault isolation: Component failure should not bring the whole system down
• Better support: The architecture is suitable for smaller, parallel teams
• Independent deployment: We can easily deploy each microservice independently without impacting other microservices in the architecture

Microservice-based architecture also has a few disadvantages, however, and we'll take a look at them in the following section.

Disadvantages of the microservice architecture pattern

Microservices provide several benefits, but there are also some challenges relating to microservice architecture when developing an enterprise application. These include the following:

• It is sometimes difficult to achieve strong consistency across services and transactions.
  
  • Atomicity, Consistency, Isolation, Durability (ACID) transactions do not span multiple processes. ACID is a set of properties of database transactions intended to guarantee validity, even in the event of errors, power failures, and so on. This can be counteracted, however, using eventual consistency, which helps to manage transactions in a microservice application.
• A distributed system often:
  • Is harder to debug or trace
  • Has a greater need for end-to-end testing
  • Requires you to expect, test for, and handle the failure of any process
  • Has more components to maintain, which leads to issues such as redundancy or High Availability (HA)
• It typically requires a cultural change with regards to DevOps, such as how applications are developed and deployed, and the cooperation of Development and Operation teams

In light of its disadvantages, in the next section, we will discuss when to use microservice architecture for your project.

When to use microservice architecture

One of the challenges related to microservice architecture is deciding when to use it. The following scenarios are examples of when it is a good idea to start using microservice architecture in your project:

• New project development: Microservice architecture is more suitable when developing the first version of an application. You can plan your project and its associated modules from an initial level, whereas it can be challenging to convert an old or legacy project into a microservice-based application.
• Separating concerns in the business application: This architecture provides a better level of separation of concerns as the Spring framework provides separation of concerns at the level of the application’s components.
• Development of a cloud-native application: This architecture provides cloud-native patterns and supports distributed application development. We can create numerous independent services which can be deployed to a different platform on a different network, as can be done in the cloud.
• Quick development of independent service delivery: Microservice architecture allows us to develop a business application quickly by dividing it into the independent delivery of individual parts within a larger, integrated system.
• Efficient modules: In a business application, there are some modules that are very important for a business, and these modules must be developed in extremely efficient ways. Microservice architecture allows you to use better technologies for these modules to improve their efficiency.
• Alongside a fast-growing product or team: If you start with microservice architecture, it provides your team with the flexibility to develop a product quickly. It also provides scalability to your application from the beginning.

Essentially, microservice-based application development better follows an agile software development process, because different, small teams work on separate modules of the application. The teams are therefore able to release services with continuous delivery. Now, let's move on to another type of software application architecture.