Nobody has true cloud computing just yet — where the computing just happens, regardless of hardware, such as with a Beowulf cluster.

If you want cloud capabilities on more known physical hardware then AppNexis is worth looking at.

Also Rackspace Cloud (formally Mosso) appear to indicate they offer more robustness on the physical H/W site.

You might like to also read Enterprise Class Cloud
http://cloudpundit.com/2009/06/16/enterprise-class-cloud/

I could repeat the experiment when I have some time to spare, perhaps using a distribution master with a blackhole storage engine inside EC2, and a number of slaves of different instance types replicating from that. The answers may already be out there though – I’ve stopped paying attention to the MySQL on EC2 stuff for now after seeing that it wasn’t a quick fix for *my* requirements.

BTW John, what instance size are you using? I’ve read a lot on running MySQL on EC2 and the minimum recommended instance size for reasonable performance in a production environment is Large, otherwise you’re going to run into contention issues with the CPU (you’re only getting approx. 1GHz virtual) and you have very low network bandwidth (around 250Mbps and this includes all traffic to EBS as well). With large, this should increase to approximately 1 whole CPU core and about 750-1000Mbps network bandwidth.

First, while an instance *can* disappear entirely, the EBS volume should not. It’s possible (the same as losing an entire disk array is possible), but generally speaking failure of an instance won’t kill the EBS volume. In this case, recovery from the instance failure means attaching the EBS volume to a new instance, at which point you go through normal recovery as though you’d had an unexpected power failure, kernel panic or similar. Of course, this only works if you have all of the required data on the one EBS volume!

That said, my tests with a “small” instance and a single EBS volume showed that the EC2 instance couldn’t keep up with my replication load, let alone serve any actual queries. I do roughly 1GB of binlog traffic a day – I’m guessing that’s not small, but not enormous either.

The EC2 instance was constantly behind in replication, usually by several minutes at a time. IO latency on the EBS volume *seemed* to be the cause, but I ran out of time to investigate further. Possible fixes (which I didn’t try) include using local disk (which requires bigger instances and has the risk of losing the disk if the instance goes down), or striping across multiple EBS volumes (which complicates things and would make getting a consistent snapshot much harder). Of course, the possible fixes increase the complexity and cost of the solution.

I *love* EC2 – it’s incredibly flexible and I think it’s on the right track – but you certainly need to be careful when migrating existing applications across. I’m not convinced it’s a good fit for traditional RDBMS setups. You might be able to make it fit, but you’ll have to use a shoehorn.