"Marathon Man" and cloud storage: Is it safe?

Anyone who has seen the 1976 film Marathon Man, will no doubt recall the cringe-inducing scene where a sadistic Nazi dentist (played by Laurence Olivier) tortures the protagonist (Dustin Hoffman) by drilling into his teeth without anesthetic. Throughout the ordeal, Olivier constantly asks, "Is it safe?" Not knowing what "it" refers to, Hoffman can't come up with an answer to avert the torture.

For those of us in a cloud-related field, the same question -- "Is it safe?" -- is only slightly less cringe worthy. Here again, at least part of the torture stems from the lack of clarity about the question itself. When asked if public cloud storage is safe, (or cost effective, scalable, high-performance) the only correct answer has to be, "Compared to what?"

Most IT "safety questions," usually come down to two separate, but related issues:

• Security: How certain can you be that bad guys won't get at your data; and,
• Availability: How certain are you that the good guys can get to the data when they need to? (i.e. that the data won't be lost, corrupted or unavailable when needed)

Security

Let's start with security. A perusal of the security pages for two of the most well known public cloud services make it clear that serious providers make enormous investments in physical, logical and network security, including validating their security levels through numerous external accreditations. The economies of scale enjoyed by public cloud providers (not the least of which include the ability to hire some of the best security practitioners), enable investments in security that most enterprises simply can't afford. Moreover, public cloud operators are often under both legal and contractual requirements to report any breaches or security failures, and are subject to the scrutiny of a large number of customers. This makes it less likely that issues will go unnoticed or unresolved. Finally, it is important to remember that the vast majority of data thefts are inside jobs. The use of a public cloud provider may make it easier to implement best practices like segregation of duties, user level access control, data separation, etc.

All of this is not to say that one can delegate all security to the cloud provider. For example, organizations should take responsibility for cryptographic management or both data in transit and -- where appropriate -- data at rest.

Availability

Now, let's look at issues of availability. These certainly came to forefront in April 2011, when high profile outages at AWS data centers led many to question the viability of public cloud services as a whole.

Failures of one form or another are endemic to data center operations. Routinely servers and disks fail, power lines get cut, surges in usage overwhelm available resources, blizzards keep employees from getting to the data center, etc. Less routinely floods, fires, natural disasters, or 9/11-type events take out entire data centers.

The question should really not be, "Can failures occur in the public cloud?" Of course, failures will occur. The real questions should be "How frequently do those failures occur?", "How easy is it to minimize the impact of those of those failures?", and "How expensive is it to reach a particular availability level?" In all cases, these questions should be viewed in comparison to what is achievable on-site.

While the outage garnered a lot of attention (no doubt because of the high profile of impacted customers), it is worth noting that several high profile services that run their own data centers have experienced similar failures over the past several months. Would the impacted customers have been safer or experienced better levels of availability over the long haul had they been in-house? I suspect not.

There are several reasons for this:

a) Because of economies of scale, a cloud service provider can invest far more in robust and redundant power supplies, cooling equipment, physical and logical security, etc. than a typical, self-run data center. They can also invest more in monitoring services and employees to respond to device failures.

b) Used appropriately, public cloud services make it possible to distribute workloads across multiple devices (thus minimizing the impact of any particular device failing).

c) Used appropriately, public cloud services make it easy to flexibly and quickly provision additional resources to handle usage spikes.

All of the above items relate to the frequency and impact of failures within a particular data center.

It is important to note that with these services, users also have the ability to minimize the impact of the failure of an entire data center. Many cloud providers offer multiple, physically separate data centers, (with separate power supplies, water supplies, personnel, etc.) both within and between geographic regions. Thus, with the right supporting technologies, it is possible to replicate data between different data centers (including between both public and private centers.)

As should be clear from both the availability and security discussions, public cloud storage -- if used appropriately -- offers many organizations higher levels of "safety" than they could feasibly attain from on-premise solutions. While I have no doubts about my dentist's skills as a dentist (and, yes, he does use anesthetic), I am fairly confident that any medical records his office would keep in reputable public cloud services would be quite safe compared to the same files on his office computer system. I suspect the same is true of data for most mid-sized enterprises for which IT operations are not considered a core investment area.

For those organizations who do have substantial IT operations capabilities, have unique security concerns (e.g. healthcare or financial institutions), or have unique performance requirements, a hybrid between on-site and public cloud storage may be the best answer. More on that in the next post.

In the meantime, keep flossing.

Ben Golub was CEO of Gluster, Inc. , which is now the Storage Business Unit of Red Hat. He is on Twitter @golubbe.