Commentary

Jonathan Feldman
 

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".

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.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

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 jf@feldman.org.

Read about IT governance at governance.informationweek.com


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links