Introduction to Microservices Architecture

The chapter covers some essential microservices architecture concepts. It is designed to get you started with those principles and to give you an overview of the concepts surrounding microservices, which should help you make informed decisions about whether to go for a microservices architecture or not.

Since microservices architecture is larger in scale than the previous application-scale patterns we visited and often involves complex components or setup, there is limited C# code in the chapter. Instead, I explain the concepts and list open-source or commercial offerings that you can leverage to apply these patterns to your applications. Moreover, you should not aim to implement many of the pieces discussed in the chapter yourself, as it can be a lot of work to get them right, and they don’t add business value, so you are better off just using an existing implementation instead. There is more context about this throughout the...

What are microservices?

Microservices represent an application that is divided into multiple smaller applications. Each application, or microservice, interacts with the others to create a scalable system. Usually, but not necessarily, microservices are deployed to the cloud as containerized or serverless applications.

Before getting into too many details, these are the principles to keep in mind when building microservices:

• Each microservice should be a cohesive unit of business
• Each microservice should own its data
• Each microservice should be independent of the others

Furthermore, everything we have studied so far—the other principles of designing software—applies to microservices but on another scale. For example, you don’t want tight coupling between microservices (solved by microservices independence), but coupling is inevitable (as with any code). There are numerous ways to solve this problem, such as the Publish-Subscribe...

An introduction to Event-Driven Architecture

Event-Driven Architecture (EDA) is a paradigm that revolves around emitting and consuming events. These events could be user actions, sensor outputs, or messages from other programs, like microservices. The core aspects of EDA include:

• Decoupling of components: EDA allows for the decoupling of application components or microservices
• Asynchronous communication: Components communicate by producing or consuming events, which allows for non-blocking interactions
• Reactivity and adaptability: Systems built with EDA can easily adapt to changes or new requirements by modifying how events are handled, or by introducing new events

A system modeled using EDA usually consumes streams of events instead of static states like the data stored in a relational database table. EDA systems typically rely on event stores. An event store is a specialized database system that persists the events. Such stores are usually immutable...

Project – BFF

Here, we’re pausing our discussion of microservices concepts and relevant patterns to work through a practical project, demonstrating how the BFF pattern works in practice. This is a long chapter, so feel free to take a break before diving into this project.

This project leverages the BFF design pattern to reduce the complexity of using the low-level API of the REPR project we created in Chapter 18, Request-EndPoint-Response (REPR). The BFF endpoints act as the several types of gateway we have explored.

This design makes two layers of APIs, so let’s start here.

Layering APIs

From a high-level architecture perspective, we can leverage multiple layers of APIs to group different levels of operation granularity. For example, in this case, we have two layers:

• Low-level APIs that offer atomic foundational operations
• High-level APIs that offer domain-specific functionalities

Here’s a diagram that...

Revisiting the CQRS pattern

Command Query Responsibility Segregation (CQRS) applies the Command Query Separation (CQS) principle. Compared to what we saw in Chapter 16, Mediator and CQS Patterns, we can push CQRS further using microservices or serverless computing. Instead of simply creating a clear separation between commands and queries, we can divide them even more using multiple microservices and data sources to enhance scalability and flexibility. This approach allows each component to be scaled independently based on demand, improving system performance and resource efficiency.

CQS is a principle stating that a method should either return data or mutate data, but not both. On the other hand, CQRS suggests using one model to read the data and one model to mutate the data.

Serverless computing is a cloud execution model where the cloud provider manages the servers and allocates the resources on-demand, based on usage and configuration. Serverless resources fall...

Overview of the Microservice Adapter pattern

The Microservice Adapter pattern allows us to add missing features, adapt one system to another, or migrate an existing application to an event-driven architecture model, to name a few possibilities. The Microservice Adapter pattern is similar to the Adapter pattern we covered in Chapter 11, Structural Patterns, but applied to a microservices system that uses event-driven architecture, instead of creating a class to adapt an object to another signature.

In the scenarios we cover in this section, the microservices system represented by the following diagram can be replaced by a standalone application as well; this pattern applies to all sorts of programs, not just microservices, which is why I abstracted away the details:

Figure 19.34: Microservices system representation used in the subsequent examples

Here are the examples we cover next and the possible usages of this pattern:

• Adapting an existing system to another...

Summary

The microservices architecture is different from everything we’ve covered in this book and how we build monoliths. Instead of one big application, we split it into multiple smaller ones called microservices. Microservices must be independent of one another; otherwise, we will face the same problems associated with tightly coupled classes but at the cloud scale.

We can leverage the Pub-Sub design pattern to loosely couple microservices while keeping them connected through events. Message brokers are programs that dispatch those messages. We can use event sourcing to recreate the application’s state at any point in time, including when spawning new containers. We can use application gateways to shield clients from the microservices cluster’s complexity and publicly expose only a subset of services.

We also looked at how we can build upon the CQRS design pattern to decouple reads and writes of the same entities, allowing us to scale queries and commands...

Questions

Let’s take a look at a few practice questions:

1. What is the most significant difference between a message queue and a Pub-Sub model?
2. What is event sourcing?
3. Can an application gateway be both a routing gateway and an aggregation gateway?
4. Is it true that real CQRS requires a serverless cloud infrastructure?
5. What is a significant advantage of using the BFF design pattern?

Further reading

Here are a few links that will help you build on what you learned in this chapter:

• Event Sourcing pattern by Martin Fowler: https://adpg.link/oY5H
• Event Sourcing pattern by Microsoft: https://adpg.link/ofG2
• Publisher-Subscriber pattern by Microsoft: https://adpg.link/amcZ
• Event-driven architecture by Microsoft: https://adpg.link/rnck
• Saga pattern by Microsoft: https://adpg.link/3FD7
• Microservices architecture and patterns on microservices.io: https://adpg.link/41vP
• Microservices architecture and patterns by Martin Fowler: https://adpg.link/Mw97
• Microservices architecture and patterns by Microsoft: https://adpg.link/s2Uq
• RFC 6902 (JSON Patch): https://adpg.link/bGGn
• JSON Patch in ASP.NET Core web API: https://adpg.link/u6dw
• Strangler Fig Application pattern:
  • Martin Fowler: https://adpg.link/Zi9G
  • Microsoft: https://adpg.link/erg2

Answers

1. The message queue gets a message and has a single subscriber dequeue it. If nothing dequeues a message, it stays in the queue indefinitely (the FIFO model). The Pub-Sub model gets a message and sends it to zero or more subscribers.
2. Event sourcing is the process of chronologically accumulating events that happened in a system instead of persisting in the current state of an entity. It allows you to recreate the entity’s state by replaying those events.
3. Yes, you can mix Gateway patterns.
4. No, you can deploy micro-applications (microservices) on-premises if you want to.
5. It separates generic functionalities from app-specific ones, promoting cleaner code and modularization. It also helps simplify the frontend.

Learn more on Discord

To join the Discord community for this book – where you can share feedback, ask questions to the author, and learn about new releases – follow the QR code below:

https://packt.link/ArchitectingASPNETCoreApps3e...