<?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"
	>
<channel>
	<title>Comments on: Cloud computing hype overload</title>
	<atom:link href="http://www.protocolostomy.com/2008/07/07/cloud-computing-hype-overload/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.protocolostomy.com/2008/07/07/cloud-computing-hype-overload/</link>
	<description>Made with only the finest 1's and 0's</description>
	<pubDate>Thu, 04 Dec 2008 17:56:00 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.5</generator>
		<item>
		<title>By: friarminor</title>
		<link>http://www.protocolostomy.com/2008/07/07/cloud-computing-hype-overload/#comment-1756</link>
		<dc:creator>friarminor</dc:creator>
		<pubDate>Tue, 08 Jul 2008 21:45:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.protocolostomy.com/?p=328#comment-1756</guid>
		<description>Given the fact that thee had been cloud over-zealousness, it does make sense that many of its shortcoming are being exposed as early as possible and we're not even touching on 'security'.  Or even the impact of power consumption a shift to major clouds would bring.  To say that the cloud world has everything taken cared of to a 'T' would definitely be the hype.

Still, better to keep an open ear to all things 'innovation'

Best.
alain
mor.ph</description>
		<content:encoded><![CDATA[<p>Given the fact that thee had been cloud over-zealousness, it does make sense that many of its shortcoming are being exposed as early as possible and we&#8217;re not even touching on &#8217;security&#8217;.  Or even the impact of power consumption a shift to major clouds would bring.  To say that the cloud world has everything taken cared of to a &#8216;T&#8217; would definitely be the hype.</p>
<p>Still, better to keep an open ear to all things &#8216;innovation&#8217;</p>
<p>Best.<br />
alain<br />
mor.ph</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sean O'Donnell</title>
		<link>http://www.protocolostomy.com/2008/07/07/cloud-computing-hype-overload/#comment-1752</link>
		<dc:creator>Sean O'Donnell</dc:creator>
		<pubDate>Tue, 08 Jul 2008 08:37:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.protocolostomy.com/?p=328#comment-1752</guid>
		<description>Irrational Exuberance... you mean like "Web 2.0"?? =p</description>
		<content:encoded><![CDATA[<p>Irrational Exuberance&#8230; you mean like &#8220;Web 2.0&#8243;?? =p</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Oliver</title>
		<link>http://www.protocolostomy.com/2008/07/07/cloud-computing-hype-overload/#comment-1749</link>
		<dc:creator>Oliver</dc:creator>
		<pubDate>Tue, 08 Jul 2008 04:38:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.protocolostomy.com/?p=328#comment-1749</guid>
		<description>First, I really like your post. I had equal thoughts before, cloud computing won't be the solution for everything.

It surely has its market, and it surely makes sense in some situations, but why would all websites need to scale infinitely? How many websites ever needed to scale fast (and failed)?

As your application/website grows the codebase needs to change, which is no problem. But if you're using a cloud, do you need to change your codebase? I guess you'll run into cloud limitations earlier or later, and these will probably be harder to circumvent then the known scaling problems...</description>
		<content:encoded><![CDATA[<p>First, I really like your post. I had equal thoughts before, cloud computing won&#8217;t be the solution for everything.</p>
<p>It surely has its market, and it surely makes sense in some situations, but why would all websites need to scale infinitely? How many websites ever needed to scale fast (and failed)?</p>
<p>As your application/website grows the codebase needs to change, which is no problem. But if you&#8217;re using a cloud, do you need to change your codebase? I guess you&#8217;ll run into cloud limitations earlier or later, and these will probably be harder to circumvent then the known scaling problems&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John</title>
		<link>http://www.protocolostomy.com/2008/07/07/cloud-computing-hype-overload/#comment-1748</link>
		<dc:creator>John</dc:creator>
		<pubDate>Tue, 08 Jul 2008 02:45:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.protocolostomy.com/?p=328#comment-1748</guid>
		<description>I agree with all the arguments you make and for many applications or websites the current offerings of the cloud leave much to be desired.  That being said I think the real problem right now with the idea of cloud computing is that it is in its infancy and what is available to developers outsides the likes of Google, Amazon, Ebay, Yahoo, etc are orders of magnitude worse than that of those inside these companies.

Having worked at one of these companies, one does have to change a lot of thinking about how to design software to utilize technologies more like Google's BigTable or Yahoo's Hadoop but there is a reason that all these previously listed companies design and utilize these massively parallel systems.  They work or at least work better than anything else out there.  

The project I worked on started with one MySQL database, ended with over 100 all while upgrading hardware constantly.  The pain and limitations that this brought were much worse than the idea of of losing a letter or two in ACID.  Now before people scream that you can't do things without ACID, sometimes you don't need all of it.  Its not necessarily important that an update be instantly viewable by all other readers.  You want to guarantee it will get there eventually (usually within 10s of milliseconds), but it doesn't necessarily have to be atomic.  Now obviously this does not make sense for writing ATM software or some other textbook example.  

Either way I won't continue to ramble and still agree that a badly designed application using one of these grid frameworks would be infinitely worse than a decently designed traditional 3 tier setup, but my guess is that the companies I listed above didn't start with the buzz of grid but ended up there (somewhat simultaneously) due to necessity.  I look forward to improvements both in MySQL and other traditional technologies as well as the development of infant technologies like Hadoop, HBase, and others.  Nothing like competition to keep things moving forward.</description>
		<content:encoded><![CDATA[<p>I agree with all the arguments you make and for many applications or websites the current offerings of the cloud leave much to be desired.  That being said I think the real problem right now with the idea of cloud computing is that it is in its infancy and what is available to developers outsides the likes of Google, Amazon, Ebay, Yahoo, etc are orders of magnitude worse than that of those inside these companies.</p>
<p>Having worked at one of these companies, one does have to change a lot of thinking about how to design software to utilize technologies more like Google&#8217;s BigTable or Yahoo&#8217;s Hadoop but there is a reason that all these previously listed companies design and utilize these massively parallel systems.  They work or at least work better than anything else out there.  </p>
<p>The project I worked on started with one MySQL database, ended with over 100 all while upgrading hardware constantly.  The pain and limitations that this brought were much worse than the idea of of losing a letter or two in ACID.  Now before people scream that you can&#8217;t do things without ACID, sometimes you don&#8217;t need all of it.  Its not necessarily important that an update be instantly viewable by all other readers.  You want to guarantee it will get there eventually (usually within 10s of milliseconds), but it doesn&#8217;t necessarily have to be atomic.  Now obviously this does not make sense for writing ATM software or some other textbook example.  </p>
<p>Either way I won&#8217;t continue to ramble and still agree that a badly designed application using one of these grid frameworks would be infinitely worse than a decently designed traditional 3 tier setup, but my guess is that the companies I listed above didn&#8217;t start with the buzz of grid but ended up there (somewhat simultaneously) due to necessity.  I look forward to improvements both in MySQL and other traditional technologies as well as the development of infant technologies like Hadoop, HBase, and others.  Nothing like competition to keep things moving forward.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bill Karwin</title>
		<link>http://www.protocolostomy.com/2008/07/07/cloud-computing-hype-overload/#comment-1747</link>
		<dc:creator>Bill Karwin</dc:creator>
		<pubDate>Tue, 08 Jul 2008 02:21:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.protocolostomy.com/?p=328#comment-1747</guid>
		<description>Total agreement.  There have been distributed computing buzzwords flying around for as long as I can remember.  Middleware, CORBA, DCOM, EJB, Grid computing, Peer-to-Peer, etc.

All of these technologies have important uses, but none of them took over the world as their marketing rhetoric suggested they would.

These technologies incur additional cost to manage the architecture.  Naturally, any application that can do the same job without using a distributed architecture is cheaper and therefore more competitive.  

See also:
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing 

Unless you have a system that truly needs to be distributed, it's simpler, more reliable, and more efficient to use a conventional architecture.  Not everyone works on the Google File System.</description>
		<content:encoded><![CDATA[<p>Total agreement.  There have been distributed computing buzzwords flying around for as long as I can remember.  Middleware, CORBA, DCOM, EJB, Grid computing, Peer-to-Peer, etc.</p>
<p>All of these technologies have important uses, but none of them took over the world as their marketing rhetoric suggested they would.</p>
<p>These technologies incur additional cost to manage the architecture.  Naturally, any application that can do the same job without using a distributed architecture is cheaper and therefore more competitive.  </p>
<p>See also:<br />
<a href="http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing" rel="nofollow">http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing</a> </p>
<p>Unless you have a system that truly needs to be distributed, it&#8217;s simpler, more reliable, and more efficient to use a conventional architecture.  Not everyone works on the Google File System.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
