Chapter 1. The Journey to Reactive Systems
Enterprises are transforming themselves into cognitive businesses: companies that learn and adapt instantly to the changing conditions around them, using real-time data and AI to bring additional value to their customers. They are realizing this business agility by building applications capable of handling massive scale, massive amounts of data, or both, and running them in a hybrid, multicloud environment.
As enterprise developers and architect leaders within these organizations, you are key influencers. Your recommendations drive the buying decisions that lead to success or failure. The good news is that today you have an unprecedented array of open source technologies on which to base these next-generation applications. That unprecedented array of choices is also the bad news. This report discusses some of the factors driving organizations to employ a reactive-systems approach to cloud native development.
Within this report we define reactive systems as an architectural style that enables applications composed of multiple microservices working together as a single unit to better react to their surroundings and one another, manifesting in greater elasticity when dealing with ever-changing workload demands and resiliency when components fail. We also introduce some of the key patterns found within reactive systems and distinguish between various toolkits and frameworks. Our goal is to help enterprise developers and architects make better decisions about reactive systems.
Microservices: So Many Choices
For most enterprises, an essential part of becoming a cognitive business is migrating to a hybrid multicloud infrastructure and adopting microservices application architecture. A 2018 survey of developers1 found that more than 90% were pursuing a microservices strategy. It’s not hard to see why, given that everything is trending toward greater software development velocity. Microservices are intended to be small, self-contained, single-purpose units of computation, loosely coupled to other microservices through well-defined interfaces. These characteristics enable you to develop, test, and deploy them independently—different teams, different timelines. Combining this architectural approach with DevOps methodologies such as continuous integration, continuous delivery, and continuous deployment can lead to tremendous efficiencies. But for developers, two of the chief advantages of microservices are flexibility and choice. The relative independence they offer frees you to select a mixture of programming languages or frameworks based on the services you’re developing and the skills available on your team.
However, applications are composed of systems of microservices. How an application’s microservices behave internally, as well as how they interact with one another, determines the application’s ability to scale dynamically, exhibit resiliency in the presence of failures, and maintain responsiveness as workload increases. In short, these behaviors establish the fundamentals of building a reactive system.
When and Where Are Reactive Systems Applicable?
You could, theoretically, engineer every microservices application as a reactive system. It’s equally true that this approach will present quite a learning curve for many developers today. If the application does not require it, why do it? Here’s what we think: you will need to climb that hill sooner than you might think, so you might as well start the journey now. It is not a matter of “if,” but “when.” Let’s look at a few scenarios that would drive you to a reactive systems architecture.
Let’s say it’s late November, the US Thanksgiving holiday is over, and peak shopping season has begun. Millions of people are shopping online, and every one of them expects your website to be responsive no matter how many others are browsing and buying at the same time. A study of the impact website performance has on buying behaviors2 shows that sluggish sites reduced both a customer’s likelihood to make a purchase as well as the amount they would be willing to pay for a product. The researchers concluded that there was a “48% reduction in revenue between the high and poor performing website.” The results of this study as well as numerous others highlights just how important it is for your website to remain responsive regardless of load.
So, does the reverse apply? If you improve the responsiveness of a solidly performing web commerce site, will that improve financial results? In a word, “yes.” Verizon Wireless rearchitected its monolithic commerce platform to reactive microservices and achieved a threefold reduction in page response times, dramatically improved sales conversion rates, and realized a 235% increase in revenue over a comparable prior sales period.
It’s been said that data is now “the world’s most valuable resource.” Vast amounts of data exist, and even greater amounts are generated every second of the day by nature, people, and systems. Collecting, aggregating, and making use of this data is driving new businesses and improving the way we operate. The challenge, however, is dealing with its sheer volume and velocity.
PayPal presents an interesting study of its Product Performance Tracking system. This application processes information from across PayPal’s global network of platforms, giving executives insight into the performance of products, and allowing the company to adjust and deliver a better experience for its customers. The data volume and velocity statistics are stunning: 40 terabytes of data and more than 10 billion messages every day, asynchronously and at widely varying rates. PayPal adopted a reactive architecture approach to build a system capable of responding quickly and elastically, without the need to provision new infrastructure to handle the load.
Data-driven decisions are good, but data-driven decisions in near real time are even better. This is where reactive microservices combine with artificial intelligence and machine learning in a reactive system. Consumer credit companies are using this approach to determine credit risk, shrinking processing time to mere minutes.