<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Building a House in the Cloud &#8211; Cloudcenters vs. Infrastructure Web Services</title>
	<atom:link href="http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/</link>
	<description>&#34;Complex Infrastructure Made Easy™&#34;</description>
	<lastBuildDate>Wed, 22 May 2013 15:20:59 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: villa stone</title>
		<link>http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#comment-2076</link>
		<dc:creator>villa stone</dc:creator>
		<pubDate>Fri, 04 Sep 2009 09:54:05 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gogrid.com/?p=618#comment-2076</guid>
		<description><![CDATA[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 &#039;general contractor&#039; in Michael&#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&#039;ll use it all. For a smaller house, maybe only pick and choose what you need



Read more: http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#ixzz0Q87uopUM]]></description>
		<content:encoded><![CDATA[<p>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 &#8216;general contractor&#8217; in Michael&#8217;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. </p>
<p>For a large house, you&#8217;ll use it all. For a smaller house, maybe only pick and choose what you need</p>
<p>Read more: <a href="http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#ixzz0Q87uopUM" rel="nofollow">http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#ixzz0Q87uopUM</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rational Survivability &#187; Private Clouds: Your Definition Sucks</title>
		<link>http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#comment-1980</link>
		<dc:creator>Rational Survivability &#187; Private Clouds: Your Definition Sucks</dc:creator>
		<pubDate>Thu, 30 Jul 2009 23:24:20 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gogrid.com/?p=618#comment-1980</guid>
		<description><![CDATA[[...] are too narrow end exculpatory in definition when you consider that you are omitting solutions like GoGrid&#8217;s CloudCenter concepts &#8212; extending your datacenter via VPN onto a cloud IaaS provider whose infrastructure [...]]]></description>
		<content:encoded><![CDATA[<p>[...] are too narrow end exculpatory in definition when you consider that you are omitting solutions like GoGrid&#8217;s CloudCenter concepts &#8212; extending your datacenter via VPN onto a cloud IaaS provider whose infrastructure [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: randybias</title>
		<link>http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#comment-1536</link>
		<dc:creator>randybias</dc:creator>
		<pubDate>Thu, 16 Apr 2009 05:12:24 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gogrid.com/?p=618#comment-1536</guid>
		<description><![CDATA[Shannon, 
 
  You can also program elastic scalability using GoGrid API functionality just like Amazon&#039;s EC2.  In fact, our partner, RightScale currently supports this kind of scalability on both GoGrid and Amazon. 
 
 
--Randy ]]></description>
		<content:encoded><![CDATA[<p>Shannon, </p>
<p>  You can also program elastic scalability using GoGrid API functionality just like Amazon&#039;s EC2.  In fact, our partner, RightScale currently supports this kind of scalability on both GoGrid and Amazon. </p>
<p>&#8211;Randy </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shannon Clark</title>
		<link>http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#comment-1535</link>
		<dc:creator>Shannon Clark</dc:creator>
		<pubDate>Thu, 16 Apr 2009 04:52:29 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gogrid.com/?p=618#comment-1535</guid>
		<description><![CDATA[A question - how does GoGrid compare to Amazon&#039;s API driven ability to (if admittedly you program this) to provision additional capacity as your systems detect the need (i.e. as usage spikes over certain levels your systems could via API calls provision additional servers - and likewise turn off instances when the usage spike passes)? 
 
As I think about scaling via utilizing the cloud I see a few distinct &amp; different dimensions: 
 
Compute capacity (i.e. resolving requests &amp; service as user increase in numbers and frequency of use) 
 
Storage capacity - an issue if your specific application has storage needs on a per-user basis 
 
Bandwidth - again highly application dependent but often needs to also scale with growth (and can in some cases grow quite large &amp; pricy quickly) 
 
Shannon ]]></description>
		<content:encoded><![CDATA[<p>A question &#8211; how does GoGrid compare to Amazon&#039;s API driven ability to (if admittedly you program this) to provision additional capacity as your systems detect the need (i.e. as usage spikes over certain levels your systems could via API calls provision additional servers &#8211; and likewise turn off instances when the usage spike passes)? </p>
<p>As I think about scaling via utilizing the cloud I see a few distinct &amp; different dimensions: </p>
<p>Compute capacity (i.e. resolving requests &amp; service as user increase in numbers and frequency of use) </p>
<p>Storage capacity &#8211; an issue if your specific application has storage needs on a per-user basis </p>
<p>Bandwidth &#8211; again highly application dependent but often needs to also scale with growth (and can in some cases grow quite large &amp; pricy quickly) </p>
<p>Shannon </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Virtual, Cloud, Datacenters? &#124; neoTactics</title>
		<link>http://blog.gogrid.com/2009/01/14/building-a-house-in-the-cloud-cloudcenters-vs-infrastructure-web-services/#comment-1525</link>
		<dc:creator>Virtual, Cloud, Datacenters? &#124; neoTactics</dc:creator>
		<pubDate>Mon, 13 Apr 2009 18:56:09 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gogrid.com/?p=618#comment-1525</guid>
		<description><![CDATA[[...] An emerging trend pioneered by GoGrid and also pre-announced by RackSpace Cloud is the &#8220;cloudcenter&#8220;, a datacenter-in-the-sky.  Cloudcenters are an intermediate step between no virtualization [...]]]></description>
		<content:encoded><![CDATA[<p>[...] An emerging trend pioneered by GoGrid and also pre-announced by RackSpace Cloud is the &#8220;cloudcenter&#8220;, a datacenter-in-the-sky.  Cloudcenters are an intermediate step between no virtualization [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
