LiveRebel 3.0 is here – and its up for even the weirdest environments
JAXenter catches up with ZeroTurnaround CEO Jevgeni Kabanov for the for the full story on the multi-app release capable update.
Jevgeni first wrote the JRebel prototype as an effort to reduce development time while working as R&D director in Webmedia in 2007, and the company has gone from strength to strength since then. JRebel won the JAX Innovation Award for Most Innovative Technology in 2011. He talks about classloaders and ZeroTurnaround in Java Development in many international conferences. He is also the co-founder of 2 open-source projects: Aranea and Squill.
Estonian startup ZeroTurnaround turned LiveRebel 3.0 loose last week – and, it’s fair to say, the software has picked up some pretty cool new toolings since its last major update. With a rejigged database, as well as the ability to unleash veritable fleets of apps simultaneously, it’s certainly worth taking for a test drive. We caught up with CEO Jevgeni Kabanov for the full story.
JAX: What are you most excited about with this release – and what are the biggest changes since LiveRebel 2.0?
Jevgeni: Many things, honestly. This release is the result of a year of gathering feedback from our customers and then eight or nine months of team working on the release. We changed several different things, though not all of them are actually visible on the surface.
The biggest thing that we changed is the ability to release multiple applications at the same time. Building a release tool is actually very hard – and it’s very hard from two aspects.
One is the fact that there are so many environments out there, and everybody is different, so you have to be highly logical. You have to accommodate everyone, and at the same time, enable a very good and very predictable process.
The other really hard part is the integration. Basically, making the whole process virtually failure proof. Whenever anything crashes, or anything goes wrong, you have a back-up plan, right? So, I think those are the two areas where I believe we are strong, and have made us a lot stronger.
When it came to implementing these changes, what were the biggest challenges for you?
The biggest challenge was building a test harness that could accommodate all of those cases that we need to cover, which would be wide enough to cover all of the environments, and all of the different failures that you can encounter.
We spent a lot of that time building tests, and building the test infrastructure to support it. Generally, we were always very much into automated testing. I know that LiveRebel now runs 45,000 tests. That was what a lot of the time went into. We just wanted to make absolutely sure that the customers who downloaded and installed this product would get an amazing experience out of the box.
What’s different about the database this time round?
One of the issues that customers told us about with previous releases was that there were several inherent limitations in the product. For example, it didn’t allow you to deploy multiple same named applications or to deploy multiple applications with different database schema.
There were basically limitations which were simply architectural. And we went through to solve them so that really any combination of requirements that customers may have would be possible. To be able to handle any request, no matter how many schema you’ve deployed, how many modules, or anything else. And finally, just to be able to accommodate more complex and more weird environments.
Can you share a best-practice use case scenario?
We have 17 servers running our services, and we have 42 applications, and 12 different environments. We switched to LiveRebel 3.0, and what it gave us is, thanks to the multi-app support, an amazing overview of what’s deployed where. Before, you had to go per application, but now you literally have this digital staging. All the applications are deployed there, all the versions are deployed there, and all the servers are deployed there also.
The first thing that our infrastructure team told us that they’re really happy to be getting so much information…because when you have that many deployments, they can be really hard to track.
They are also incredibly happy about the release process. Before they had this issue, which the users typically also had, which was that you typically have several things depending on each other. With LiveRebel, you can just press a button, and multiple things come out in one transaction. So if anything somehow fails, they won’t have the case where one application has updated but the other isn’t – things that are dependent go out together.
We also have Java, PhP, and Python applications. So we’re also testing the multi-platform capabilities of JRebel, and it seems to be working great.
One of the biggest goals generally for LiveRebel is to make reviews a non-event, to make them trivial, so that you won’t have to gather your team for that. You won’t have to do anything. You just press the button – that’s it.
Because of the way that LiveRebel handles faults, failures, and user impact – one of its key features is that is supports the zero downtime updates which don’t affect the end users, we’ve got our environment to the point where any update is just the press of a button, and you don’t have to make a fuss about it.
This is the kind of process that some of the big guys enjoy, you know, Flickr, Amazon, using continuous deployment. They put a lot of resources into doing that and supporting it. Whereas, with LiveRebel we can get it with very little cost.
Bringing the luxury of the massive enterprise down to the little enterprise too?
Yes exactly – if you look at our competitors, this is one of our biggest differentiators. It’s not necessarily that we are richer in features, but those features are very well tooled. They are very simple to use right out of the box. So that’s how we view ourselves.
Do you feel this is what makes you stand out in the market?
If you consider our key differentiators, it’s the zero downtime, we don’t take the application down ever. The second biggest thing is that, whatever happens, your users are never exposed to failures. If something fails during the release, the users are not exposed to it. The third thing is the sheer number of release automation tools we have that can be freely downloaded and tested without any professional services or anybody helping out.
You’ve said before you don’t make continuous integration tools – but can you see your products edging more towards this in the future, or do you think this kind of development will remain very separate to what you do?
I honestly see us as very separate. Continuous integration is something I see as a scripting platform for builds and tests, and it’s great for that. What we focus on is the last mile – you’ve done all your scripting, you’ve run all you tests, and the last mile is actually pretty hard. There are multiple problems there.
On the continuous integration side, there are some efforts to extend it to deployment, and I think it’s fine to a point, but I think if people want to protect themselves from failure, and from downtime, they’ll still need something like LiveRebel in addition to what they have anyway.
And building tools for that is a completely different space, it has completely different requirements, and completely different issues. It’s hard to say what will be in the future – there is some overlap – but even if the continuous integration guys move over into the space, it will be a second product baked into the first product.
What’s on the roadmap for LiveRebel 4.0?
Actually nothing – we don’t plan our releases so far ahead. The reason for this that we believe in listening to our customers and understanding what they want. We have several things that we’re juggling – but from a market level, there are some things we can’t ignore. Things like cloud, integration management, continuous integration, DevOps changes – like in culture, monitoring tools, and so forth.
We’re probably going to be looking into getting ourselves better aligned with the market more, and I don’t necessarily know which way we will choose. Our idea documents probably contain around a thousand ideas by now!
What are you most excited about in Java 8?
I’m quite excited about Lambdas – though less so than I used to be, as I haven’t written code in many years. I think the language is moving in the right direction, and I think the only thing it’s missing now is local type imprints. I think everything else is there.
I’m quite happy with Java 7 as well – Java 8 is better – but I don’t think it’ll make a world of difference either way. It’s a nice incremental improvement. Some people see it as revolutionary, but I don’t see it. I think it’s going to be good old Java in the end. It’s more about the tooling than the language – that’s what makes it amazing.