Art of Rollback III: Rollback Strategies Through the Ages
By Pierre-Boris Bonafous

Let's recap what we learned from the previous chapters in the series: episode 1 and episode 2.

We learned that a good rollback mechanism cannot be designed without having an intimate knowledge of the application architecture, the nature of your components and their dependencies. Now that we know what we have to restore and in which order, the question is how?

There are always different possible strategies available to restore your services. The only criteria for deciding which one to choose is speed. For this reason, the rollback must be automated and the best rollback features available must be leveraged for each of your application components and technologies. The automation tool will be in charge of the orchestration of the different technologies involved in the rollback process.

How Much Money Should You Spend on Rollback?
Always go for the fastest process you can afford. No company can afford data loss, data corruption and service interruption. Never cut cost on this part. Trying to reuse old backup systems or mutualized backup, for example, is not advisable, as investing in new technologies can give you more reactivity with an immediate ROI.

The budget of rollback implementation should be calculated at the beginning of your project, according to the cost of an error for the business and not by looking at best solution price or providers' bundles available on the market.

The acceptable cost of an error should not be estimated by Ops or Devs but by the business itself, as it can be a mix of unexpected factors. Some are part of the company plan and should not be shared internally. For example, it can be related to the company share price, risk assessment, compliance and compensation, SLA and penalties, customer retention, sales objectives, transactions per days and so on...

Time is money, so the equation is really easy to solve for Ops: the maximum recovery time objective (RTO) of an application depends on the maximum acceptable loss for the business. Your company may already have defined this metric in the disaster recovery plan.

Unfortunately, like most other technical services, the rollback system is too often taken in account at the end of a project. This is a big mistake as the cost of implementing the rollback can be huge, sometimes higher than essential features like automated deployment or monitoring. The rollback cost does not only include the cost of the implementation and the possible additional tools but also the cost of maintenance and regular testing of the rollback system.

Automic is helping his customers to create value with automation. Automated deployments and automated rollbacks must be considered together as a whole when you want to cover the Release Automation activities.

Static Components
Let's take a look at the most popular rollback strategies implemented today for static components. There are two different ways to manage immutable components: restore and switch.

Restore Rollback: This is the traditional way to roll back, from a time when applications were installed on premise, on physical boxes, and when the materials and software were expensive. Thanks to virtualization, containers and automated provisioning, the restore approach has enjoyed a renaissance. The original intent was to simply to reinstall the previous version of the application(s). That can be done by overriding files, uninstalling/reinstalling binaries or going back to a restoration point.

Today it's more about redelivering the previous complete application stack, pre-configured: the OS, the middleware and the application layer itself. Virtualization has paved the way with templates and Gold VMs. But container technologies like Docker do even better, as you can instantiate a container from an image in a couple of seconds. You have to re-instantiate a container from the previous images instead of delivering old binaries

Automic Release Automation enables you to define rollback at the workflow or job/task level. When the default rollback is activated, you can assign backup and rollback tasks. The backup task will be executed before the main action, while the rollback task will be executed in case of failure.

However, not every application today is a good candidate for containerization. If this is the case, you can go for the switch strategy, to achieve the same outstanding performance but for old systems.

Switch Rollback: Switch rollback maintains two releases of your application in parallel but makes only one accessible to your users while the other remains offline. When you want to deploy a new application release, you install the new release on the offline system. Once the new version is ready you just have to put the old version offline and new version online. If you want to rollback your application, you just switch back.

The switch can be really transparent when the application is a bunch of files in a flat directory. All you have to do is to switch two repositories with the old and the new release content. Sometimes it can be trickier if you rely on an application server or a cluster.

Blue-green deployment is a typical example of switch rollback. The blue environment is offline and the green is online. An environment can be a cluster or collection of machines. The switch (or change of color) can be done quickly by reassigning the IP addresses between the blue and the green machines in the DNS, in the load balancer or at the proxy level. Another advantage of blue-green deployment is that the rollback does not need a specific procedure because it the same procedure used for the initial rollout.

How much does this cost? Well, you must maintain a duplicated platform. That can be quite expensive if your platform is a cluster or a server farm. However, virtualization and automated provisioning can help you to limit the cost of administration, licenses and maintenance of the blue platform if you build and destroy the environments on the fly.

Dynamic Components
As you may be aware, immutable components are not an issue anymore. The problem we must solve today is rolling back dynamic components. Data is now stored on various formats: files, relational databases, NoSQL databases and so on... each technology with its own properties for recovery management.

In this scenario it's difficult to rollback without downtime or data loss if you do not have specific features embedded in the application itself. Some examples of possible function could be a data resilience system, a database virtualization layer, a data cache mechanism or treating your database structure as code.

Let's take an even more simple use case: a database upgrade with zero downtime. Not all databases can support that feature. There is no set plan to follow so you must exploit the best technologies available on the market like checkpoints or point-in-time recovery for databases and snapshots for virtual machines when your software architecture does not support rollback natively.

In fact, the only way to achieve zero downtime and to keep control of your data during deployments and rollbacks is to design backward and forward compatibility in the application itself. But this is another story...

Next Episode
Rolling forward; Why is it better than rollback? Because rolling forward is the best way of accepting that we, Dev and Ops, are intimately involved in time-flow, no matter what Albert Einstein or Brian Green told us! Stay tuned.