Holy Cloud Computing, Batman!

I have been spending the last couple of months working educating a client about cloud computing, building demos, and so on. If I hear another sales droid try to explain cloud computing in the terms of their products, I'll puke.

A couple of observations that most sales droids seem to not be aware of:

1. Having VMWare installed is not cloud computing
2. Oracle software (including WebLogic) is fundamentally incompatible with cloud computing

The above combination is a new term I'll post here: "Could Computing"

In other words, it's a waste of time and effort. Here I'll explain my assertions:

Cloud computing has nothing, in theory, to do with virtualization. It has to do with elastic, on-demand scaling for applications. Virtualization makes it easier. But even with virtualization any clouding effort will fail because of the achilles' heel of most organizations: configuration management.

Which leads me to explain my next assertion: Configuration management for Oracle products isn't just hard, it's damn hard. Look at the use cases at most of the Oracle shops: Servers are configured with IP addresses and not names, TNS Listeners are hard-coded with IP addresses and not names, and database configurations get incredibly complicated, very quickly. A lot of time (and money) is spent on "clustering" applications that should be running as independent parallel applications and load-balanced, but aren't because developers would rather code their customers or employers into a corner with massive, monolithic applications. This tends to derail the "clone and boot" methodology of elastic scaling (cloud computing) in most shops. Because of the effort involved in getting an Oracle database server up and running, and the effort to get something like WebLogic running, and have everything talking happily, the installations are static, rigid, and fragile.

Which explains why VMWare bought SpringSource: sell free stuff to companies who don't know any better. You're damn right I bought that stock.

What the DDoS Attack on Bitbucket.org really means for the Amazon Cloud

Well, I guess it was inevitable - a successful DDoS attack on a moderately popular service hosted in the Amazon cloud. Blog posts from Jasper detailing the attack are here.

For starters, Amazon tried to hush it over, although the different outages amounted to more than a few hours, with the excuse that disclosure would enable more effective attacks (and hence the corporate idiocy tag). The hubris of the Amazon team being significant, I never thought they'd stoop to a level like that of effectively not listening to their customer, or telling them not to explain something so plainly obvious.

There are some issues here that address some of the more fundamental aspects of cloud computing generally glossed over as scenarios like this "will never happen":

1. That users will be able to scale their EC2 (or other) virtual machines quickly enough to absorb these attacks.
2. More fundamentally, that users will be able to afford to scale their systems up. Remember that pay-as-you-go for CPU time and bandwidth? Guess what a DDoS attack attacks? There are significant financial ramifications for attacks of this type given the billing model of the Amazon cloud.
3. Transparency - the Amazon statement aside, the DDoS attack manifested itself as an issue with the storage system. This leaves one to wonder how they really run their wiring over there, and how much transparency is appropriate for a hosted service.
4. Which brings one to the Achilles' heel of Cloud systems: network I/O. Cloud systems are dependent on network I/O especially when it comes to the Amazon system, and coupled with a shared I/O infrastructure there are potential issues, including this one that can prop up. If Amazon's people aren't coming clean with that, that makes it all the much worse.
   

One of the key things to understand here is that for all the wonderful technology and ideas the cloud computing model embraces, transparency is not one of them. As one outsources one's understanding to an ever increasing degree, the questions remain:

How much can you trust a vendor?

How much due diligence should you do?

And vendors, how much should you tell your customers about how the internal plumbing of your systems really works?