Application requirements have changed drastically in recent years. For any application to succeed in this era of cloud computing, big data and IoT, going reactive is increasingly becoming a norm.
Today’s users embrace applications that have milliseconds of response time, 100% uptime, lower latency, higher throughput and scalability. However, these features are nearly impossible to achieve by using yesterday’s software architecture that enabled applications having tens of servers, long response time, hours of offline maintenance and gigabytes of data. There’s now a need for systems that are built for distributed environment, and which can deal effectively with petabyte of data and cloud-based clusters running thousands of multi-core processors.
This is a major reason why many businesses are adopting Reactive Systems for building applications that provide high-end user-experience and help beat the competition.
Let’s get into details of what Reactive Systems bring on the table for your application and how they work.
Top Four Traits of Reactive Systems:
Responsiveness
If an application user doesn’t get timely response, they will go somewhere else because they are not getting the value they expect from your application. Having a reactive System prevents that by responding in real-time. Besides, such systems are capable of detecting errors quickly and fixing them effectively. Being able to provide consistent response times helps comply with tighter SLAs of today, grow confidence in end users and make your app highly interactive.
Responsiveness heavily relies on two other aspects of Reactive Systems: Resilience and Elasticity. Let’s see how.
Resilience
If a system is not resilient, it will not be able to respond under failure, making responsiveness a lost feature of your app. By using replication, isolation and delegation, you can have a Reactive System that is resilient and responsive even under failure. When components are isolated from each other, they can fail and recover without leading to the failure of the system as a whole. Delegation allows another (external) component to take the responsibility of recovery of each component, whereas replication ensures high-availability whenever required.
Elasticity
As workload can vary from time to time, your application should have the ability to stay responsive even under high workload. According to Reactive Manifesto, “Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs.”
Isolation of components from each other and no sharing of resources pave the way for replication. Which translates into running multiple instances of a component at once and splitting the inputs between them. The inputs become asynchronous messages, allowing instances to independently receive different messages. All the instances only deal with the messages they receive, and do not show concern for ordering of a message in relation to other messages. Also, there’s no need to care about how other instances are dealing with their messages.
As a result, it becomes possible to scale up or scale down as many or as few instances of a component running at once as required. This property of growing or shrinking as needed is referred to as “elasticity”.
Message-Driven
Reactive systems are message-driven and use asynchronous message-passing to create a boundary between components. This brings the much-needed loose coupling, isolation and location transparency in the systems. With a boundary established between components, failures go as messages.
Due to this message-driven nature, the system responds in a sensible way when any component comes under stress. The component can’t fail, so it sends a message to the system, telling the fact that it needs other components to reduce its load. This feature is called back-pressure. Message queue monitoring and action-taking ability makes the system capable of managing load, elasticity, and flow control.
How Loose Coupling boosts Performance of Reactive Applications?
Going reactive means using a set of design principles to create cohesive pieces of software that solve individual problems efficiently through “separation of concerns” and “loose coupling”. The architecture of Reactive Systems is so designed that multiple individual components of the software conflate as a single unit and react to changes.
To better understand, let’s take an example. A software that has tightly coupled components would look something like this.
It might be your hard work, but it will not be able deal effectively with a change. All of them would probably fall if anyone of them moves out of the place. So, if your software does not have components that are independent of each other, they won’t be able to work properly in the absence of others.
Now, look at this.
Well, this is made of small reusable components that can be arranged in different ways to solve different problems.
But, think about the effort and the cost that will take for converting it into something showed below.
Besides high cost and time, this might also prove to be a headache for your technical team.
The Takeaway: even if your software architecture has small, reusable pieces, it’s not enough to effectively deal with a change, as new requirements may demand a complete rewrite of huge parts of your system.
Now, look at this.
The picture says it all about how easy it is to change from one shape to another. All you need is to add some toothpicks and balls or remove them to create a different shape. Since the balls are totally decoupled from each other, they can be easily linked with any other through a common interface (the toothpick).
Such a software architecture design makes it possible to effectively react to a change and solve different problems through resilience, elasticity and responsiveness. The picture has its limits and just serves as an example to make it easier to understand what do we mean by decoupling or loose coupling.
What Reactive Programming holds for Reactive Systems?
Reactive Programming is a popular method of writing codes to create components and compose workflows in Reactive Systems. The programming method is event-driven and helps increase utilization of computing resources on multicore and multi-CPU hardware. Besides, developers using Reactive Programming find it easy to deal with asynchronous and nonblocking I/O. What makes Reactive Programming a good fit for developing Reactive Systems is the removal of explicit coordination between active components.
Below are some links to case studies of businesses going reactive, and thereby boosting growth
How America’s largest telecommunications provider Verizon is drawing benefits from going reactive
UK’s online gaming leader invests big on reactive to drive personalization
Walmart sees 20% hike in conversion rates after going reactive
Wix.com user base grows from 5 to 50 million after going reactive
The idea of going reactive is not new as dates back to 1970s. However, it’s only been in the past few years that the emergence of new tools and technologies have helped developers turn the idea into reality by composing complex tasks with ease. Going by the context of multicore, blockchain, Cloud and Mobile architectures, the future of modern web is reactive. Business giants, like Netflix, Slack, Microsoft and Facebook, have already started to power themselves by going reactive, with many more businesses awaited to jump on what has now become the bandwagon.
For any queries related to Reactive Systems and Reactive Programming, get in touch with us using the comment box below.
Comments