What do we mean by reactive?

Let’s start at the beginning. Forget about software and IT for a few minutes, and use an out-of-fashion approach. If we look for “reactive” in the Oxford dictionary, we find the following definition:

*reactive*
ADJECTIVE

1. Showing a response to a stimulus.
1.1 Acting in response to a situation rather than creating or controlling it.
1.2 Having a tendency to react chemically.
1.3 (Physiology) Showing an immune response to a specific antigen.
1.4 (of a disease or illness) caused by a reaction to something.
1.5 (Physics) Relating to reactance.

Among these definitions, two are relevant in our context. The first definition, showing a response to a stimulus, refers to some kind of reaction. Being reactive means reacting to stimuli, whatever they are. Sub-definition 1.1 says that being reactive is also about facing unexpected and uncontrolled situations. We will see along with this book, that Cloud-Native applications, and distributed systems in general, face plenty of such kind of situation.

But, while these definitions are interesting, they don’t apply to software. So, let’s make one. Taking these definitions into account, we can add a new one specific to software:

1.6 (Software) Application reacting to stimuli, such as user events, requests,
and failures.

But, we will see in this book that today’s reactive goes beyond this. Reactive is an approach to design, implement, and reason about your system in term of events and flows. Reactive is about building responsive, resilient, and elastic applications. Reactive is also about resource utilization through efficient management of resources and communication.

To put another way: Reactive is about designing and building better distributed systems. More robust, more efficient. We call them: reactive systems.

Reactive software is not new!

But wait, the definition (1.6) we just gave; it’s not groundbreaking. On the contrary, it looks “déjà-vu,” no?

Isn’t the nature of software to react to user inputs, and operating systems signals? How does a software behave when you hit a keystroke, it reacts. So, why so many books, talks and debate about it if it’s just regular software?¹ Please be patient; there is a bit more about it.

But you are right; Reactive is not new. It’s actually pretty old. We can track the foundation of the ideas behind reactive software just after the apparition of computers in the ’50s. The DYSEAC, a first-generation computer (in operation in 1954), was already using hardware interrupts as an optimization, eliminating waiting time in polling loops, waiting for external events. This computer was one of the first systems to use reactive and event-driven architecture!

Reacting to events implies being event-driven. Event-driven software receives and produces events. The received events determine the flow of the program. A fundamental aspect of this event-driven aspect is the asynchronous² nature of event-driven architecture. You don’t know when you are going to receive events. It is precisely the (1.1) definition from the previous section. You cannot plan when you will receive events; you are not in control of which events you will get; you need to be prepared to handle them.

That’s the essence of being reactive: being asynchronous.

The reactive landscape

From this idea of being asynchronous and event-driven, many forms of Reactive have emerged. The reactive landscape is broad and crowded.

But don’t forget our objective: building better distributed systems - reactive systems. The other “reactive”s are here to help us implement these systems.

The reasons for Reactive, and reactive systems in particular, come from distributed systems. As we will see in Chapter 3, building distributed systems is hard. In 2013, distributed system experts wrote the first version of the reactive manifesto introducing the concept of reactive systems.

Yes, you can build distributed systems without applying the reactive principles. Reactive provides a blueprint to ensure no significant known concerns were overlooked while architecting and developing your system. On the other hand, you can apply these principles on non-distributed systems.

Figure 1-1 depicts an excerpt of this landscape and the relation between the main reactive things.

Figure 1-1. The reactive landscape

A reactive system is first and foremost responsive. It must handle requests in a timely fashion even under load or when facing failures. To achieve this responsiveness, the manifesto proposes using asynchronous message passing as the primary way to communicate between the components forming the system. We will see in Chapter 4 how it enables elasticity and resilience, two essential attributes of solid distributed systems. The objective of this book is to show you how you can build such reactive systems with Quarkus. So, it’s our primary goal.

Infusing asynchronous message passing at the core of distributed systems does not come without consequences. Your application needs to use asynchronous code and use non-blocking I/O, the ability provided by the operating system to enqueue I/O interactions without having to actively wait for the completion (We will cover non-blocking I/Os in Chapter 4). The latter is essential to improve resource utilization, such as CPU and memory, another important aspect of Reactive. Today, many toolkits and frameworks, such as Quarkus, Eclipse Vert.x, Micronaut, Helidon or Netty, are using non-blocking I/O for this very reason: doing more with limited resources.

Yet, having a runtime leveraging non-blocking I/O is not enough to be Reactive. You also need to write asynchronous code embracing the non-blocking I/O mechanics. Otherwise, the resource utilization benefits would vanish. Writing asynchronous code is a paradigm shift. From the traditional (imperative): do x; do y;, you are now going to shape your code as: on event(e) do x; on event(f) do y; In other words, to be reactive, not only your system is an event-driven architecture, your code is also going to become event-driven. One of most straightforward approach to implement such code is callbacks: you register functions invoked when event are received. Like Futures, Promises, and Co-routines, every other approach is based on callbacks and offers higher-level APIs.

Reactive programming, addressed in Chapter 5, is also an approach to writing asynchronous code. It uses data streams to structure your code. You observe the data transiting in these streams and react to it. Reactive programming provides a powerful abstraction and APIs to shape event-driven code.

But using data streams comes with an issue. If you have a very fast producer directly connected to a slow consumer, you may flood the consumer. As we will see we can buffer or use a message broker in between, but imagine without. That would be against the responsiveness and anti-fragile ideas promoted by Reactive. To help us with that particular issue, reactive streams propose an asynchronous and non-blocking backpressure protocol where the consumer signals to the producer its availability. As you can imagine, this may not be applicable everywhere, as some data source cannot be slowed down.

Reactive Streams popularity has increased over the past few years. For example, RSocket is a network protocol based on Reactive Streams. R2DBC proposes asynchronous database access using Reactive Streams. Also, RX Java, Project Reactor, and Mutiny adopted reactive streams to handle backpressure. Finally, Vert.x allows mapping the Vert.x back-pressure model to reactive streams³.

That concludes our quick tour of the reactive landscape. As we said, it’s crowded, many terms, many tools. But never lose sight of the overall objective of Reactive: build better distributed systems. That’s the primary focus of this book.

Why are reactive architectures so well-suited for Cloud-native applications?

The Cloud, public, private, or hybrid, has put Reactive in the spotlight. The Cloud is a distributed system. When you run your application on the Cloud, it faces a high degree of uncertainty. The provisioning of your application can be slow, fast, or even fail. Disruptions of communications are usual, because of network failures or partitions. You may hit quota restrictions, resource shortages, hardware failures. Some services you are using can be unavailable at times or moved to other locations.

While the Cloud provides outstanding facilities for the infrastructure layer, it only covers half of the story. The second half is your application. It needs to be designed to be a part of a distributed system. It needs to understand the challenges of being part of such a system.

The reactive principles, we will be covering in this book, help to embrace the inherent uncertainty and challenges of distributed systems and Cloud applications. It won’t hide them - to the contrary, it embraces them.

As Microservices and Serverless are becoming prominent architectural style, the reactive principles become even more important. They would make sure that you design your system on a sane base.

Reactive is not a silver bullet

As with everything, there are pros and cons to Reactive. It’s not a magic weapon. No solution works everywhere.

Remember about microservices in the late 2010’s? They quickly have become exceedingly popular, and many organizations implemented them in areas for which they may not have been well-suited. This often traded one set of problems for another. Much like microservice architectures, reactive architectures have areas in which they are well-suited. They shine for distributed, and Cloud applications but can be disastrous on more monolithic and computation-centric systems. If your system relies on remote communication, event processing or seek for high efficiency, Reactive will be interesting. If your system is mostly using in-process interactions, handle just a few requests per days or is computation-intensive, then Reactive won’t bring anything but complexity.

With Reactive, you put the notion of events at the core of your system. If you are used to the traditional synchronous and imperative way of building applications, the path to become Reactive can be steep. The need to become asynchronous disrupts most traditional frameworks. We are moving away from the well-known RPC and HTTP endpoints.

So, disclaimer said, time to start our journey!