Tuesday, August 27, 2013

How I Learned to Stop Worrying and Trust the Public Cloud

Some interesting and valuable insights... which I'll pick a fight with :)

"The world's most dangerous technology is Windows Update."

"While many organizations test updates to make sure they don't break anything, how many check to make sure that an update doesn't steal sensitive data off your disk? Pretty much nobody."

"The level of trust that enterprises already have in Microsoft far exceeds what Windows Azure or another cloud platform asks of them."

I agree that there is a huge amount of trust in the Microsoft update practice of most organizations, and this yields a considerable vulnerability.

Here's my beef: trusting the secure/confidential status of data in the cloud is a very different matter from trusting the service availability yielded by the cloud.  David Chappell begins by acknowledging the testing (or at least pre-production deployment) by many organizations of updates.  He even states why this is done: "to make sure they don't break anything."  Then he moves to matters of data security/confidentiality: "how many make sure that an update doesn't steal sensitive data off your disk?"

With this line of argument, he concludes that the data security/confidentiality issues of the public cloud will eventually subside, and trust of the public cloud will result.

I won't argue that public cloud data security/confidentiality concerns will experience an eternal life; actually David has formulated a remarkably convincing brief argument that they will subside.

But service availability remains something that can be validated with Windows update; there is no solid similar method for an individual cloud subscriber to validate cloud code or hardware upgrades prior to deployment.  And while data security/confidentiality has not been breached in the public cloud by the public cloud (at least, such breaches are not publicly known), service availability should be a significant consideration before trust is granted to a public cloud platform.  Consider the few links below regarding Amazon EC2 service.

Finally, there are data concerns beyond security/confidentiality.  For medical and financial data, as well as data that outlines intellectual property such as design and code itself. there are huge concerns around data ownership: when the cloud service shuts down, what becomes of the data?

So, while I congratulate David Chappell for briefly articulating a compelling argument for the eventual irrelevance of data security/confidentiality concerns as a barrier to transition to public cloud platforms, the argument here is not sufficient for me to agree with the conclusion: "We're not there yet, but the day when trusting a public cloud platform is as unremarkable as trusting Windows Update is coming."

I don't think so:
1. the service availability vulnerability to individual organizations accompanying cloud code and hardware changes must be mitigated somehow.
2. data ownership issues other than security/confidentiality must be confidently resolved.

Already I wish I could communicate as briefly as Mr. Chappell does :)

At any rate, sql.sasquatch has not yet learned to stop worrying and trust the public cloud.    


22 October 2012
"The [Amazon EC2] outage was the fifth significant downtime in the last 18 months for the US-East-1 region, which is Amazon’s oldest availability zone. The US-East-1 region had outages in April 2011, March 2012, and June 15 and June 30 of 2012. Amazon’s U.S East region also was hit by a series of four outages in a single week in 2010."
Amazon Cloud Outage KOs Reddit, Foursquare & Others

30 June 2012

15 June 2012
15 March 2012

21 April 2011

 May 2010
Amazon Addresses EC2 Power Outages

No comments:

Post a Comment