Monday, August 1, 2011
Transparency: The Essential Ingredient to a Good Cloud Services Partnership
Not long ago, Amazon reported issues with its Elastic Compute Cloud (EC2) cloud service. Several of its data centers experienced what the company described as “connectivity errors.” And with that, everyone who depended on Amazon EC2 in the eastern half of the U.S. was knocked offline for the next four days, according the news reports, as Amazon struggled to understand and fix the problem.
This included several high-profile websites, including Quora, Reddit, Foursquare, and Hootsuite. They, along with an unknown number of nameless enterprises, were essentially out of business for four days.
Certainly this was an eye-opening, even chilling incident for Amazon, its customers, and any IT leader interested in extending her infrastructure to the cloud. It exposed three crucial issues that are not unique to Amazon, but rather, are attributes of most cloud services relationships.
1. The cost of downtime. It’s the #1 risk factor for customers of most cloud services providers. When your cloud services provider goes down, there’s not much you can do other than scream at them to get it back up. Amazon EC2 customers had no choice but to endure this huge business disruption while the clock kept ticking.
2. Your cloud architecture. That’s right, I said your cloud architecture, not Amazon’s (or any cloud services provider’s). Amazon’s EC2 failure exposed the critical role your architecture plays in successful use of cloud resources. For example, Quora and Reddit built their cloud infrastructure with a single point of failure. Others designed their infrastructure to fail-over to backup cloud resources if a problem was encountered with Amazon EC2. Those businesses rolled on despite Amazon’s problems.
3. Transparency. This incident illustrated how poorly prepared Amazon was for a major system outage. The company did not provide its customers with full, immediate, and ongoing communications into the status of the problem and its resolution. As I note below, this is but one of several key aspects of transparency in your relationship with a cloud services provider.
After the fact, Amazon offered its customers a small refund, an apology, and an explanation. Amazon executives also acknowledged that they had done a poor job of communicating with their customers during the crisis. Excerpts:
We understand that during an outage, customers want to know as many details as possible about what’s going on, how long it will take to fix, and what we are doing so that it doesn’t happen again ... we think we can improve in this area.
If you’re going to base some or all of IT infrastructure around cloud services, then transparency is essential. In a crisis, if you’re unable to get the information you need to make informed decisions about how to respond to the IT needs of your business, your partnership is one-sided. If information is being generically and ambiguously delivered by your provider’s PR department or if the information is provided well after the problem is resolved, you don’t have a true partnership with your vendor.
At SHI, we believe providing a high level of transparency in all aspects of cloud services is essential for businesses to fully capitalize on the benefits of cloud computing. While providing fast, honest, ongoing communications in a crisis is a part of that, it’s not the only part. Our goal, and our vision, is that cloud services should be an extension of our customer’s IT environment. That goal carries a great deal of responsibility and demands that we, your provider, must focus on delivering the same expert counsel and access to data that you expect from your own internal IT staff.
This philosophy of transparency also informs all the design decisions we make in building and evolving the SHI cloud. But most important, it informs the design decisions we counsel our customers to make (clearly Amazon did not counsel Quora or Reddit about redundancy -- and Amazon is not alone.)
In the end, if a cloud services provider is to become, in essence, a logical part of the customer's IT organization, then we must provide transparency in our security, in the design of our cloud (and it’s interdependencies with the customer’s IT architectures), and in our relationship with the client.
In my next post, I’ll drill into how this notion of transparency has influenced the design of the SHI Cloud, and how that serves as a true logical extension of our customers' IT architecture.