Podcast: Is Your Data Really Safe In the Cloud?

Earlier this week, over on InformationWeek's sister site that's dedicated to Cloud Computing -- Plug into the Cloud -- George Crump asked a question that I thought I knew the answer to: Is data in the cloud risky? Crump points to a "recent report that the FTC is considering a request to shut down Google Apps." But after I got done laughing at such a waste of taxpayer money, I turned back to the seriousness of the question at hand.

The cloud is infallible, right? Although Crump doesn't answer the question, he implies that the same practices that work for protecting on-premises IT can serve you well should you decide to move some amount of data into the cloud. Writes Crump: <p> </p><blockquote>...companies like Iron Mountain, Nirvanix and Bycast have the ability to have a mixed deployment model with local appliances to cache data before being transfered to the cloud storage data center.</blockquote> <p> But is data in the cloud at risk? Must you turn to third parties to guard against a catastrophe or do the various cloud providers have you covered out of the box? </p><p> I never stopped to give the question serious thought until last week when I had the opportunity to chair a panel on cloud computing at Sun&apos;s CommunityOne East Conference in New York City. Sun Cloud CTO Lew Tucker had a reserved parking spot on the panel. But the rest of the guests -- Google App Engine product manager Pete Koomen, Rightscale CEO and founder Michael Crandell, and Salesforce vice president of developer marketing Adam Gross -- were my picks. To hear the recording of that conversation in its entirety, you can press the miniature play button here <a href="http://media.libsyn.com/media/interop/Cloud_Computing_Panel_At_CommunityOne_East.mp3">to listen to the podcast</a>. </p><p> The dialog on the cloud&apos;s reliability really got going around the 42:22 mark where Michael Crandell had said the following: </p><p> </p><blockquote>Any public service, any cloud-oriented service is extremely publicly exposed so the slightest glitch makes headlines and we&apos;ve all seen some of those recently. But if you talk to anyone who has run any size of datacenter internally, they&apos;re not judgmental at all because they&apos;ve had bigger outages. And more severe outages...</blockquote> <p> Bigger? Well, to be clear, it&apos;s all relative. When millions of users lose access to their Gmail account because Gmail is flaking out for some reason, that&apos;s a petty big outage that would be tough to beat. But relatively speaking, I think the point that Crandell is making is that for each organization that has experienced on-premises email outages, that those outages were &quot;bigger&quot; to that organization than any of Gmail&apos;s outages would have been (to that organization). Crandell went on: </p><p> </p><blockquote>... Cloud services actually provide better redundancy, better failover You have to be quite a large company with a lot of investment in multiple datacenters over different geographic areas to achieve the same kind of reliability that you can get today at 10 cents an hour.</blockquote> <p> This of course is the benefit of cloud computing. No matter what size the customers are, they all get to benefit from the cloud provider&apos;s investment in scale which, by the very nature of the business the cloud provider is in, must dwarf the investment that all but the very largest companies are prepared to make in their datacenters. But scale and reliability are not necessarily the same thing. Later, at 53:05, Crandell said: </p><p> </p><blockquote>Instances on Amazon, when they terminate for whatever reason -- you terminate them intentionally or there&apos;s a hardware fault -- the local storage on that instance is gone and that&apos;s why of course they also came the storage model around S3 and Elastic Block Store and Sun is doing the same thing. So, it is up to you to make sure that your model of storing data keeps your data safe.</blockquote> <p> Here, Crandell is referring to the virtual nature of Amazon&apos;s Machine Images (AMI, which coincidentally happens to stand for Amazon Malaria Initiative as well) used in Amazon&apos;s Elastic Compute Cloud. One of the differences of working with virtual machines when compared to real bare metal (physical machines) is that you must deliberately save or preserve any work or data that may have been added, changed, or deleted between the time the virtual machine was started and the time it was &quot;ended.&quot; Some virtual machine solutions do this automatically for you. But, in the case of Amazon&apos;s EC2, Crandell is basically saying that if the hardware in Amazon&apos;s datacenter that your virtual machine happens to be relying on fails in some way, then whatever data was in that image at the time of failure will essentially fail too. There&apos;s no opportunity to preserve it. </p><p> This naturally begs the question &quot;What are the odds that my machine image will be running in some virtual machine on a piece of hardware in Amazon&apos;s datacenter that decides to ABEND itself?&quot; Off microphone, I asked Crandell if such hardware failures within Amazon&apos;s EC2 infrastructure ever occur. He would know. His company Rightscale has built an entire business out of making Amazon&apos;s EC2 work better for customers than it does &quot;out of the box.&quot; According to Crandell. They do occur. Not often. But they do in fact occur and unless the owner of the image has taken certain precautions to protect the data, such failures take the data with them. </p><p> I contacted Amazon to see what it had to say about the matter and Amazon confirmed the scenario that Crandell describes. But, as it turns out, Amazon itself offers one of the countermeasures that can be taken to ensure that should an image fail, that the data that image was working with is preserved. According to Amazon spokesperson Kay Kinton: </p><p> </p><blockquote>Amazon EC2 offers many options for users to store their data.The behavior that you describe is true for the instance stores that come with an instance. The instance stores can be thought of as &quot;local disks&quot; on the instance, and if the instance is terminated or fails, the data on that instance store will be lost. These instance stores are useful for many applications. <p> Amazon EC2 added the Amazon Elastic Block Store (<a href="http://aws.amazon.com/ebs/">Amazon EBS</a>) last August to give customers a reliable disk option for their Amazon EC2 instances. With Amazon EBS, developers are able to provision reliable volumes and attach them to their instances. These look to the instance like standard block devices (i.e. hard drives) and customers can use as many as they need to store and persist their data. Amazon EBS volumes are automatically replicated within a single Availability Zone to protect users from failure of independent components. Additionally, with Amazon EBS, users also have the ability to easily take point in time snapshots of EBS volumes to Amazon S3 for long term durability.</p></blockquote> <p> Of course, EBS doesn&apos;t come free. According to <a href="http://aws.amazon.com/ebs/">Amazon&apos;s Web site</a>, </p><p> </p><blockquote>...you only pay for what you use. Volume storage is charged by the amount you allocate until you release it, and is priced at a rate of &#x24;0.10 per allocated GB per month Amazon EBS also charges &#x24;0.10 per 1 million I/O requests you make to your volume.</blockquote> <p> Whereas you&apos;re on your own to decide how to cover the data kept with an instance of a machine on Amazon&apos;s EC2, other cloud offerings bake such redundancy right into their service. I checked with Salesforce.com&apos;s Adam Gross (who also sat on the panel) to find out if there&apos;s ever a point in time after a salesforce.com user commits an addition, change, or deletion that that transaction could be at risk in the event that salesforce.com&apos;s infrastructure experiences a failure of some sort. </p><p> According to Gross: </p><p> </p><blockquote>All data (regardless of when its committed) goes through multiple layers of data redundancy, including at the local level (within a data center), across data centers and geographies, and to offline / tape backup.</blockquote> <p> So, in answer to George Crump&apos;s original question regarding how risky is it to keep data in the cloud, the answer is that your mileage will vary depending on which cloud providers you&apos;re relying. Some, like salesforce.com, take certain measures to protect your data from the moment a user hits the enter button on a Web form. Others require more awareness of what is and what isn&apos;t at risk and what the solutions for remediation are. </p><p> <em><strong>David Berlind</strong> is an editor-at-large with <i>InformationWeek</i>. David likes to write about emerging tech, new and social media, mobile tech, and things that go wrong. He can be reached at <a href="mailto:[email protected]">[email protected]</a> and you also can find him on Twitter and other social networks (see the list below). David doesn&apos;t own any tech stocks. But, if he did, he&apos;d probably buy some Salesforce.com and Amazon, given his belief in the principles of cloud computing and his hope that the stock market can&apos;t get much worse. Also, if you&apos;re an out-of-work IT professional or someone involved in the business of compliance, he wants to hear from you.</em> </p><p> <img style="width: 16px; height: 16px;" src="https://docs.google.com/a/masseventslabs.com/File?id=dhms4dtk_70jph8rxfg_b"> Twitter: (<a title="http://twitter.com/dberlind" target="_blank" href="http://twitter.com/dberlind" id="mh0t">@dberlind</a>)<br> <img style="width: 16px; height: 16px;" src="https://docs.google.com/a/masseventslabs.com/File?id=dhms4dtk_73fmvzv6cb_b"> <a title="http://www.facebook.com/profile.php?id=660157570" target="_blank" href="http://www.facebook.com/profile.php?id=660157570" id="vr:d">My Facebook Page</a>&#xa0; (Facebook should have a namespace like Twitter, FriendFeed, and the others)<br> <img style="width: 16px; height: 16px;" src="https://docs.google.com/a/masseventslabs.com/File?id=dhms4dtk_71gx2cxmgh_b"> Flickr (<a title="http://flickr.com/photos/davidberlind/" target="_blank" href="http://flickr.com/photos/davidberlind/" id="s_yw">davidberlind</a>)<br> <img style="width: 16px; height: 16px;" src="https://docs.google.com/a/masseventslabs.com/File?id=dhms4dtk_72dfk672ch_b"> YouTube (<a title="http://www.youtube.com/techwebtv" target="_blank" href="http://www.youtube.com/techwebtv" id="rbll">TechWebTV</a>)<br> <img style="width: 16px; height: 16px;" src="https://docs.google.com/a/masseventslabs.com/File?id=dhms4dtk_74mj66nffk_b"> FriendFeed (<a title="http://friendfeed.com/davidberlind" target="_blank" href="http://friendfeed.com/davidberlind" id="oguj">davidberlind</a>)<br> <img style="width: 16px; height: 16px;" src="https://docs.google.com/a/masseventslabs.com/File?id=dhms4dtk_79cqr82cd3_b"> Del.icio.us (<a title="http://delicious.com/dberlind" target="_blank" href="http://delicious.com/dberlind" id="b:4s">dberlind</a> )<br> <img style="width: 16px; height: 16px;" src="https://docs.google.com/a/masseventslabs.com/File?id=dhms4dtk_75cxkqqxdg_b"> <a title="Me on LinkedIn" target="_blank" href="http://www.linkedin.com/pub/0/27/739" id="p4w.">Me on LinkedIn</a> (LinkedIn should have a namespace as well)<br> <img style="width: 16px; height: 16px;" src="https://docs.google.com/a/masseventslabs.com/File?id=dhms4dtk_77cbsws5fc_b"> Plaxo (<a title="http://davidberlind.myplaxo.com/" target="_blank" href="http://davidberlind.myplaxo.com/" id="t:44">davidberlind</a>)<br> <img style="width: 16px; height: 16px;" src="https://docs.google.com/a/masseventslabs.com/File?id=dhms4dtk_76hgxqxgf6_b"> Disqus (<a title="http://disqus.com/people/DavidBerlind/" target="_blank" href="http://disqus.com/people/DavidBerlind/" id="ozys">DavidBerlind</a>) </p>