Signed,

-Richard M Stallman

To the authors – it isn't quite as hard as you think to move between clouds and other virtualization formats. But my reasons for believing that are because I am one of the team behind the Elastic Server platform (http://www.elasticserver.com) which allows you to have a “bill of materials” for a server (OS + Middleware + Applications) and then quickly assemble it into Amazon AMI format, VMware, Parallels, etc.. So cloud portability at the format level is less of an issue maybe than the authors think. Cloud portability at the API level or the storage services level is another thing and one we would be happy to discuss.

However, doing it by hand is not quite as easy as described above. I don't disagree with any of the description above of what an Amazon AMI really is, but, for a virtual server to be a proper “citizen” of most clouds there are nuances of format with respect to the meta data of the virtual machine – even when both clouds use open source Xen. Additionally most clouds and virtualization hypervisors require specific libraries to be in the operating system of the running virtual server. So to use “Cloud Foo” that uses Virtual Iron your build will need “virtual iron” tools inside of it, as well as “Cloud Foo Tools” so it behaves properly in their data center's overall environment.

Again – I clearly have a vested interest in the automated approach – but that is why we built the Elastic Server platform to handle lots of these details behind the scenes.

In the DB tests you ran, can you tell us what EC2 instance you used, and what hardware?

The differences you stated are *clearly* one of a handful of issues:

1) On disk -vs- in memory data access
2) indexed -vs- non-indexed lookups

It's a bit of a disappointment to see benchmarks without *any* idea of configuration details. Without them, the benchmarks are *meaningless*.

As far your argument about performance is concerned, you haven't provided the specs of traditional server and the servers used in the cloud. In the absence of specs, the comparison could be like that of comparing apples to oranges.

This article appears like an article with agenda. I am sorry for being blunt. This is not an objective analysis.

Interesting that this was mentioned — “If the cost of just one outage would exceed the benefits of speed and flexibility, you’re better off managing your own infrastructure.” — but really, is this even possible? I'd be interested to find about related case studies.

Macel Legaspi
Morph Labs

Michael Kassing
MarkTend.com