<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
	<channel>
		<title>gdp's Comments</title>
		<language>en-us</language>
		<link>https://www.intensedebate.com/users/299829</link>
		<description>Comments by randybias</description>
<item>
<title>Union Station : The State of XML Parsing in Ruby (Circa 2009)</title>
<link>http://www.engineyard.com/blog/2009/xml-parsing-in-ruby/#IDComment44129582</link>
<description>Oh dear.  With this article you would think it&amp;#039;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 &amp;#039;xsi:type&amp;#039; aren&amp;#039;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. </description>
<pubDate>Sat, 21 Nov 2009 06:33:18 +0000</pubDate>
<guid>http://www.engineyard.com/blog/2009/xml-parsing-in-ruby/#IDComment44129582</guid>
</item><item>
<title>Union Station : Understanding Cloud Benchmarks</title>
<link>http://www.engineyard.com/blog/2009/understanding-cloud-benchmarks/#IDComment23024786</link>
<description>More important than EBS being slower than disks is that it&amp;#039;s got an absolute maximum sequential read/write speed.  Since it&amp;#039;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&amp;#039;s 100MBps shared by the number of TOTAL (all customers) EBS volumes on a physical EC2 node - I&amp;#039;m currently assuming it&amp;#039;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:  &lt;a href=&quot;http://blogs.msdn.com/tvoellm/archive/2009/05/07/useful-io-profiles-for-simulating-various-workloads.aspx&quot; target=&quot;_blank&quot;&gt;http://blogs.msdn.com/tvoellm/archive/2009/05/07/...&lt;/a&gt;  </description>
<pubDate>Tue, 2 Jun 2009 01:28:54 +0000</pubDate>
<guid>http://www.engineyard.com/blog/2009/understanding-cloud-benchmarks/#IDComment23024786</guid>
</item><item>
<title>GoGrid Blog : Planning for the New GoGrid Feature – MyGSIs</title>
<link>http://blog.gogrid.com/2009/04/22/planning-for-the-new-gogrid-feature-%e2%80%93-personal-server-images/#IDComment21683523</link>
<description>This is a future release.  It&amp;#039;s due in late June or early July. </description>
<pubDate>Sun, 17 May 2009 04:05:28 +0000</pubDate>
<guid>http://blog.gogrid.com/2009/04/22/planning-for-the-new-gogrid-feature-%e2%80%93-personal-server-images/#IDComment21683523</guid>
</item><item>
<title>GoGrid Blog : Cloudcenters are Datacenters in the Sky</title>
<link>http://blog.gogrid.com/2009/01/08/cloudcenters-are-datacenters-in-the-sky/#IDComment21001914</link>
<description>Wesley,    Thank you for your questions.  It&amp;#039;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&amp;#039;t be adopted.  More important are services like S3, Amazon&amp;#039;s Simple Storage Service.  A 100% proprietary file storage system.  You won&amp;#039;t be able to have an equivalent in your own datacenter.    With regards to EC2, the Xen hypervisor is standard, but that&amp;#039;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&amp;#039;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&amp;#039;t sue given their history with &amp;#039;1-click shopping&amp;#039;?    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&amp;#039;s &amp;#039;no&amp;#039;, &amp;#039;yes, but it will be  painful&amp;#039;, 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&amp;#039;s ZFS, and similar for real-world examples of standards or software that can be safely embraced inside and outside the cloud.   --Randy </description>
<pubDate>Thu, 7 May 2009 22:30:06 +0000</pubDate>
<guid>http://blog.gogrid.com/2009/01/08/cloudcenters-are-datacenters-in-the-sky/#IDComment21001914</guid>
</item><item>
<title>GoGrid Blog : Building a House in the Cloud - Cloudcenters vs. Infrastructure Web Services</title>
<link>http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#IDComment18832670</link>
<description>Shannon,    You can also program elastic scalability using GoGrid API functionality just like Amazon&amp;#039;s EC2.  In fact, our partner, RightScale currently supports this kind of scalability on both GoGrid and Amazon.   --Randy </description>
<pubDate>Thu, 16 Apr 2009 05:12:24 +0000</pubDate>
<guid>http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#IDComment18832670</guid>
</item><item>
<title>GoGrid Blog : GoGrid Performance Improvement for Linux Customers - Action Required</title>
<link>http://blog.gogrid.com/2009/02/13/gogrid-performance-improvement-for-linux-customers-action-required/#IDComment17900189</link>
<description>Matthew,    You&amp;#039;re right that we could have handled this better.  Myself, Michael Sheehan, and our new Service Team Manager, Tom Blossom are planning how we&amp;#039;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 </description>
<pubDate>Tue, 31 Mar 2009 06:22:57 +0000</pubDate>
<guid>http://blog.gogrid.com/2009/02/13/gogrid-performance-improvement-for-linux-customers-action-required/#IDComment17900189</guid>
</item><item>
<title>GoGrid Blog : Measuring the Performance of Clouds - GoGrid</title>
<link>http://blog.gogrid.com/2009/03/17/measuring-the-performance-of-clouds-gogrid/#IDComment17583389</link>
<description>Raditha,    Thanks for following up.  We appreciate your support of the GoGrid service.  It&amp;#039;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&amp;#039;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 </description>
<pubDate>Wed, 25 Mar 2009 17:52:31 +0000</pubDate>
<guid>http://blog.gogrid.com/2009/03/17/measuring-the-performance-of-clouds-gogrid/#IDComment17583389</guid>
</item><item>
<title>GoGrid Blog : New Larger RAM Instances Now Available on GoGrid</title>
<link>http://blog.gogrid.com/2009/02/17/new-larger-ram-instances-now-available-on-gogrid/#IDComment15427146</link>
<description>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. </description>
<pubDate>Wed, 18 Feb 2009 20:05:51 +0000</pubDate>
<guid>http://blog.gogrid.com/2009/02/17/new-larger-ram-instances-now-available-on-gogrid/#IDComment15427146</guid>
</item><item>
<title>GoGrid Blog : Building a House in the Cloud - Cloudcenters vs. Infrastructure Web Services</title>
<link>http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#IDComment15069485</link>
<description>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 (&lt;a href=&quot;http://blog.gogrid.com/2009/01/08/cloudcenters-are-datacenters-in-the-sky/)&quot; target=&quot;_blank&quot;&gt;http://blog.gogrid.com/2009/01/08/cloudcenters-ar...&lt;/a&gt; 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&amp;#039;ll have a full press release on Tuesday.  The new larger virtual machine sizes have 2+ cores.  </description>
<pubDate>Thu, 12 Feb 2009 23:42:50 +0000</pubDate>
<guid>http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#IDComment15069485</guid>
</item><item>
<title>GoGrid Blog : Cloudcenters are Datacenters in the Sky</title>
<link>http://blog.gogrid.com/2009/01/08/cloudcenters-are-datacenters-in-the-sky/#IDComment14810768</link>
<description>Yes, effectively the entire cloudcenter is virtualized including loadbalancers, firewalls, and NAS.  You will never see another customer&amp;#039;s infrastructure nor will they see yours. </description>
<pubDate>Fri, 6 Feb 2009 20:48:00 +0000</pubDate>
<guid>http://blog.gogrid.com/2009/01/08/cloudcenters-are-datacenters-in-the-sky/#IDComment14810768</guid>
</item><item>
<title>GoGrid Blog : Cloudcenters are Datacenters in the Sky</title>
<link>http://blog.gogrid.com/2009/01/08/cloudcenters-are-datacenters-in-the-sky/#IDComment14753797</link>
<description>Rob, the key issue for BSS functions is multi-tenancy.  Just like the telcos, perhaps more so, clouds will eventually need fairly sophisticated and robust mechanisms for metering and billing.  We already have partners who desire to resell the platform while maintaining control of the customer relationship.  For them it&amp;#039;s important to have very good tools for managing metering/billing.  I don&amp;#039;t know if there is an inherent difference of approach in terms of what cloudcenters need to do differently from infrastructure web services.  My guess is that there is not a significant difference there.  Both need to find ways to allow not only clear transparent metering, but very granular (down to a &amp;#039;user&amp;#039; or &amp;#039;department&amp;#039;) billing capabilities.  Thanks for your great question.   --Randy </description>
<pubDate>Wed, 4 Feb 2009 17:32:14 +0000</pubDate>
<guid>http://blog.gogrid.com/2009/01/08/cloudcenters-are-datacenters-in-the-sky/#IDComment14753797</guid>
</item><item>
<title>GoGrid Blog : Building a House in the Cloud - Cloudcenters vs. Infrastructure Web Services</title>
<link>http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#IDComment14003773</link>
<description>Most cloudcenters are going to pre-bundle an entire datacenter for your usage, but follow a utility charge model just like that of AWS.  Much like a &amp;#039;general contractor&amp;#039; in Michael&amp;#039;s example you still only use the materials and subcontractors that you decide when building your house.  It just happens that they are already pre-bundled and designed to work together, so there is much less work on your part.  For a large house, you&amp;#039;ll use it all.  For a smaller house, maybe only pick and choose what you need. </description>
<pubDate>Thu, 15 Jan 2009 17:20:48 +0000</pubDate>
<guid>http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#IDComment14003773</guid>
</item>	</channel>
</rss>