According to a 2015 survey by IT Revolution Press in conjunction with Puppet Labs, organizations using DevOps deploy code 30 times faster than others, doing deployments multiple times per day. Moreover, change failure gets cut in half with DevOps and services are restored up to 168 times faster than they are at non-DevOps organizations.
DevOps: Failing more quickly, and recovering faster
Let’s focus on those last two points for a moment. One thing is for certain: Embracing DevOps also pays off from a disaster recovery standpoint, because the tools and procedures that you use to move applications from development to testing to production and back to development again can also be applied to failing over and recovering from disasters and service interruptions. The same tools that automate the entire DevOps life cycle can also help you make the most use of the resources you already have for recovery purposes.
There are indeed plenty of open-source tools to help with this automation, like Chef and Puppet, which create, launch, and deploy new virtual machine instances in an automated way and configure them appropriately. They even work across security boundaries, deploying on your private laptop, in your own data center, or even up in the public cloud — Amazon Web Services and Microsoft Azure are two major public cloud providers that support Chef and Puppet. By using these tools, you can not only automate the deployment of new code your developers write using carbon copies of their development machine environment and configuration; you can also orchestrate and launch a backup environment in the cloud in a matter of minutes. If you combine Puppet and Chef with a tool like Oracle Ravello (if your public cloud is Amazon Web Services or Google) for your VMware and KVM virtual deployments, you can literally nest hypervisors so that you can run your virtual environments in the public cloud as they are — with networking, addressing and more — without any changes, deployed in an automated way. These are really powerful tools both from a DevOps and a disaster recovery perspective. You can quickly build software, test it, deploy it, mitigate bugs and provide robust failover and recovery solutions using these same tools. Continuous deployment becomes continuous disaster recovery and failover.
[Related: Is DevOps good or bad for security?]
The prime tenet of DevOps is that developers should be writing code and testing their apps in a copy of the production environment in which their code will run. This is often nearly achieved using virtual machines and container solutions like Docker running on individual laptops or desktops. This is much better, of course, than just writing code blindly in Xcode or Visual Studio and then shipping packages to system administrators to deploy, but I said nearly in the previous sentence because even this type of virtualization does not entirely simulate the capacity constraints of a real world production environment. It’s difficult to test a real load against a containerized microservice running on an Apple MacBook Air, for example, but load testing could be carried out in a more realistic, actionable way against a full Azure Stack service deployment, for instance.
Disaster recovery environments as potential DevOps workspaces
Some companies find that, as they further embrace DevOps on a deeper level, their developers will constantly ask for access to the hot spare disaster recovery environments to mitigate that “single laptop or desktop” constraint. Generally, midsize and larger organizations have significant investments in backup infrastructures that are almost exactly carbon copies of the environments that are running critical production workloads and are at standby in case those workloads need to be ported over in the event of a service disruption or a disaster.