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.

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