7 Self-Inflicted Wounds Of Cloud Computing

Don't let poor planning and half-hearted decisions doom your promising cloud projects.
Wound 5: Believing The Vendor

Skipper said, "When a data center automation vendor tells you they can take their existing product and simply add a plug-in or new related product that makes everything cloud-ready... You should think of unicorns..." Next slide shows a pug dog in a pink unicorn outfit, not the happiest of marriages.

This is that moment in every presentation when you realize it's being given by a vendor with a self interest, and along with much valuable information comes a swipe at the competition. When I think of cloud vendors, I think of or Rackspace or Terremark. At ServiceMesh, they think of those competing vendors in the data center automation space. No, you can't necessarily believe someone who says there's an instant answer to becoming ready for the cloud. Okay, now let's move on.

Self-inflicted wound number five continued with two more slides. Cloud vendors come with cloud management tools. Skipper asked: Can the tool provide end-user self-provisioning? Can it calculate chargeback on a pay-by-the-hour basis? Can it automate storage provision? Does it work with multiple hypervisors?

Good points, Anthony. Let me note here that most cloud service suppliers, from Amazon Web Services on down, have limited interest in working with multiple hypervisors. Amazon likes Amazon Machine Images that run under the Xen hypervisor. AT&T and Verizon Business like VMware virtual machines. Microsoft likes its own and Citrix Systems' virtual machines. But most customers already have multiple hypervisors in operation and only a few clouds are willing to run all of them.

Skipper continued in another slide: "All cloud projects will require some level of integration." "Skepticism is healthy for everyone" on the integration front, he said. Not all cloud APIs are created equal, another good point. And cloud providers who also provide their own management software "represent a dangerous dose of lock-in," a dart probably directed at VMware.

Wound 6: Getting Addicted To Cloud

Many early implementers have realized immediate savings in moving a workload into the cloud and reacted with enthusiasm. If a little is good, then a lot must be a lot better. Skipper warned, "There are solutions that are initially cost effective in the cloud, but which later grow to scale where they become incredibly expensive."

I would say one place to look for this is in the charges for data movement into the cloud, or in Amazon's case, between availability zones within the same data center. There's a charge based on the amount of data. In other cases it's based on numbers that are hard to predict, such as the number of http requests, storage consumed, or number of I/Os used. The cloud vendors mix up their charging mechanisms, making it hard to compare one to another as well as predict what the charges might actually be. In most cases it's cheaper to move your data into the cloud than it is to get it back out again, a built-in discouragement to considering another vendor.

Skipper wisely warned against too much enthusiasm and not being able to calculate what your costs will be if your workloads needs to go big and start consuming more resources. "Have the ability to bring things back internally or to another provider at any point," he advised. Again, point well taken.

A company that has clearly learned to do this is the online game supplier, Zynga, which launches its new creations in the Amazon cloud but brings the game logic and services back in-house, once it sees what the demand will be. It tries to manage the Amazon cloud and its own Z Cloud as one environment and move workloads fluidly between them. For more on this, see CTO Allan Leinwand's comments in Lessons From Farmville.

Wound 7: Failing To Implement Policy From The Beginning

Another way to cause your move to cloud computing to fail is to make no decision on how you will manage cloud workloads, Skipper said in his concluding point. "You'll miss the window to drive major process improvements. It's not possible to fully automate everything if you don't have configuration generated by policy. Even though it's technically possible to move anything anywhere, that doesn't mean it is legally possible. Cloud means a business unit can open a Salesforce or EC2 account with a credit card and be using it in minutes."

So if you've achieved simplification by moving to a standard x86 architecture and scrupulously followed standards in networking and storage, you can still blow it by adopting cloud use willy nilly without an ability to impose your governing policies. It does no good to allow end-user self-provisioning if you don't have the policies in place that determine the appropriate amount of networking and storage for the type of server spun up. You'll be resorting to constant manual interventions if you don't have security policies that match the use of the virtual server.

And I would add those security policies must follow it around if a virtual machine is moved from one location to another in the cloud. Good policies are one of the few ways to free up those carbon units we were talking about earlier and let them work on further improvements--your ultimate pay-off.

All in all, a fine summary on how half-measures, traditional thinking, and refusal to change can kill the most promising cloud project.

Charles Babcock is an editor-at-large for InformationWeek.

Security monitoring, incident response, and forensics are essential, even in the cloud. But the cloud by definition implies relinquishing at least some control, which can make these practices problematic. In this report, we identify the challenges of detecting and responding to security issues in the cloud and discuss the most effective ways to address them. Download our report now. (Free registration required.)

Editor's Choice
Carrie Pallardy, Contributing Reporter
Cynthia Harvey, Freelance Journalist, InformationWeek
James M. Connolly, Contributing Editor and Writer
Mary E. Shacklett, President of Transworld Data