Why Reactive?

Chapter 1. Introduction

It’s increasingly obvious that the old, linear,
three-tier architecture model is obsolete.¹

A Gartner Summit track description

While the term reactive has been around for a long time, only recently has it been recognized by the industry as the de facto way forward in system design and hit mainstream adoption. In 2014 Gartner wrote that the three-tier architecture that used to be so popular was beginning to show its age. The goal of this report is to take a step back from the hype and analyze what reactive really is, when to adopt it, and how to go about doing so. The report aims to stay mostly technology agnostic, focusing on the underlying principles of reactive application and system design. Obviously, certain modern technologies, such as the Lightbend or Netflix stacks, are far better suited for development of Reactive Systems than others. However, instead of giving blank recommendations, this report will arm you with the necessary background and understanding so you can make the right decisions on your own.

This report is aimed at CTOs, architects, and team leaders or managers with technical backgrounds who are looking to see what reactive is all about. Some of the chapters will be a deep dive into the technical aspects. In Chapter 2, which covers reactive on the application level, we will need to understand the technical differences around this programming paradigm and its impact on resource utilization. The following chapter, about reactive on the system level, takes a step back a bit and looks at the architectural as well as organizational impact of distributed reactive applications. Finally, we wrap up the report with some closing thoughts and suggest a few building blocks, and how to spot really good fits for reactive architecture among all the marketing hype around the subject.

So, what does reactive really mean? Its core meaning has been somewhat formalized with the creation of the Reactive Manifesto² in 2013, when Jonas Bonér³ collected some of the brightest minds in the distributed and high-performance computing industry—namely, in alphabetical order, Dave Farley, Roland Kuhn, and Martin Thompson—to collaborate and solidify what the core principles were for building reactive applications and systems. The goal was to clarify some of the confusion that around reactive, as well as to build a strong basis for what would become a viable development style. While we won’t be diving very deep into the manifesto itself in this report, we strongly recommend giving it a read. Much of the vocabulary that is used in systems design nowadays (such as the difference between errors and failures) has been well defined in it.

Much like the Reactive Manifesto set out to clarify some of the confusion around terminology, our aim in this report is to solidify a common understanding of what it means to be reactive.

Why Build Reactive Systems?

It’s no use going back to yesterday,
because I was a different person then.

Lewis Carroll

Before we plunge into the technical aspects of Reactive Systems and architecture, we should ask ourselves, “Why build Reactive Systems?”

Why would we be interested in changing the ways we’ve been building our applications for years? Or even better, we can start the debate by asking, “What benefit are we trying to provide to the users of our software?” Out of many possible answers, here are some that would typically lead someone to start looking into Reactive Systems design. Let’s say that our system should:

• Be responsive to interactions with its users

• Handle failure and remain available during outages

• Strive under varying load conditions

• Be able to send, receive, and route messages in varying network conditions

These answers actually convey the core reactive traits as defined in the manifesto. Responsiveness is achieved by controlling our applications’ hardware utilization, for which many reactive techniques are excellent tools. We look at a few in Chapter 2, when we start looking at reactive on the application level. Meanwhile, a good way to make a system easy to scale is to decouple parts of it, such that they can be scaled independently. If we combine these methods with avoiding synchronous communication between systems, we now also make the system more resilient. By using asynchronous communication when possible, we can avoid binding our lifecycle strictly to the request’s target host lifecycle. For example, if the lifecycle is running slowly, we should not be affected by it. We’ll examine this issue, along with others, in Chapter 3, when we zoom out and focus on reactive on the system level, comparing synchronous request-response communication patterns with asynchronous message passing.

Finally, in Chapter 4 we list the various tools in our toolbox and talk about how and when to use each of them. We also discuss how to introduce reactive in existing code bases as we acknowledge that the real world is full of existing, and valuable, systems that we want to integrate with.

And Why Now?

The Internet of Things (IoT) is expected to surpass mobile phones
as the largest category of connected devices in 2018.

Ericsson Mobility Report

Another interesting aspect of the “why” question is unveiled when we take it a bit further and ask, “Why now?”

As you’ll soon see, many of the ideas behind reactive are not that new; plenty of them were described and implemented years ago. For example, Erlang’s actor-based programming model has been around since the early 1980s, and has more recently been brought to the JVM with Akka. So the question is: why are the ideas that have been around so long now taking off in mainstream enterprise software development?

We’re at an interesting point, where scalability and distributed systems have become the everyday bread and butter in many applications which previously could have survived on a single box or without too much scaling out or hardware utilization. A number of movements have contributed to the current rise of reactive programming, most notably:

IoT and mobile

The mobile sector has seen a 60% traffic growth between Q1 2015 and Q1 2016; and according to the Ericsson Mobility Report,⁴ that growth is showing no signs of slowing down any time soon. These sectors also by definition mean that the server side has to handle millions of connected devices concurrently, a task best handled by asynchronous processing, due to its lightweight ability to represent resources such as “the device,” or whatever it might be.

Cloud and containerization

While we’ve had cloud-based infrastructure for a number of years now, the rise of lightweight virtualization and containers, together with container-focused schedulers and PaaS solutions, has given us the freedom and speed to deploy much faster and with a finer-grained scope.

In looking at these two movements, it’s clear that we’re at a point in time that both the need for concurrent and distributed applications is growing stronger. At the same time, the tooling needed to do so at scale and without much hassle is finally catching up. We’re not in the same spot as we were a few years ago, when deploying distributed applications, while possible, required a dedicated team managing the deployment and infrastructure automation solutions.

It is also important to realize that many of the solutions that we’re revisiting, under the umbrella movement called reactive, have been around since the 1970s. Why reactive is hitting the mainstream now and not then, even though the concepts were known, is related to a number of things. Firstly, the need for better resource utilization and scalability has grown strong enough that the majority of projects seek solutions. Tooling is also available for many of these solutions, both with cluster schedulers, message-based concurrency, and distribution toolkits such as Akka. The other interesting aspect is that with initiatives like Reactive Streams,⁵ there is less risk of getting locked into a certain implementation, as all implementations aim to provide nice interoperability. We’ll discuss the Reactive Streams standard a bit more in depth in the next chapter.

In other words, the continuous move toward more automation in deployment and infrastructure has led us to a position where having applications distributed across many specialized services spread out onto different nodes has become frictionless enough that adopting these tools is no longer an impediment for smaller teams. This trend seems to converge with the recent rise of the serverless, or ops-less, movement. This movement is the next logical step from each and every team automating their cloud by themselves. And here it is important to realize that reactive traits not only set you up for success right now, but also play very well with where the industry is headed, toward location-transparent,⁶ ops-less distributed services.

¹ Gartner Summits, Gartner Application Architecture, Development & Integration Summit 2014 (Sydney, 2014), http://www.gartner.com/imagesrv/summits/docs/apac/application-development/AADI-APAC-2014-Brochure.pdf.

² Jonas Bonér et al., “The Reactive Manifesto,” September 16, 2014, http://www.reactivemanifesto.org.

³ Jonas Bonér, Founder and CTO of Lightbend (previously known as Typesafe) in 2011, and Scalable Solutions in 2009, http://jonasboner.com.

⁴ “Ericsson Mobility Report,” Ericsson, (June 2016), https://www.ericsson.com/res/docs/2016/ericsson-mobility-report-2016.pdf.

⁵ Reactive Streams, a standard initiated by Lightbend and coauthored with developers from Netflix, Pivotal, RedHat, and others.

⁶ Location-transparency is the ability to communicate with a resource regardless of where it is located, be it local, remote, or networked. The term is used in networks as well as Reactive Systems.