Enterprise deployment of “reactive” systems is no longer a fringe concept enjoyed by a handful of early adopters. According to the Reactive Manifesto, developing these message-driven, elastic, resilient, consistent, and highly responsive applications is what’s fueling the new wave of systems that are deployed on everything from mobile devices to cloud-based clusters running thousands of multi-core processors.
Users expect millisecond response times and constant uptime.
See also: As Systems Get More Complex, Programming Is Getting “Reactive”
Web-giant enterprises like Twitter, Facebook, Google and Netflix measure their data in petabytes, but even smaller companies face enormous pressure to keep pace with the market. Expectations have changed—rather than batch processing, both users and lines of business expect data to be processed in real-time for both user experience and a competitive advantage in the market.
This can strain legacy architectures, even those dealing with “medium data” measured in gigabytes. On top of user expectations being significantly higher today than a decade ago, the pressures facing enterprise operations teams to manage resilient, responsive systems is brutal; most existing technologies available today are not designed to deploy and manage reactive systems running on clusters.
Chain Reaction
Typesafe, developers of Akka, Scala, and Play Framework, and a company I’ve covered several times because of the cool open source things they help to build, have launched a new tool to manage reactive applications called ConductR.
I spoke recently to Kevin Webber, who joined Typesafe last year as a developer advocate. Most recently he led the team that redesigned Walmart Canada’s new e-commerce platform. Walmart’s platform was built on Akka, Play and Scala.
ReadWrite: What’s driving this new scale challenge where monolithic applications are morphing into microservices?
Kevin Webber: The short answer is that enterprises need reactive systems to respond to growth in mobile computing and the Internet of Things. The rapid cycle of technological innovation is troubling for enterprises.
If we look back 10 years to 2005, you’ll notice that we didn’t have the iPhone, Facebook, Twitter, Netflix streaming, Kindle, App Store, Spotify or Big Data tools. In 2005, the average household of consumers would have one or two computers—a desktop and laptop, let’s say—that would connect to applications running on one or two redundant servers. Internet connectivity wasn’t especially fast, and applications weren’t especially fast.
Let’s face it, by today’s standards nothing was really that fast. And most of us were fine with it—back then.
Jumping forward to 2015, we see the need for a major change in the network topology of enterprises in order to meet the demands being placed on back-end infrastructure. What has happened is that the very same household now has multiple devices per person—all of which may use different protocols and platforms. Now we have a multitude of devices connecting to a multitude of application server instances.
A single application server simply can’t handle the strain, no matter how much vertical scalability is attempted. There’s only one option—to scale out.
Managing Reaction
RW: So Typesafe believes that while the development side of the organization is embracing the principles of reactive programming, the operations side needs new tools for managing these new applications?
KW: Yes, enterprises have begun embracing the concept of architecting reactive systems for many reasons: they are more flexible, loosely coupled, and scalable. This makes them easier to develop and amenable to change, plus significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster.
Because enterprise systems are being built as smaller individual applications rather than the giant monoliths of the past, the next logical step is to enable operations to intelligently deploy and manage their production systems using the same reactive principles.
Whereas 10 years ago a system may have been comprised of a handful of core applications, now a system may be comprised of tens or hundreds of smaller, lightweight applications. Although distributed, more resilient against failure and capable of handling much higher loads, reactive systems are actually safer, more predictable and easier to manage and deploy than traditional systems; however, they differ from traditional architectures and this unfamiliarity must be managed using new approaches and tools.
Armed with existing solutions, is your ops team confident that they have the tools needed to handle the demands placed on enterprise infrastructure in 2020? Software architectures are changing; the real question is if your operations team is ready to handle these changes.
We will be the first to say that the challenges of deploying and managing reactive systems are not obvious to the casual observer. Without technologies designed specifically for distributed architectures, there are several reasons why we believe enterprises are struggling to deploy and manage reactive systems:
- Existing operations processes and methodologies are inadequate for reactive systems.
- Existing operations tools and technologies are inadequate for reactive systems
- The costs and risks of downtime using inadequate solutions are higher than ever.
How To React To Reactive
RW: So how should reactive-inclined enterprises manage this new complexity?
KW: That’s what ConductR is for. The idea behind ConductR is to let operations teams experience the same convenience that development teams get using Play Framework to build their reactive applications.
Indeed, your system needs to be designed in a reactive way—minimal shared state, for example. Here, resilience is key. You should be prepared for your database to disappear at any point in time.
Once you’re that resilient, then you can move around a cluster very easily, shifting load over to active areas and reducing latency to a minimum. Once your apps are tolerant enough to lose everything, shut down and immediately restart somewhere else, then you’ve got yourself a reactive system.
RW: How does ConductR fit into an enterprise’s new architecture?
KW: Enterprises have other tools designed to handle provisioning, virtualization and other infrastructure needs for your machines and cluster, so ConductR was designed to work well with existing technology and promote the four tenets of reactive systems—responsive, resilient, elastic and message-driven.
Photo courtesy of FitStar
