Today I received an email from the Cloud Connect conference soliciting sponsorship.  It began with the eye-opening comment, "Clouds are designed to fail - they're made of transient, unreliable components."  It then goes on to say that at the conference, an analyst will lead a discussion about architecting applications to work around expected failure.

But I'd like to go back and examine the opening comment.  Are clouds really designed to fail?   If you are a cloud aficionado as I am, you have been keeping tabs on Amazon's EC2 since it was created, and you'd know that the statement is correct about EC2.   Amazon approached the cloud from a very academic perspective, in which - much like a RAID array - the components are assumed to be failure prone and the only thing that can be guaranteed is the service as a whole (even across multiple datacenters) and that it is the users' responsibility to architect their application deployment around this principle.   So it was no surprise to me when a datacenter-wide failure in EC2 brought down many of its customers.  

However, Amazon isn't the only cloud out there, and it isn't even defining what cloud is or supposed to be anymore, even if it has a dominant market share.  EC2's low reliability, low performance, and fend-for-yourself management aren't suitable to many (and I would argue most) cloud customers, and other vendors - including ENKI - have stepped in to offer alternatives.  In fact, ENKI's cloud offerings have always been designed to recover from failure automatically because we know our customers are often not interested or capable of figuring out how to work around built-in failure modes.   Just looking out at the available technologies for building public or private clouds, CA's Applogic and VMWare have offered automatic failover for a long time, and newer offerings from smaller vendors are starting to offer it as well.

Now, I'll be the first to say that all systems have failure modes and there is no cloud or hosting solution that can offer 100% uptime - despite optimistic advertisements to the contrary.  Disks fail, servers fail, SANs fail, networks fail.  It's inevitable.  However, customers of clouds which have self-healing infrastructure have a choice: accept the vendor's guaranteed per-server/service uptime level as their base infrastructure reliability, or architect a more highly redundant deployment that can build on that base level.   For many, the 99.975% to 99.99% uptime that we guarantee at the operating system level is more than adequate for their business, especially considering that the bulk of their downtime is usually due to software issues.  On the other hand, customers of clouds guarantees only at the aggregate service level and not at the operating system/VM level do not have a choice: they must factor unbounded downtime into their systems architecture planning.  And that requires skilled, experienced IT staff and developers, as well as increased complexity and cost for redundant cloud instances

All clouds will fail, but the ones designed to stay up will offer a very different customer experience from the ones that are designed to fail.

One of the huge advantages of the cloud is its ability to cut the time to market for new ideas, creating more agile enterprises.   While rapid provisioning and access to a larger set of resources than you might otherwise have contributes to this, the biggest win comes from realizing that the cloud eliminates the need to think linearly.

Over the last 10 years or so, software development methodologies have evolved from a "waterfall" analogy where design was followed by development then by test, then by deployment (to put it simply) to an agile, concurrent model where software releases became much smaller and all of the activities above happened at the same time.  So instead of:

design->develop->test->deploy

organizations realized that they can be much more customer responsive and get more done by developing software as follows, in which their team is broken up into smaller groups that work on multiple releases at once, speeding up release times by 4 (in this example):

design4->develop4->test4->deploy4

develop3->test3->deploy3->design7

test2->deploy2->design6->develop6

deploy1->design5>develop5->test5

However, the cloud allows you to apply this same discovery to your deployments, not just your development cycle.  What does this mean?   Well, for most growing internet enterprises, deployment isn't static: as their code evolves, so does their deployment architecture.   

Let's look at a little example.  We have a customer who is bringing their internet service from beta through ramp-up to large volumes.   As they do so, their deployment architecture has changed from single-instance MySQL to multi-instance MySQL to Mongo+MySQL and finally Mongo-only.   Here's how their IT staff laid out their IT architecture plans:

prototype MySQL -> test MySQL -> production MySQL -> prototype MySQLmulti
->test MySQLmulti -> production MySQLmulti -> prototype mongo -> test Mongo
-> production Mongo

If there were any problems in any of the prototyping or test phases for their deployment architecture, they'd run the risk of falling behind their code or the demands of their customer base and having a site meltdown or constraining their business.   But they don't need to think this way.

Even with a small team, they can simply develop each of the deployment architectures concurrently by creating a separate cloud instance for each one and making progress as their teams' knowledge base evolves, rather than being constrained by limited amounts and configurations of hardware for hosting the deployments.

prototype MySQL -> test MySQL -> production MySQL

                   |-->prototype MySQLmulti ->test MySQLmulti -> production MySQLmulti

                                  |-->prototype mongo -> test Mongo -> production Mongo

The organization has the option of trading off staffing for project schedule on the deployment phase, while avoiding any potential budget problems by using small cloud instances when needed to speed development of their deployments.   As a result, they no longer have to worry about being "taken by surprise" by a sudden hockey-stick in their usage that overwhelms their current-generation of deployment architecture.   And their IT operations staff no longer needs to worry about taking the blame for falling behind the market.

This applies equally well to testing new markets with mini-versions of new products, and whole host of other processes that used to be linear but can now be done in parallel, thanks the cloud.

Today, HP warned that cloud computing early adopters faced security risks.

But the timing and motivation for such a warning are suspect: the risk that HP is warning about is already present for for organizations that don't have an adequate security plan.  Where their infrastructure is - virtual, physical, cloud - is of little consequence if there is no application-dependent security plan in place.  Once the application-dependent plan is created, it must be adapted to the deployment strategy.  For example, at the simplest level, there must be a firewall in place to block unused ports, which will be a physical firewall for a physical deployment, or a virtual one coupled with vlan controls for a virtual or cloud deployment.

This is no different than the requirement that there be a business continuity plan available to ensure uptime.  During the failure at Amazon's East Coast datacenter two weeks ago, customers which had a business continuance plan in place barely noticed the outage, while those who had hoped that Amazon's services included solving their business continuance requirements were disappointed by a multiday outage.

So the risk of the cloud is really more that, with its point-and-click deployment ease, it can lull users into ignoring or avoiding their fundamental business-critical IT responsibilities, especially since avoiding these responsibilities can represent a large fraction of the cost savings they see from cloud deployment.   Because these security and in business continuance plans have to start with the application, the cloud-buying organization cannot expect an infrastructure or platform cloud vendor that they interact with purely through a self-service portal to "fix" their security and uptime exposure: they must either retain the IT expertise in-house to use the cloud properly, or find a managed cloud vendor that offers Virtual IT services as part of their management suite.

So in a sense, HP is belaboring the obvious: large enterprises already have enough IT expertise to use the cloud safely, and small enterprises are well warned not to ignore the risks of skipping business continuity and security planning.   A possible reason for HP's announcement is that HP is late to the cloud game.  While HP's competitors were fielding cloud services, HP was focusing on providing hardware and software to cloud vendors, and it still does not have a credible cloud offering, according to outsourcing experts.  And there's nothing wrong with that: HP makes fine hardware and software.  But this sounds more like a stalling tactic to me: "stay away from the cloud until we have a better solution to your security problems than our competitors!"