Oh dear. With this article you would think it's all peachy keen in Ruby and XML land, although nothing could be further from the truth. XML support in Ruby is much worse than in other languages. For example, the only library that handles XML namespaces correctly is nokogiri. The rest are broken. As another example, lots of edge cases like handling 'xsi:type' aren't handled by any of the libraries.

Simple XML is easily handled, but the various dialects and extensions are barely handled well in most Ruby XML libraries.

More important than EBS being slower than disks is that it's got an absolute maximum sequential read/write speed. Since it's a network-based solution (presumably iSCSI or similar) there is a maximum throughput of 125MBps, well short of a real RAID solution. Add to this the following considerations:

- This is a theoretical maximum (~100MBps is more likely)
- There is almost certainly a level of network oversubscription so it's 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node
- I'm currently assuming it's a separate storage network; if not, the oversubscription is much worse

So, bottom line is that random read/writes should be pretty good, but any kind of sequential read/write work loads will be problematic. Many OLTP databases have a roughly 30% seq write workload.

See following for some examples of work load I/O profiles:

http://blogs.msdn.com/tvoellm/archive/2009/05/07/...

This is a future release. It's due in late June or early July.

Wesley,

Thank you for your questions. It's true that the Amazon APIs all have a SOAP interface. This is really not my point in talking about industry standards. To some degree any API demands that you use *something* that the industry uses or it won't be adopted. More important are services like S3, Amazon's Simple Storage Service. A 100% proprietary file storage system. You won't be able to have an equivalent in your own datacenter.

With regards to EC2, the Xen hypervisor is standard, but that's about it. Storage for EC2 images is in S3, a proprietary standard. The image management and description system is also proprietary. Or, at the very least, you (again) can't have it inside your datacenter. Well, perhaps you can leverage EUCALYPTUS, but their legal status on the structure of their API interfaces is almost certainly in question. More so now that they are a commercial entity. Do you want to bet the farm that Amazon won't sue given their history with '1-click shopping'?

There are two ways to look at whether a given service is proprietary or not:

1) Can you get it today in your own datacenter, infrastructure, or cloud?
2) If you write tools and software that manages the service through an API can you reuse those easily with other similar systems?

My guess is that with most of Amazon it's 'no', 'yes, but it will be painful', or similar. Amazon could choose to provide a de facto standard, but until they take a stance with regards to the legality of copying their programming interfaces and services then sticking with well known standards seems like the best bet.

Look more towards the efforts of the OGF around the OCCI standard, Sun's ZFS, and similar for real-world examples of standards or software that can be safely embraced inside and outside the cloud.

--Randy

Shannon,

You can also program elastic scalability using GoGrid API functionality just like Amazon's EC2. In fact, our partner, RightScale currently supports this kind of scalability on both GoGrid and Amazon.

--Randy

Matthew,

You're right that we could have handled this better. Myself, Michael Sheehan, and our new Service Team Manager, Tom Blossom are planning how we'll make these kinds of releases better in terms of communicating the bugfix scopes and impact more clearly.

We really appreciate your patience. In hindsight we realize it was more critical than we previously thought. There were some cases where when we measured the performance where we see very pathological behavior that did not arise in our initial tests.

Best,

--Randy

Raditha,

Thanks for following up. We appreciate your support of the GoGrid service. It's important to us as a business to identify and respond to blog postings like yours. In this case we felt the methodology you used may not fairly represent GoGrid's performance and we wanted to present our case.

Open debates like this are what the Internet is about. :) We still have some concerns with the methodology that you used, but recognize that you put some effort into trying to make it fair.

Would be happy to work with you on an update to your posting that perhaps uses a few different measures of performance (bonnie++, iozone, dd, and perhaps vmmark?) to compare disk subsystems.

Best,

--Randy

There will be some solutions for allowing cloud-like scalability with dedicated servers in the future. That should take care of most downsides to this. On-demand, pay-as-you-go, etc.

With regards to managed services we have a number of partners who provide this expertise and are well versed in building robust cloud architectures. Recommend you check with your sales folks for recommendations.

Doug, thanks for your question. Cloudcenters are a type of IaaS. We discovered the distinction while trying to understand why our service looked so different from other IaaS platforms, specifically AWS. I strongly recommend reading my early posting (http://blog.gogrid.com/2009/01/08/cloudcenters-ar... which goes into some detail on cloudcenters.

I am not aware of any significant blockers to your requirements using GoGrid as it is very much a standard cloud infrastructure. Perhaps the primary issue is that VDI is another virtualization technology. Generally speaking you cannot deploy virtualization inside another virtualized system; however, it would be possible to use our CloudConnect offering to deploy VDI on dedicated servers (ServePath) or colocated servers (ColoServe) that were attached to your GoGrid cloud offering.

FYI, larger virtual machine sizes were quietly deployed today and are available now on GoGrid. We'll have a full press release on Tuesday. The new larger virtual machine sizes have 2+ cores.

Yes, effectively the entire cloudcenter is virtualized including loadbalancers, firewalls, and NAS. You will never see another customer's infrastructure nor will they see yours.