JAX London 2014: A retrospective
Critical thinking

Typesafe CTO: the Reactive future on the JVM is very bright

ClaudiaFrhling
typesafe-logo

Typesafe’s Jonas Bonér explains why the Reactive Manifesto is key for the for the future of high quality development – and why it’s good news for Java devs.

  • Jonas Bonér

    Jonas Bonér the co-founder and CTO of Typesafe and the inventor of the Akka project. Learn more at: http://jonasboner.com

Since it went live last summer, thousands of people have signed up to adhere to the standards of the Reactive Manifesto – a blueprint for writing Reactive Applications. In this interview, Typesafe co-founder and CTO Jonas Bonér  tells us why the Manifesto is so important for addressing contemporary development issues, and just how ready the Java ecosystem is for a Reactive future.

JAX: More than 4.000 people have already signed the Reactive Manifesto. First things first: What exactly were they signing up for?

Bonér: The Reactive Manifesto is a conceptual framework for what it means to build high quality software that lives up to the hardest challenges of today: mobile, cloud, multicore, very impatient users that want real-time and interactive, and massive concurrent usage. The list of challenges goes on and on, and then you of course have complicated technical decisions, because any non-trivial application today is “polyglot”, meaning you have to use different tools, languages and frameworks to address the range of problems.

So the Reactive Manifesto is there to try to establish a common and shared vocabulary and a way try to put focus on the essence—the core principles—and not be distracted by differences in techniques, languages, patterns and idioms. Signing the manifesto is just a way of showing your support to this effort, that you are agreeing with the principles outlined in the manifesto and that you want to help out changing the way applications are built.

Why is it so important for APIs to be asynchronous and non-blocking today?

Because truly scalable, responsive user experiences require managing failure in a way where things can fail in isolation, instead of cascading.

Applications today needs to be asynchronous, non-blocking and share-nothing. This mind-shift in application design leads to a lot of nice and essential properties such as elimination of contention—enabling truly scalable applications and more efficient use of the hardware, and loosely coupled systems—that you can evolve and maintain independently and in which parts of the system can fail, be restarted or upgraded independently.

The manifesto states: “An application must be Reactive from top to bottom.“ What does this look like?

It is very important that the Reactive principles are adhered to across all the layers in the application stack. All layers and libraries need to participate.

For example, if only a single service, in a long request chain, block (on IO or something else) then the whole request pipeline stalls and consumes a thread without doing any useful work. This is very wasteful. Threads are a precious and limited resource and should only be held on to when doing useful work, else they should be handed off to someone that can use it more efficiently. Never sit on resources you don’t use. They key principle here is to be event-driven all the way.

Another example is resilience. For an application to be truly resilient it needs to be loosely coupled from top to bottom (and communicate failures through asynchronous events). This is the only way to avoid cascading failures where one service that goes haywire can take down the whole application. Compartmentalization—sometimes called bulkheading—needs to be applied everywhere.

The same is true for responsiveness; it does not matter if all but one of your stages in a computation or request pipeline is extremely responsive—one guy can the ruin the whole party and render the application completely unresponsive.

What is Typesafe’s role in the Reactive Manifesto – especially with the Akka framework in mind?

Typesafe’s role in the manifesto is not more than the fact that it was me that initiated it and wrote the first version. It is an open document with many participants and has no direct connection to Typesafe. However, we strongly endorse it. At Typesafe we believe that Reactive applications is the way of the future (and the present for that matter). The Reactive principles are our bread and butter and affects all parts of the Typesafe Reactive Platform; Play, Akka, Scala, Activator etc.

One of the benefits for us is that it’s an effective teaching instrument for developers that want to understand how the early adopters in Reactive—companies with the most stringent requirements, like Twitter, LinkedIn, Netflix—approached the problem set. There is a general education process to help the market see that the set of requirements that those companies have conquered are starting to apply more universally.

The Reactive Manifesto describes a “perfect world” scenario, i.e. that all I/O must be non-blocking or that all clients should be attached via two-way asynchronous message passing. What do you think the largest challenges are for fully adopting the Reactive paradigm, both technically and at an administrative level?

One big challenge is the database layer. The latest JDBC specification do not support async APIs and most popular SQL databases do not even support it in their proprietary drivers (exceptions being MySQL and Postgres). It can be addressed by using patterns like CQRS (perhaps using the new Akka Persistence module) or by using NOSQL databases with asynchronous APIs, but that feels unnatural to a lot of developers…yet another new thing to learn. We just have to continue lobbying for adding async APIs to JDBC, but the JCP (Java Community Process) is moving slowly.

Another challenge comes back to education. Building Reactive applications require you to think and design your application in a different way. In my experience the initial learning curve can be quite steep, but then it flattens out. You take an immediate hit by the essential complexity of the domain and problem you are trying to solve, but there is close to zero accidental complexity. Compare this to trying to solve the same problem using traditional techniques where the familiarity of synchronous calls and shared mutable state makes it very easy to get started but where it very quickly gets out of hand and you get drowned in the accidental complexity—making the system brittle, hard scale, to understand and evolve.

Is the Java ecosystem ready for the Reactive future?

For starters, it’s great news for Java developers is that one of the main features in the new Java 8 release is Lambda Expressions (lambdas)—which will make it easier to write applications in a more functional style. This will help a lot. It’s been possible pre Java 8—a good example is Google’s excellent Guava library. But it’s been a bit clunky, so I’m very excited to see how lambdas will take off and change the picture. It is also good to see Oracle making the effort to retrofit lambdas on top of the existing collections, adding abstractions like Stream, and enhancing the concurrency library with things like the non-blocking composable CompletableFuture—all taking advantage of the power of lambdas.

There will definitely be a spectrum of how aggressively the Java market moves on Reactive. For example, it might not be immediately obvious what the real benefits of async are to a Spring + Java developer. For a very simple app or proof of concept, it might be that a synchronous old school solution looks simpler. But as soon as you have demands for scalability or using the hardware well or you have to have a system with resilience, then you have so much complexity with that synchronous—you get that exponential complexity. After a while you just do a re-write, then back to zero, then it increases again.

A system with Reactive has a steeper curve at the beginning, but then it flattens out (as we discussed earlier). So you take the hit immediately instead. Taking that hit at the onset is a different mindset.  There’s a learning curve of the whole different way of thinking how you take a problem, deconstruct it into modules or elements, and it’s a little different when you’re thinking Functional instead of Object-Oriented.

But yes, there are a lot of interesting things happening in the Java ecosystem right now. More people are starting to embrace Reactive and we can see frameworks pop up here and there—like Reactor, Vert.x, RxJava and others—all driven by the need to go Reactive. And of course, Typesafe’s Play and Akka are ready for Java 8 with top-notch Java APIs all leveraging the power of lambdas.

So the Reactive future on the JVM is very bright.

Author
Comments
comments powered by Disqus