Rebel Yell, LiveRebel 2.0 is here

Rebel with A Cause: Interview with Jevgeni Kabanov

Chris Mayer

With LiveRebel 2.0 appearing recently, we wanted to talk to one of the key men behind it. We talk to ZeroTurnaround’s leader about the latest version and general Java goodness.

So LiveRebel 2.0 has landed – what’s new this time round and sets it apart from the previous version?
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 user sessions.
What do you think is innovative about LiveRebel 2.0?
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 one server.
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 term.
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 where. 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 them tick. Our Java Productivity Report 2011 (and the 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 production 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 opinion?
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.
Inline Feedbacks
View all comments