So LiveRebel 2.0 has landed – what’s new
this time round and sets it apart from the previous
The most important change is that LiveRebel 2.0 can do more than
just hotpatching for live apps , which is what first attracted
users to LiveRebel 1.0. LiveRebel 2.0 is designed to support
multiple deployment strategies, including rolling restarts (aka the
cluster dance) and offline updates as well. We want our users to be
able to completely manage their application and cluster with
LiveRebel, directly out of the box, which is sweet.
Can you explain the thinking behind creating LiveRebel
in the first place? Why did you want to create it?
From the start people were asking us for “JRebel for
Production.” LiveRebel 1.0 was just that, the port of the
hotpatching engine used by tens of thousands of JRebel users to
production, but as we started deploying it to our customers, we
understood that it wasn’t enough. What people really want is to
have an automated way of managing their servers and applications
without ever stopping them. With LiveRebel 2.0 we’re delivered a
fully automated, predictable, transactional and 100% reversible way
to deliver updates that you can confidently roll out to your
customers during business hours, without disruptions to services or
What do you think is innovative about
For LiveRebel 2.0 we created a kind of distributed
load-balancing process, where each server is in charge of routing
requests and sessions to other servers if necessary. This process
allows us to plug into any existing architecture, as we don’t need
any additional integration. Also, it gives us complete control over
the servers and applications, so in the future we can add even more
strategies and features without any changes to the infrastructure.
And it’s wicked cool :)
Personally I’m also extremely proud of the installation and
configuration process. All you need to do, is run a simple
installation script that works with Tomcat, JBoss, Weblogic,
Websphere, Glassfish and Jetty and restart the container in our
wrapper script. This takes minutes even on larger infrastructures
(as the installation script can be automatically downloaded from
our central Command Center) and once you’re done, all servers and
applications can be managed directly. We spent a great deal of time
ensuring that this process is as simple as it can be. And we will
even rescue your application server if it runs out of memory :)
What is the importance of offering different update
strategies? To offer greater choice?
One of our biggest goals is to make the price of an update
proportional to its impact. So a minor update, which fixed a few
bugs and adds a few small features can be applied instantly through
hotpatching strategy. A large update, that changes the application
structure can be rolled out through the rolling restart strategy.
And backwards-incompatible changes to environment and configuration
still need the offline restart strategy.
From command line or Jenkins plugin, we can actually choose the
strategy automatically for you -defaulting to hotpatching if it’s
compatible, rolling restart if not and offline restart if it’s just
I assume JRebel and LiveRebel are designed
to complement each other well?
JRebel lets development teams significantly cut down on the time
they waste redeploying by eradicating the whole build&deploy
phase needed every time a code change is made (i.e. add a new
feature, fix a bug). LiveRebel makes sure that those features and
bug fixes can get to QA & Production quickly and safely. So in
a way, they do complement each other – both are aimed at
accelerating application development, in the broad sense of the
JRebel – are we likely to see you push that further with
new ideas too?
Oh yeah, absolutely. We’re having tons of fun there as well
One thing that is coming in beta any day now is JRebel Remoting. We
noticed that a lot of folks are developing in the cloud now, and
the process is pretty painful. So we designed JRebel Remoting to be
just as seamless in the cloud as it is on your desktop. It’s the
same Save, Alt+Tab, Refresh and just as simple to configure.
JRebel Social was pretty cool as far as licensing models go and you
might see some further development in that area as well.
And we are playing around with all types of ideas. Some of them
would take JRebel in new directions altogether. So stay tuned!
Anything new we can expect from ZeroTurnaround in the near
future? Cooking anything special up?
We are definitely looking at releasing a QA product that would
help the folks that do the testing to manage application versions
better and to have a better understanding of which issues are fixed
We keep an eye on the cloud, there’s a lot of cool stuff going on
and we want to be a part of it. JRebel Remoting is one step in that
direction, but there is more work to be done.
Generally, it’s important to understand what are goals and
values are. We believe in building “consumer” software for
enterprise — software that is dead easy to install and use and
adds immediate value.
We also believe in not going after new and shiny buzzwords, but
rather focus on the existing software that needs to be maintained
and supported. Both JRebel and LiveRebel follow that model and you
can expect other products focused on the Java application
development from us in the future.
You recently released the Developer Productivity Report.
Can you tell us more about it, why you set it up and what kind of
responses did you get for that?
We’ve actually prepared 4 reports in the last 12 months,
including our most recent Developer Productivity Report (Parts 1-4
have been published on our blog
most recently), which is aimed at
getting into the heads of developers and finding out what makes
Our Java Productivity Report 2011
subsequent release of the India Comparison Report
) were very
well-received, and helped us set benchmarks for understanding the
tools and technologies that make Java development more or less
efficient. For example, these reports let us know that the average
developer spends over 10 minutes each coding hour waiting for
redeploys. We also looked into how companies update their Java EE applications in
and saw some interesting results from that too (e.g.
approx 3 out of 4 companies have to shut down their servers during
a production update!)
Everyone seems to be talking about the state of Java at the
moment, some suggesting that it’s on the slide. What’s your
We’ve seen complaints and critics make the rounds over the
years, but our opinion
is that Java is still very much
alive and as strong as ever. From the perspective of a company
whose mission is to make products that enable Java to be as fast,
efficient and flexible as languages like PHP or Python, we see lots
of great stuff on the horizon.
When developers use JRebel, they tell us it’s like breathing new
life into the language, and we hope that Operations teams using
LiveRebel see the distinct advantages of automated, predictable and
safe releases of Java apps.