I think you’ve hit the nail on the head – new applications which don’t require multiple 9′s of availability, or sub-millisecond latency, will use cloud services.

Just like less-reliable minicomputers took lots of market share from mainframes, and even-less-reliable PCs and commodity servers took lots of market share from minis and mainframes, cloud computing could take lots of market share from earlier technologies.

Also, I expect cloud computing providers and third parties to find ways to improve availability, and address the other problems. Remember what RAID did for commodity hard drives. A middleware provider could sell a way to host the same applications or storage on multiple cloud providers despite their base incompatibilities. Like JungleDisk, for example.

I’ve been pushing “dumb branch offices” instead of Cisco routers for several years now. In one case, buying “Ethernet extenders” with spares, cost less than one year’s Cisco router maintenance (aka “the Cisco tax”), with far less sys admin time. No need to wait for Google’s rumored high-end Cisco killer to save lots of money – you can keep the big Cisco routers/switches at the core of the network, and save big bucks on the branch offices.

http://news.cnet.com/8301-1001_3-10137682-92.html

I can see it happening, but given that Cisco can cut their prices signifcantly if the situation demands it, Google can probably save more money by threatening Cisco rather than actually switching.

I suspect the mostly likely outcome is that someone builds this new low-cost router, Cisco buy the company, and start to produce a version themselves at a slightly lower cost than they currently build their high-end routers.

It would be interesting to see the user reaction to a 2-3 day outage of one of the AWS data centres, it’s obviously unlikely but it’ll never be impossible. I’m sure Amazon could switch people over to another site but it might take a long time, and I think it would be a big dent in cloud computing if it happened soon. In 5-10 years the outage would still be significant, but I don’t think it would have the same reaction, simply because by then people will consider clouds the norm rather than the risky new thing.

When a cloud service provider has a relationship with a small number of larger customers, then it is economical to deploy technologies, such as VPN’s, specialized networking equipment, etc, which can mitigate or eliminate the threat of DDOS attacks.

However, when a cloud service provider has a relationship with a large number of smaller customers, then the costs of preventing DDOS attacks from having a significant impact on their operations is very high.

Let’s look at a simple example: Let’s say, for example, that a storage service provider has several hundred large enterprises as customers. Because these are larger accounts, the provider can use enterprise-grade VPN connections, and install networking equipment that discards all traffic except that which originates from legitimate customers. Thus, DDOS attacks can be stopped at the front door at a networking level.

Compare this to Amazon S3, where anyone on the Internet can be a customer. A DDOS that ties up CPU resources by performing bogus TLS authentication attempts could prevent legitimate customers from being able to perform transactions, and because there is little way to distinguish between a legitimate user and a DDOS botnet client, there is no easy way to stop the traffic before it consumes significant resources within the cloud authentication layer.

And when customer systems hosted on clouds are opened to the general public, as is the case with many EC2 hosted web applications, DDOS attacks against these customer systems are in many cases indistinguishable from the actions of regular users.

Having said this, it is important to emphasize that these issues are in no way specific to cloud-based deployments. The risks of DDOS are the same with in-house (non-cloud) infrastructure. But with usage-based charges for dynamic scaling, instead of just maxing out your in-house infrastructure, a cloud-based deployment might end up surprising you with a really large bill at the end of the month unless you put upper bounds on the elasticity of your account.