12 comments posted · 0 followers · following 0
Simple XML is easily handled, but the various dialects and extensions are barely handled well in most Ruby XML libraries.
- 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:
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.
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.
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.
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.
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.
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.