Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

Goodbye, LiveRebel!

Hi folks, Jevgeni here. I’m the founder and CEO of ZeroTurnaround.

Today, it’s my sad duty to inform our users and customers that our LiveRebel product is discontinued as of today. We will refund all of our active customers and will both provide support and help migrate off LiveRebel for another year, until 11th August 2015. All known customers have already been contacted, but if you have any questions please email liverebel@zeroturnaround.com to get in contact right away.

I’d like to thank our users for their support, feedback and patience over the years. We built a beautiful product together, but failed to attract enough customers to make the product sustainable for the company. Without a big enough market approachable at this time, it was with heavy heart that we decided to end LiveRebel gracefully as a preferred scenario for everyone.

Since all the pertinent information about our decision has already been presented in the above text, now I’d like to share with those of you who are interested the whole story of LiveRebel.

It’s one that’s as filled with drama, successes and failures as any startup story you’ll find. I believe that failure is an important part of any success, and would like to share with you as much of the story as I can…

A brief history of nearly everything LiveRebel (for the curious)

The Story Begins (2008)

LiveRebel history begins all the way back in 2008. With JRebel (then called JavaRebel) just starting to take off, we got numerous requests for using our famous classloading technology for making hot code changes in a production environment. Our response wasn’t affirmative at that time, but an idea took hold: could we deploy the same (hotpatching) technology to production?

There were multiple limitations. At the time, JRebel only supported a certain subset of changes, and we were not sure what would happen when individual classes were updated in a highly-concurrent environment. To solve the first issue, we developed a difference engine, one that could compare two versions of the application and determine whether a hotpatch update would succeed. To attack the second, we integrated with the servers and held off requests while the hotpatching update was in progress.

We worked on these problems on and off through 2009 and 2010, and were finally able to release LiveRebel 1.0 in May 2011. It was what everything our JRebel customers had asked for – JRebel for production, complete with the safety features previously described.

Learning curve stage (2011)

During the rest of 2011, we closed exactly two deals. The same customers who were asking for the technology had no authority to actually deploy it to production, as the production environment is typically controlled by the operations teams. The main feedback we got was that nobody wanted a tool that can only apply to a subset of updates. Folks were also concerned that they didn’t know how the tool worked and weren’t sure if they would be able to debug issues should they occur.

We learned that hotpatching wasn’t enough. Never fear–we had an idea! By intercepting requests going to the application servers and cleverly redirecting them during the update we could update one or more servers at a time without application downtime. Moreover, we could do session drain, by only directing new users to new servers and waiting with the restarts until all users on the individual server expire.

Eureka, a breakthrough! (2012)

Armed with these new features, LiveRebel 2.0 was released in February 2012. It could now manage any Java EE application update and would choose the default strategy depending on whether the hotpatch update would be successful or not.

During 2012 we got 25 customers, but most deals were tiny. With the next wave of feedback, we understood that managing only Java EE applications wasn’t enough – the WAR file was just a small part of the release process that can include database changes, configuration changes, release scripts and apps running on platforms different from Java. Suddenly, the vision for the product expanded by an order of magnitude; and, because sales were not happening, we needed to build the vision out as quickly as we could.

LiveRebel 2.5, unveiled in October 2012, included support for executing custom release scripts. LiveRebel 2.6, announced in March 2013, supported database changes, configuration changes and multi-platform releases (in hindsight it should have been a 3.0 release). You could also finally run LiveRebel without the performance overhead incurred by hotpatching instrumentation. LiveRebel 2.7 in June 2013 extended rolling update support to any web platform. What could go wrong?

Applying previous experiences (2013)

Through those iterations, we were getting more and more customers – in 2013, we closed 45 deals with several big installations – LiveRebel was finally getting traction! We also started eating our own dogfood and using it to manage our own infrastructure: our ops team loved it. However, hotpatching and the accumulated technical debt were causing issues with stability and performance, so we focused on those as well as developing support for more complex multi-app release orchestration.

image00

LiveRebel 3.0 came out in January 2014, and it has been all we wanted it to be. It could release multiple applications in one transaction, so the users are not affected if something goes wrong at any point. LiveRebel 3.1 followed up with further performance and scalability improvements, and we finally dropped hotpatching support.

In the first half of 2014, we closed 32 deals and then promptly decided to discontinue the product.

Is there a market in the house? (2014)

Wait, what? What could possibly cause us to make that decision? And why did we make it when the product has seemingly found its stride?

With each iteration while we were building LiveRebel, we were also learning more and more about the release management market. Specifically, LiveRebel was targeting mid-market deployments for dozens and up to a couple hundred servers, whereas most of our competitors were going for hundreds to thousands. We learned, increasingly, that the mid-market was not very good for us for mainly two reasons:

  1. There was no agreement on what release management should even look like. Continuous Delivery and DevOps movements had some ideas, but the approaches were wildly different. Virtual images, microcontainers, configuration management and build servers were all used for release orchestration. Even then, our typical competitor was still just a bunch of bash scripts with a wiki.
  2. Release management was not anywhere near the top problems for a typical potential customer. Release management provides little value if you don’t have automated builds, provisioning and a well-defined release process and unfortunately most potential customers would have none of those.

The deals we were closing were folks who have solved these issues, but stopped short from scripting out their release process or were for some reason unhappy with their scripts. After the LiveRebel 3.0 release, which removed most other reasons the deals wouldn’t succeed, it became increasingly clear that current market conditions do not support the sale of LiveRebel as a product.

The silver lining (2015 and beyond)

In the end, it came down to making tough decisions. Should we wait for the market to develop, change our strategy to go after the top levels, or exit the market to focus on other efforts? After a long and painful deliberation we chose the latter.

So where’s the silver lining?

Well, the bright side to this all is that I feel we have a more consolidated approach to the market that had long been our core focus: DEVELOPERS (…developers, developers!)

So even though our part of the journey with LiveRebel ends here, the next chapter of ZeroTurnaround is just beginning, realigning according to our best strengths. Our JRebel user base continues to grow rapidly and our newest developer tool XRebel is creating a lot of waves by looking at how an interactive profiler can help developer uncover dangerous production issues that might not rear their ugly heads until the app goes live.

Our focus is now dedicated to the development tools market for the near future, building technologies centered around the only real thing ZeroTurnaround has ever really cared about: making developers more productive, more aware and happier.

I promise to do my best to ensure that our tools are a significant step-up from the competition and that help you develop quality software faster. I’m confident that we’ve made the right choice. We have a vision for our future and despite the setbacks, the future is bright.

Yours truly,

Jevgeni Kabanov
Founder & CEO of ZeroTurnaround

  • Andre Schneider

    I’m very sad to hear, that you discontinued LiveRebel.
    Are there any plans/possibilities to migrate this project to an open-source project?

  • Hi,

    Sorry but we discussed the issue at length and decided not to open source LiveRebel. We did not believe that it can be maintained adequately without significant dedicated resources and believed that customers and users will benefit more by migrating away than being stuck on an unmaintained OSS project.

    JK

  • Tomas Vala

    Ouch, what a bummer. ;-( Bye bye small scale continuous delivery. LiveRebel was cool till it lasted.

  • Shane

    I am also very sad to see this go. This is one of the products I highlight for open source projects to use for DEV, QA, and PROD release cycle within an application. I hope that we can discuss this further. Mirko is someone I kept in contact with.

  • Thanks for all your feedback and contribution, Tomas!

  • Slim Ouertani

    Rest in peace @liverebel

  • Ken Blair

    That’s a shame, it looked like a great product. You correctly identified the main problem in using LiveRebel, most places simply aren’t ready.

    Once continuous integration and deployment become common place there will likely be a huge market. Unfortunately I suspect for that to happen some new solutions will have to gain traction and the companies that offer those will likely offer a LiveRebel competitor with it.

  • Hi Ken,

    Thanks for your kind words, we also believe that we built something great.

    As for the future – I would much rather compete with others in a market that exists than sit alone in the market that doesn’t. Competition creates and validates the market.

    JK

  • Yeah, it sucks.

    JK

  • Steve

    Will the same thing happen to xrebel in 1-2 years from now?

  • arhan

    hope not :)

  • I’m confident that XRebel has an amazing future for years and years ahead :)

  • exfromtheleft

    it is sad indeed, it seemed like a great product, my team was considering it. I have a crazy suggestion for you :-) : open source the solution, give to Apache foundation or something, it might just get a second life as a community driven product!

  • Yeah, it sucks. Of course we considered giving it to Apache, but communities don’t appear magically out of thin air.

  • Timo Meinen

    What do you recommend as an alternative?

  • SolrWind

    Rolling restarts. I was just thinking the other day about using LiveRebel (before I found out the news), and was weighing the options: use LR or set up a cluster behind a load balancer and do rolling restarts. The latter gives us high availability while the former does not. So I’m not that bummed since in the end we still have a good solution.

  • David Paterson

    I believe you would get a lot of traction as an apache project. I for one would contribute immediately. There’s def a niche for just this sort of product. Worse case nothing happens, best case you get traction and support contracts.