Going from Services to Systems: Being Message Driven

Microservices in a reactive system work together to achieve responsiveness, resilience, and elasticity, and this is largely achieved through being message driven. There are two levels of “message driven-ness” that we look at now: intra-service, or how the components of a service communicate; and inter-service, or messaging between services, as illustrated in Figure 4-1.

Creating multiple instances is one way of achieving scale and resilience within a given service. Ideally, you could scale your microservice in a way that’s transparent to other parts of the system. For example, load balancing and routing between instances would be handled internally by the microservice, and additional instances would be spun up or down as needed in response to load and other external conditions. None of this is trivial, but it’s made possible by messaging between the elements that make up the microservice collective.

Figure 4-1. Messaging within and between services

There are open source libraries that can help you. One example is Akka, which provides libraries that allow you to manage the components of your microservice, actor systems in this case, as a “system of systems.” Another open source library is Vert.x, which uses an event bus between components of your microservices (verticals) and supports both point-to-point and publish/subscribe (pub/sub) messaging.

Messaging between services is a different matter, and durable messaging is a prerequisite for a microservice-based application, reactive or otherwise. This is where a pub/sub system is really useful. In a pub/sub integration pattern, a microservice producing an event (data) publishes it to an event bus, and services subscribed to that event bus take note and consume the event or data. Communication between microservices is completely asynchronous and location independent. It is important that the event bus is “durable” so that events persist long enough for subscribers to pick them up; in case of a failure, the message stream can be reconstructed with the events intact. Apache Kafka is one of the better-known platforms for implementing durable pub/sub messaging.

Reactive streaming takes inter-service messaging to the next level. As explained in Chapter 2, reactive streams implementations give you a graceful way to handle unbounded streams of data across asynchronous boundaries with back pressure. This makes it perfect to integrate your reactive microservices with external systems and to implement messaging between services within your reactive system. There are several frameworks and libraries from which to choose that implement the Reactive Streams specification, including Akka Streams and Vert.x Reactive Streams.

What type of infrastructure will allow us to reap the full benefits of this message-driven approach to application architecture?

Distributed Infrastructure 

As the pure quantity of data and scale of connected devices, sessions, and transactions continue to rise at an exponential rate, businesses have turned to distributed, cloud-based infrastructures to build applications that can process these huge volumes of data and support vast numbers of online users concurrently. Cloud native systems have become the bread and butter of many applications. However, getting the most out of this compute platform entails writing highly concurrent, distributed software. That isn’t easy! It requires properly handling threads, implementing synchronization, preventing race conditions, dealing with persistence and state, scaling the application, and responding to failures. Fortunately, this is exactly what reactive systems were designed for. Reactive systems embrace distributed infrastructure, creating a consistent and responsive experience that works as expected even in the face of failure and unpredictable loads.

Orchestrated Cloud Infrastructure

How can you go about deploying and managing your reactive system in a cloud environment? The answer is containers and Kubernetes. Containerization—packaging up your microservices and all of their dependencies into lightweight packages that can run anywhere—is a basic tenet of building cloud native software, and Kubernetes has become the de facto open source standard for managing containerized applications in production.

Kubernetes is fundamentally a cluster orchestration system that brings “reactive systems” characteristics to container management. We touch on just a few basic Kubernetes concepts here, but there are plenty of good resources available.

Here are the basics in a nutshell:

Clusters and nodes

A Kubernetes cluster consists of a set of nodes (VMs or physical machines) on which Kubernetes services are running.

Pods

A pod is the fundamental unit of deployment in a Kubernetes cluster. It essentially wraps one or more app containers along with the necessary network and storage resources.

Controllers

Lastly, controllers are Kubernetes services that watch over the cluster and take corrective action when the current state of the cluster strays from the desired state.

The cluster management capacity of Kubernetes gives you both resilience and elasticity at the infrastructure layer. Elasticity is achieved with Kubernetes autoscaling, which can dynamically adjust the number of nodes in your cluster as well as scale the number of pods running in your cluster based on workload. Automated pod recovery features enhance resilience by restarting failed pods or re-creating pods that have been deleted. An application created with reactive architectural principles will expand, contract, and redistribute itself with changes in the underlying infrastructure.

Running your reactive microservices application on a Kubernetes orchestrated infrastructure can provide multiple levels of resilience and elasticity.

Reactive Meets Machine Learning

Now that we’ve covered the application architecture and infrastructure approach for creating a responsive, elastic, and resilient application, the next step in your journey to become a cognitive business is to instrument your application to take advantage of data-driven insights in real time. This means combining vast amounts of data with machine learning to make your reactive system “smarter” in ways that create value for your customers.

First, we need to (briefly) introduce the concepts of machine learning (ML) and ML models, given that these are the means to infusing your applications with intelligence. ML is a subset of artificial intelligence that involves computers “learning” from exposure to data, being trained to find patterns in the data. The result is a computational model that can more or less correctly respond when new data is provided. Models can be developed for identification (such as image or voice recognition) or predictions (such as the weather).

Figure 4-2 illustrates the basic elements and flow of an ML-enabled reactive system. It’s generalized to show devices as well as users as sources of data on which the models are based.

Let’s say you are shopping at a brick-and-mortar store for new running shoes and find a pair you like, but you don’t love the price. You pull out your mobile phone and open an app for an online retailer to see if it has the shoes at a better price. (Admit it. You’ve done this.) The online retailer will have modeled your buying behaviors and that of millions of others, so with the right supplemental data (for example, your location near a running shoe store), it can present you with an offer for a pair of great running shoes at an attractive price even before you begin your search in its app. You’re delighted.

It’s worth noting that ML-enriched applications can be created with virtually any application technology. However, beginning from within a reactive systems context gives you the ability to dynamically manage the entire ML model—serving life cycle: streaming data from a wide array of sources, retraining models, and automatically redeploying them in real time.

Figure 4-2. The ML-infused application flow begins in the lower right with the model development. The model is created and trained (1) using historical data, then deployed (2), and then made available to an application. Data arrives into the system from users (3a) and other sources (3b) and becomes the source data used by the model (4) to produce a prediction, or recommendation (5). This additional data (6) can be used to retrain the machine learning model to improve its accuracy.