Share This Article
DevOps is driving an interesting discussion in the disaster recovery (DR) area. Historically the assumption has been to effectively duplicate your infrastructure and mimic your production environment with your DR site. Organizations would have high quality data centers with full five 9s of everything – including backup power, network, servers, etc – and then they would mimic that complete environment at a DR site.
While, they may not have 1:1 scale from production to DR, they would have enough capacity to cover an outage. If a production infrastructure went down, the switching time theoretically would be quick. In essence, IT would be trading off speed for cost.
For other organizations, though, having a duplicate infrastructure was just too cost prohibitive, so they would work hard to ensure that their primary systems were always operational. They spent more money and time there so that a disaster site was never needed.
Challenging Conventional Disaster Recovery Logic
DevOps and inexpensive cloud computing is challenging the conventional line of thinking with disaster recovery and this new line of thinking could have far reaching effects in the industry. High flying DevOps organizations are building their infrastructures differently.
Their view is that through automation and multiple, inexpensive cloud providers they can create that redundancy much more cost-effectively. These organizations know that they can quickly spin up more resources at their primary provider or even move quickly to others.
Many organizations use load balancing techniques to help them create redundancy as well. The implementation of their infrastructure is controlled by a configuration automation system which allows them to quickly get back up and running. Automated directory services and systems management solutions like JumpCloud also enabled them to manage their multiple sites and/or get back to operational capabilities quickly.
Rethinking Disaster Recovery
JumpCloud surveyed a number of users that focused heavily on automating their infrastructure agreed with this approach. Disaster recovery didn’t scare them in the same way that it had in the past. Implementing their infrastructure from scratch was relatively easy because it was scripted.
They didn’t need to worry as much and they also were less concerned about whether their providers had all of the redundancy layers. They expected it to be there, but it wasn’t a differentiator for them and if it wasn’t fully there, they could easily leverage other providers. By building a stable, high performing infrastructure they felt that they created the up-time that they needed, which was the core issue that they were trying to solve.
JumpCloud has thought hard about how to create redundancy in its own Directory-as-a-Service® platform. Leveraging configuration automation tools such as Salt and Puppet, the process of keeping authentication services operational for its hosted LDAP, RADIUS-as-a-Service, and system user management functions is critical. Identity-as-a-Service platforms are really 100% availability services which is a significant challenge for any DevOps organization.
From an economic perspective, driving more automation into their process enabled them to purchase on the infrastructure that they needed and also limit their costs dramatically on disaster recovery duplication. In short, a DevOps organization plus cloud can quickly eat away at DR budgets and that’s a thing that CIOs will appreciate.
