Chapter 9. Reactive Microservices

We have now gained a clear understanding of a microservice-based architecture and how to harness its power. Until now, we've discussed various aspects of this architecture, such as communication, deployment, and security, in detail. We also saw how microservices collaborate among themselves when required. Now let's take the effectiveness of microservices to the next level by introducing the reactive programming aspect within them. We will cover the following topics:

• Understanding reactive microservices
• Mapping processes
• Communication in reactive microservices
• Handling security
• Managing data
• The microservice ecosystem

What are reactive microservices?

Before we dive into reactive microservices, let's see what the word reactive means. There are certain fundamental attributes that a piece of software must possess in order to be considered reactive. These attributes are responsiveness, resilience, elasticity, and above all, being message-driven. We'll discuss these attributes in detail and see how they can make microservices a stronger candidate for most enterprise requirements.

Responsiveness

It wasn't long ago when one of the key requirements of business sponsors, discussed in requirement gathering sessions, was a guaranteed response time of a few seconds. For example, a t-shirt custom print e-shop where you could upload images and then have it rendered on the chosen piece of apparel. Move forward a few years and I can vouch for this myself; I will close the browser window if any web page takes longer than a couple of seconds to load.

Users today expect near instantaneous response. But this is not possible...

Making it reactive

Let's examine our application and see how it would look with the reactive style of programming. The following image depicts the flow of the application that is reactive in nature and is completely event-driven. In this image, services are depicted by hexagons, and events are represented by square boxes. Here's the entire flow in detail:

The flow depicted in the image describes the scenario of a customer placing an order after having searched for the items he/she is looking for. The Place order event is raised to Order service. In response to this event, our service analyzes arguments, such as order item and quantity, and raises the Item availability event to Product service. From here on, there are two possible outcomes: either the requested product is available and has the required quantity or it is not available or doesn't have the required quantity. If the items are available, Product service raises an event called Generate invoice to Invoice service. Since raising the...

Event communication

The preceding discussion may have left you thinking about how the event being raised maps the call of the respective microservice perfectly; let's discuss this in further detail. Think of all the events being raised as being stored in an event store. The event stored has an associated delegate function that is called to cater to the respective event. Although it is shown that the store has just two columns, it stores much more information, such as details of the publisher, subscriber, and so on. Each event contains the complete information that is required to trigger the corresponding service. So event delegation might be a service to be called or a function within the application itself. It doesn't matter to this architecture.

Security

There are numerous ways in which security can be handled while implementing reactive microservices. However, given the limited time and scope that we have here, we will restrict our discussion to one type only. Let's go on and discuss message...

Managing data

Tracking a single order being placed is easy. However, multiply that number with the million orders being placed and canceled every hour; it could quickly become a challenge in the reactive microservices domain. The challenge is how you would perform a transaction across multiple services. Not only is it difficult to track such a transaction, it poses other challenges, such as persisting such a transaction that spans the database and message broker. The task of reversing such an operation in the likelihood of the transaction breaking somewhere in the middle due to a service failure could be even more daunting.

In such a scenario, we can utilize the event sourcing pattern. This is a strong candidate, especially since we are not looking for a two-phase commit, generally referred to as 2PC. Instead of storing a transaction, we persist all the state-changing events of our entities. In other words, we store all the events that change their states in the form of entities, such as...

The microservice ecosystem

As discussed in the initial chapters, we need to get ready for big changes when embracing microservices. The discussions we've had on deployment, security, and testing so far would have had you thinking by now about accepting this fact. Unlike monoliths, adoption of microservices requires you to prepare beforehand and in a way that you start building the infrastructure along with it and not after it. In a way, microservices thrive in the complete ecosystem where everything is worked out, from deployment to testing and security to monitoring. The returns associated with embracing such a change are huge. There is definitely a cost involved to make all these changes. However, instead of having a product that doesn't get on the market, it is better to incur some costs and design and develop something that thrives and does not die out after the first few rollouts.

Reactive microservices - coding it down

Now, let's try to sum up everything and see how it actually looks in the code. We will use Visual Studio 2015 for this. The first step would be to create a reactive microservice, then we will move on to creating a client for consuming the service created by us.

Creating the project

We will now go ahead and create our reactive microservice example. In order to do this, we need to create a project of the ASP.NET web application type. Just follow these steps and you should be able to see your first reactive microservice in action:

1. Start Visual Studio.
2. Create a new project by navigating to File | New | Project.
3. From the installed templates, select Web and ASP.NET Web Application.
4. Name it FlixOne.BookStore.ProductService.Tests and click on OK.
5. Next, select Empty from the template screen and check the WebAPI option for adding folders and core references. Then click on OK:

6. Add folders' persistence and context to the project:
7. Add the following NuGet packages to the...

Summary

In this chapter, we added the aspect of reactive programming to our microservice-based architecture. There are trade-offs with this message-driven approach to microservices communicating with each other. However, at the same time, this approach tends to solve some of the fundamental problems when we advance our microservice architecture further. The event sourcing pattern comes to our rescue and lets us get past the limitation of an ACID transaction or a two-phase commit option. This topic requires a separate book altogether and restricting it to a single chapter does not do justice to it. We used our sample application to understand how to restructure our initial microservice in a reactive way.

In the next chapter, we would have the entire application ready for us to explore and we will put together everything that we have discussed so far in this book.