<?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: Risks in the Cloud</title>
	<atom:link href="http://theappslab.com/2009/08/18/risks-in-the-cloud/feed/" rel="self" type="application/rss+xml" />
	<link>http://theappslab.com/2009/08/18/risks-in-the-cloud/</link>
	<description>Driving Innovation</description>
	<lastBuildDate>Thu, 24 May 2012 14:11:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Enterprise Clouds &#124; Oracle</title>
		<link>http://theappslab.com/2009/08/18/risks-in-the-cloud/comment-page-1/#comment-9019</link>
		<dc:creator>Enterprise Clouds &#124; Oracle</dc:creator>
		<pubDate>Tue, 25 Aug 2009 00:31:03 +0000</pubDate>
		<guid isPermaLink="false">http://theappslab.com/?p=3290#comment-9019</guid>
		<description>[...] of a cloudy week with the discussion of risks earlier and now a related post on enterprise [...]</description>
		<content:encoded><![CDATA[<p>[...] of a cloudy week with the discussion of risks earlier and now a related post on enterprise [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jake</title>
		<link>http://theappslab.com/2009/08/18/risks-in-the-cloud/comment-page-1/#comment-8971</link>
		<dc:creator>Jake</dc:creator>
		<pubDate>Thu, 20 Aug 2009 21:51:26 +0000</pubDate>
		<guid isPermaLink="false">http://theappslab.com/?p=3290#comment-8971</guid>
		<description>Yeah, but even a reputable colo could fall under this blanket assertion. If someone&#039;s doing bad things in your reputable colo, this guilt-by-association taints you too, i.e. you were facilitating the nefarious behavior. And it also taints your innocent customers.&lt;br&gt;&lt;br&gt;Although I&#039;m sure the same assumption could be applied to VMs too.&lt;br&gt;&lt;br&gt;Plus, it&#039;s very specific to the agent/agency and what they request from the judge issuing the warrant. Kinda disturbing.</description>
		<content:encoded><![CDATA[<p>Yeah, but even a reputable colo could fall under this blanket assertion. If someone&#39;s doing bad things in your reputable colo, this guilt-by-association taints you too, i.e. you were facilitating the nefarious behavior. And it also taints your innocent customers.</p>
<p>Although I&#39;m sure the same assumption could be applied to VMs too.</p>
<p>Plus, it&#39;s very specific to the agent/agency and what they request from the judge issuing the warrant. Kinda disturbing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gary</title>
		<link>http://theappslab.com/2009/08/18/risks-in-the-cloud/comment-page-1/#comment-8947</link>
		<dc:creator>Gary</dc:creator>
		<pubDate>Thu, 20 Aug 2009 04:31:07 +0000</pubDate>
		<guid isPermaLink="false">http://theappslab.com/?p=3290#comment-8947</guid>
		<description>A later report&lt;br&gt;&quot;FBI Special Agent Allyn Lynd...told the court that the owner of the co-location facility was being investigated for fraud and that even though Liquid Motors was not part of the investigation, its equipment might have been used to facilitate fraud by others.&quot;&lt;br&gt;For a reputable host, COLO should be safer than VM as at least your equipment is physically separate from other customers. SaaS, where your data may sit right next to a suspect&#039;s, would be riskier.</description>
		<content:encoded><![CDATA[<p>A later report<br />&#8220;FBI Special Agent Allyn Lynd&#8230;told the court that the owner of the co-location facility was being investigated for fraud and that even though Liquid Motors was not part of the investigation, its equipment might have been used to facilitate fraud by others.&#8221;<br />For a reputable host, COLO should be safer than VM as at least your equipment is physically separate from other customers. SaaS, where your data may sit right next to a suspect&#39;s, would be riskier.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jake</title>
		<link>http://theappslab.com/2009/08/18/risks-in-the-cloud/comment-page-1/#comment-8943</link>
		<dc:creator>Jake</dc:creator>
		<pubDate>Wed, 19 Aug 2009 07:40:09 +0000</pubDate>
		<guid isPermaLink="false">http://theappslab.com/?p=3290#comment-8943</guid>
		<description>Yeah, downtime is a killer, and an SLA won&#039;t protect you from lost revenue due to the provider&#039;s downtime. As with most things, companies write off this risk in favor of the bottom line number, until it happens to them.&lt;br&gt;&lt;br&gt;I hadn&#039;t heard that about hardware seizures. It&#039;s actually pretty frightening that the FBI seemed to know nothing about colocation. I hope that was a mistake, or FUD from a party under investigation.&lt;br&gt;&lt;br&gt;Funny, the colocation story makes an argument for EC2 when you compare losses :) &lt;br&gt;&lt;br&gt;Of course, I highly doubt any VC would fund a 90s-style operation whose business plan called for buying its own gear and hardware and staffing its own datacenter under its own operation. No one would do that with their own money.&lt;br&gt;&lt;br&gt;Refer again to the bottom line vs. risk hedge.</description>
		<content:encoded><![CDATA[<p>Yeah, downtime is a killer, and an SLA won&#39;t protect you from lost revenue due to the provider&#39;s downtime. As with most things, companies write off this risk in favor of the bottom line number, until it happens to them.</p>
<p>I hadn&#39;t heard that about hardware seizures. It&#39;s actually pretty frightening that the FBI seemed to know nothing about colocation. I hope that was a mistake, or FUD from a party under investigation.</p>
<p>Funny, the colocation story makes an argument for EC2 when you compare losses <img src='http://theappslab.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  </p>
<p>Of course, I highly doubt any VC would fund a 90s-style operation whose business plan called for buying its own gear and hardware and staffing its own datacenter under its own operation. No one would do that with their own money.</p>
<p>Refer again to the bottom line vs. risk hedge.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gary</title>
		<link>http://theappslab.com/2009/08/18/risks-in-the-cloud/comment-page-1/#comment-8941</link>
		<dc:creator>Gary</dc:creator>
		<pubDate>Wed, 19 Aug 2009 06:06:16 +0000</pubDate>
		<guid isPermaLink="false">http://theappslab.com/?p=3290#comment-8941</guid>
		<description>&quot;They’re easy and affordable&quot;. The &#039;affordability&#039; can be a huge risk in itself. For example, if EC2 doesn&#039;t meet the uptime SLA, you get a service credit for the downtime. The amount spent to ensure an SLA is met will differ considerably depending whether you plug your business&#039;s potential loss of $10,000 a day against the service providers potential loss of $10 a day.&lt;br&gt;Another risk I&#039;ve read about is hardware seizure. If one of your service provider&#039;s other customers is dodgy, you are also at risk. &lt;a href=&quot;http://www.wired.com/threatlevel/2009/04/data-centers-ra/&quot; rel=&quot;nofollow&quot;&gt;http://www.wired.com/threatlevel/2009/04/data-c...&lt;/a&gt;</description>
		<content:encoded><![CDATA[<p>&#8220;They’re easy and affordable&#8221;. The &#39;affordability&#39; can be a huge risk in itself. For example, if EC2 doesn&#39;t meet the uptime SLA, you get a service credit for the downtime. The amount spent to ensure an SLA is met will differ considerably depending whether you plug your business&#39;s potential loss of $10,000 a day against the service providers potential loss of $10 a day.<br />Another risk I&#39;ve read about is hardware seizure. If one of your service provider&#39;s other customers is dodgy, you are also at risk. <a href="http://www.wired.com/threatlevel/2009/04/data-centers-ra/" rel="nofollow"></a><a href="http://www.wired.com/threatlevel/2009/04/data-c" rel="nofollow">http://www.wired.com/threatlevel/2009/04/data-c</a>&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>

