The song and dance from IT staffers about how public cloud is unsuitable for "real" enterprise workloads is getting old. We're in a period of rapid change, and CIOs must evaluate new technologies, even those their teams are uncomfortable with. Scratch that -- especially those their teams are uncomfortable with.
A prime example is business continuity and disaster recovery. For years we had two choices: Buy redundant gear and data center capacity and do it ourselves, or hire an expensive specialty DR provider. Cloud changes all that. In fact, it's completely reset the game. The savings and agility gains from public cloud disaster recovery are quite real, and we can't pass them up based on fear and resistance to change. CIOs who don't push their teams to consider all options aren't doing their jobs.
We'll discuss business continuity, which seeks continuous operation of the business no matter what's happening in the outside world, and disaster recovery, which seeks to restore service after an acute event, in the unified context of business availability. It's a top priority by any measure, yet there's an incredible amount of dysfunction. Too often, infrastructure teams get put in sole charge of provisioning and testing disaster recovery. But unless the application team is involved, you don't know if your test worked. "The login screen came up, but we didn't bother to log in," sounds suspiciously like, "The operation was a success, but the patient may have died."
Because disaster recovery testing is a time-intensive, expensive, and scary process, unless the CIO gets personally involved and insists that all hands get on deck, systems don't get tested, or the exercise involves not much more than three guys and a pizza. That means we're rolling the dice, every day. Our latest InformationWeek Backup Technologies Survey of more than 430 business technology professionals, all involved with their organizations' backup systems, shows just 23% are extremely confident they could get the business up and running again in a reasonable time frame after a major disaster that takes out the main data center. Asked how frequently they conduct test restores of data or applications, the No. 1 answer is "once in a while." Fourteen percent admit they've never tested their restore process for some applications (10%) or at all (4%).
Slipshod testing isn't the only problem. We need only look at Hurricane Sandy to know that regional disasters often render regional private data centers useless, and that regional service provider resources aren't always available when your organization needs them. The result is that fewer systems are protected than should be, and many CIOs are just a 100-year flood away from unemployment. So you'd think IT execs would be excited about,
We dug into the technical details of the disaster-recovery-as-a-service market in a recent issue. Here we'll explore the role of CIOs in breaking through resistance, because infrastructure teams are not only not excited, they're often outright hostile -- 65% won't even use cloud storage such as Amazon S3. Of those IT groups supporting branch or remote sites, where cloud should be a no-brainer, 28% back up to disk and 14% to tape in each office. Because employees at remote sites can totally be trusted to properly manage tape systems, right?
Security Doesn't Equal Span Of Control
What's the big problem CIOs must overcome when it comes to cloud-based disaster recovery? Control freaks.
Ask an infrastructure team leader about his biggest beef with cloud, and the answer will almost always be "security." But when they talk about "secure," too many times these pros really mean "inside my span of control."
That is, "if it resides on our premises and is managed by us, that's good security; if it resides elsewhere or is managed by someone else, that's bad security." That's just about as logical as the idea that "If someone is a W2 employee at our organization, she is much more trustworthy than someone who is a W2 employee at another organization."
Of course, security isn't about internal span of control. It's about assessing risk and making choices based on the threat level, cost and benefit balance, and a statistical understanding that things go wrong, and it's our job to adapt and respond. If a technique or a technology reduces risk and keeps other variables the same, we should look at it.
We asked security expert Bruce Schneier to weigh in on the notion of cloud-based disaster recovery, specifically how CIOs should answer staffers who throw down the security card. "Like everything else, from tax preparation to cleaning services, it's a question of trust," says Schneier. "Can you trust a company you're doing business with? There's nothing magic about cloud services that isn't true about other services. Does the person who signs the paycheck of the employee make any difference in how trustworthy they are? That seems implausible."
The message: Your company no doubt has processes to vet third-party providers. Establishing trust is possible.
What about the argument that public cloud presents a gigantic attack surface -- that is, Amazon Web Services is a high-value target in the same way Windows is? "Amazon is going to spend a lot more money protecting their attack surface than you are," Schneier says. It'll likely do a better job, too. "It's the same reason you don't have your own doctor no matter how wealthy you are," says Schneier. "You get better medical care because your doctor sees more than one patient."
Cloud providers like DigitalOcean, Google, SoftLayer, and Rackspace have deep experience dealing with attacks. They're doing heavy lifting every day. For most shops, the notion that internal IT staff can do a better job is laughable. Now, that doesn't mean you can laugh off the risks of cloud, including cloud DR. What you can do is take a comprehensive approach that factors in technical realities, security risks, and business needs. And that's an effort that only the CIO, with one foot in IT and one in business, can lead. We'll discuss 12 areas to assess, but first, let's look at two variables that many companies miss in their planning: SaaS use and app dev team needs.