Typesafe Survey Shows Latest 'Reactive' Developer Trends

By Darryl K. Taft  |  Posted 2015-12-17 Print this article Print
hot tech skills

A new Typesafe survey of more than 3,000 indicates aggressive use of microservices and fast data among adopters of Reactive systems.

Typesafe, provider of a platform for building "Reactive" systems and the company behind Play Framework, Akka and Scala, today announced the results of its survey profiling Reactive adoption in the enterprise.

Key findings of the survey indicate that Reactive system adoption is going mainstream. Indeed, 77 percent of respondents said they are already going Reactive to some degree, with 43 percent researching and prototyping Reactive systems and 34 percent building and deploying systems to production. A further 80 percent said they believe that most successful enterprises will have adopted Reactive systems by 2018.

Jamie Allen, senior director of Global Services at Typesafe, said "Reactive Applications" and "Reactive Systems," terms that can be used interchangeably, represent the ideals captured in the Reactive Manifesto.

Hardware keeps getting smaller, more powerful and more distributed, he said. To keep up with growing system complexity, "Reactive Applications" are defined by the most important characteristics for applications that participate in this new world of multicore, cloud, mobile and Web-scale systems, Allen added. The Reactive Manifesto describes Reactive Systems as embodying four tenets: Responsive, Resilient, Elastic and Message Driven.

"Reactive is the school of developer thought that takes on some of the hairiest challenges related to isolation, dealing with failure of systems in the face of huge user load or device data (IoT scenarios), notions of 'state' and mutability," Allen told eWEEK. "There are also a lot of intersections between Reactive Applications and Functional Programming direction that have become very popular in Scala—and Java 8, which has also taken a more functional approach to application development.

The survey also showed that Reactive adoption is being driven by two key technology trends: microservices and fast data. Also, microservices and fast data users are rallying around a preferred group of tools and technologies, the survey indicated.

Microservices is a software architecture in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. Unlike its sibling big data—which is typically data at rest—fast data is data in motion; it is real-time data not yet stored as big data.

Tony Baer, principal analyst at Ovum, said, "Fast data is not a monolithic technology or solution. Instead, it comprises a spectrum of technologies leveraging high-performance, multi-core processing, often in conjunction with silicon-based storage where price points are becoming more affordable."

Rather than acting on data at rest, modern software increasingly operates on data in near real time, Allen said.

"This is especially true with IoT and mobile apps," he added in an interview. "Consequently, big data is becoming less important than fast data for many companies. As computing systems embrace data in motion, traditional batch architectures are evolving to stream-based architectures. In these systems, live data is captured, processed, and used to modify behavior with response times of seconds or less. There is major business value in sub-second response times to changing information. Think about 10 years ago when you didn't have a critical piece of market information until the day after it happened—now, think about getting that critical piece of information as it's happening. This is going to create a lot of value for companies. After all, fast data is critical to fast knowledge, and businesses want knowledge as quickly as possible."

With the four tenets Reactive systems differ from traditional systems. In traditional enterprise Java apps, services are written in a monolithic way, resulting in strong coupling between the components in the service and between services, Allen said. A system with the services tangled and dependent is harder to write, understand, test, evolve, upgrade and operate independently. The strong coupling can also lead to cascading failures, where one failing service can take down the entire system, instead of allowing you to deal with the failure in isolation, he added.


Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel