Of Cloud 9 and The Importance of Parachutes

Back when I did a lot of security work, we used to joke around that single sign on should be called "single vulnerability". Maybe single provider cloud models should be called "single point of failure".Toodledo went down hard last week . I rely massively on Toodledo to organize my massively complicated work and family life. But I wasn't terribly upset because my data lives in more than one place. I wrote a draft of this blog on the Toodledo site, but I could have easily written it on the equipment that houses the synchronized copy of my notes. The site being down was annoying but not, as we say in the support business, without its workaround.

Friends of mine in the social networking cloud were atwitter on the outage. One friend didn't have his data sync'd elsewhere. Others made snarky comments like, "Good thing Google is gonna support tasks soon". But, did these snarky commentators miss the Google outage in mid-May of this year? The downstream consequences were amusing or catastrophic, depending upon where you sat.

One of my Fancy Pants High Flyin' Analyst™ friends was wringing his hands over what these outages meant for cloud computing. But you don't have to be an expert on the cloud to apply fundamental IT principles to the cloud. These principles all boil down to "plan for failure." All systems fail; interdependent systems fail harder; centralized & monoculture systems fail hardest. Before you leap into Cloud 9, use tried and true IT principles to pack your parachute.

Principle 1: Diversity. No good data center manager would allow the same peer to provide backup links. Consider more than one provider. Providers have "whoops" moments no matter what the hardware redundancy looks like. If you hear the word "never" used in conjunction with failure, ask if your provider employs humans. If they don't, let me know. I've been looking to build my own army of robotic minions.

Principle 2: Backups. IT can sometimes forget that the reason that we do most things -- security, response time tuning, uptime, infrastructure deployment, ERP -- is because of the data. If there's a data loss, it means that IT has failed. Make sure you never rely on a single point of failure (provider or internal) for backups.

Principle 3: Data ownership. Again, it's about the data. You may have more than one location for your backups, but can you read them? Similarly, getting locked into a box canyon closed system means that IT is unable to handle emerging business requirements without being at the mercy of a provider. If there's no API where you can pack up your data and go if the cloud starts to dissapate, you've been sucker-punched into the same barrier to exit that Microsoft erected for desktops in the last century.

Jonathan Feldman is an InformationWeek Analytics contributor who works with IT governance in North Carolina. Comment here or write to him at [email protected]. Read about IT governance at governance.informationweek.com