LiveRebel 2.0 - Down for maintenance? Never again.


News: LiveRebel 2.0 - Down for maintenance? Never again.

  1. Remember those “Down for Maintenance� signs? Seeing that on any site means something’s not going right. Behind every ‘Down for Maintenance’ sign is frustrated operations staff, sleep-deprived developers, and angry managers letting everyone know how much money the company is losing with every minute of downtime. It is an awful experience for everyone involved.

    In May of 2011, we released LiveRebel 1.0 - a tool that brought the hotpatching technology that powers JRebel to production environments with safeguards like compatibility checks and stop-the-world updates. As more and more users deployed in production, we realized that hotpatching was just the beginning. Wouldn’t it be great if there were a tool that could be dropped into an existing infrastructure, easily start managing the production servers, and would allow any and all updates to be applied with no downtime?

    LiveRebel 2.0 is that product.

    The most common way of updating an application online is often to take one server at a time from a cluster, stop it, update the application and restart it. Immediately after LiveRebel is installed, it adds the ability to do rolling restarts completely automatically.


    Of course, we make this all possible without any changes to the existing infrastructure, due to the fact that with LiveRebel, which is all Java-based, every server can act as a load balancer, redirecting the new sessions to other servers while keeping the existing ones where they should be. So from both a user perspective and the administrator perspective, all servers are alive and functioning at all times, with all the redirection happening as if by magic.

    So what does this mean?

    • Every single update is an online, transactional, reversible operation that is completely automated and, in case of minor updates, instantaneous.
    • When something goes wrong, as it inevitably does, there is a panic button to press that will make it all better.
    • The application stays online, the updates can be done during the day and the business doesn't lose a cent of revenue.
    • Developers can see their code in production faster. At an extreme, the code can even be deployed continuously, since fixing or reverting things is so darn easy.

    It means that you are happier, and that makes our day.

    It is our pride and pleasure to present LiveRebel 2.0.

    Threaded Messages (2)

  2. Schema and DB changes?[ Go to top ]

    How are these handled? These have always been the most common reasons for downtime (even if its planned) at the places I've worked. 

  3. Schema and DB changes?[ Go to top ]

    One of the goals for LiveRebel is to differentiate between different kinds of update and provide corrresponding strategies. If the database update is backwards compatible, as it often is, you can apply that before you apply the application update. If the database update is incompatible, but minor, there is a way to apply it during Hotpatching, by pausing the user requests until it's complete (users see a pause, but the request and session are still completed successfully). If it's not backwards compatible and not minor, well, then you do need to go offline. Our goal is really to make the cost of the update proporional to it's impact. We have a customer who does 2000 updates a month with LiveRebel and is real happy about that.