The latest expert opinions, articles, and guides for the Java professional.
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 email@example.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.
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:
- 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.
- 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.
Founder & CEO of ZeroTurnaround
Leave a comment