<?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: Coghead post-mortem</title>
	<atom:link href="http://www.cloudviews.org/2009/03/coghead-post-mortem/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.cloudviews.org/2009/03/coghead-post-mortem/</link>
	<description></description>
	<lastBuildDate>Thu, 18 Mar 2010 11:25:48 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: hugo.mag</title>
		<link>http://www.cloudviews.org/2009/03/coghead-post-mortem/comment-page-1/#comment-145</link>
		<dc:creator>hugo.mag</dc:creator>
		<pubDate>Tue, 17 Mar 2009 12:29:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.cloudviews.org/?p=500#comment-145</guid>
		<description>Hello Eric,
Thanks for your comment.

I agree with your analysis that the migration path to other platforms is very difficult in the Platform-as-a-Service (PaaS) area, but at this time we already see some common functionalities between the different players and these common functionalities can be used as a basis to improve migration, by allowing not just data but also business rules to be moved from one PaaS to another.

Migration to other tools is a know problem that all software areas have, from simple documents migration (from Microsoft Word to OpenOffice for example) to traditional software packages (for instance, when you want to change from one ERP to another you normally pay a consulting firm to migrate the data). 
For me a good example how to mitigate migration issues can be seen in the social platforms area. The Open Social effort in this area allowed users to copy data from one platform to another.

I think that if a &lt;a href=&quot;http://code.google.com/apis/opensocial/&quot; rel=&quot;nofollow&quot;&gt;OpenSocial &lt;/a&gt;like effort appears in the PaaS area could surely mitigate migration issues with the added advantage of avoiding lock-in problems.

In relation to the migration path out, my opinion is that a company that offers services in the cloud (regardless of its type - PaaS, SaaS, IaaS) should create migration policies that clearly show its users how and when they can export their data (and their building blocks if possible), the same way these companies state their privacy policies.</description>
		<content:encoded><![CDATA[<p>Hello Eric,<br />
Thanks for your comment.</p>
<p>I agree with your analysis that the migration path to other platforms is very difficult in the Platform-as-a-Service (PaaS) area, but at this time we already see some common functionalities between the different players and these common functionalities can be used as a basis to improve migration, by allowing not just data but also business rules to be moved from one PaaS to another.</p>
<p>Migration to other tools is a know problem that all software areas have, from simple documents migration (from Microsoft Word to OpenOffice for example) to traditional software packages (for instance, when you want to change from one ERP to another you normally pay a consulting firm to migrate the data).<br />
For me a good example how to mitigate migration issues can be seen in the social platforms area. The Open Social effort in this area allowed users to copy data from one platform to another.</p>
<p>I think that if a <a href="http://code.google.com/apis/opensocial/" rel="nofollow">OpenSocial </a>like effort appears in the PaaS area could surely mitigate migration issues with the added advantage of avoiding lock-in problems.</p>
<p>In relation to the migration path out, my opinion is that a company that offers services in the cloud (regardless of its type &#8211; PaaS, SaaS, IaaS) should create migration policies that clearly show its users how and when they can export their data (and their building blocks if possible), the same way these companies state their privacy policies.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eric Novikoff</title>
		<link>http://www.cloudviews.org/2009/03/coghead-post-mortem/comment-page-1/#comment-141</link>
		<dc:creator>Eric Novikoff</dc:creator>
		<pubDate>Sun, 15 Mar 2009 16:12:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.cloudviews.org/?p=500#comment-141</guid>
		<description>Lock-in is a problem with all three types of Cloud Computing (Platform-as-a-Service, Software-as-a-Service, and Infrastructure-as-a-Service) however, the problems are different at each level.

I think Platform-as-a-Service faces the biggest challenges since any platform that offers a service not available by installing open-source software onto a server essentially has no easily migratable alternative, as shown by Coghead.  If the service is delivered as a proprietary API or actionable metadata, then moving your code or metadata elsewhere doesn&#039;t enable you to use it.  There are few standards in this area, precisely because it is at the forefront of innovation.

Software-as-a-Service doesn&#039;t present as many problems, since user data and metadata are already exchangeable through XML or even the dreaded CSV, but as I have seen trying to use my NetSuite data in another application, even very simple business data and metadata requires that the receiving system be customized to understand it.
 
Infrastructure-as-a-Service presents the least lock-in problems, since the services have to be more or less compatible due to the requirements of the application software and the standards imposed by the underlying hardware.   However, even here there can be some issues around differences in services the IaaS vendors offer.  For example my company offers automatically scaling cloud services, which are not offered elsewhere and would require additional development effort to realize with another vendor.  And we also offer fully hands-off administration of customers&#039; clouds, which they would have to hire staff for if they went elsewhere. 

These differences between providers are actually seen as advantages by customers, so they will continue to pose lock-in problems.   It is the responsibility of the vendors to provide a migration path out, but few seem interested in it at the moment.

-Eric Novikoff
ENKI
http://www.enkiconsulting.net</description>
		<content:encoded><![CDATA[<p>Lock-in is a problem with all three types of Cloud Computing (Platform-as-a-Service, Software-as-a-Service, and Infrastructure-as-a-Service) however, the problems are different at each level.</p>
<p>I think Platform-as-a-Service faces the biggest challenges since any platform that offers a service not available by installing open-source software onto a server essentially has no easily migratable alternative, as shown by Coghead.  If the service is delivered as a proprietary API or actionable metadata, then moving your code or metadata elsewhere doesn&#8217;t enable you to use it.  There are few standards in this area, precisely because it is at the forefront of innovation.</p>
<p>Software-as-a-Service doesn&#8217;t present as many problems, since user data and metadata are already exchangeable through XML or even the dreaded CSV, but as I have seen trying to use my NetSuite data in another application, even very simple business data and metadata requires that the receiving system be customized to understand it.</p>
<p>Infrastructure-as-a-Service presents the least lock-in problems, since the services have to be more or less compatible due to the requirements of the application software and the standards imposed by the underlying hardware.   However, even here there can be some issues around differences in services the IaaS vendors offer.  For example my company offers automatically scaling cloud services, which are not offered elsewhere and would require additional development effort to realize with another vendor.  And we also offer fully hands-off administration of customers&#8217; clouds, which they would have to hire staff for if they went elsewhere. </p>
<p>These differences between providers are actually seen as advantages by customers, so they will continue to pose lock-in problems.   It is the responsibility of the vendors to provide a migration path out, but few seem interested in it at the moment.</p>
<p>-Eric Novikoff<br />
ENKI<br />
<a href="http://www.enkiconsulting.net" rel="nofollow">http://www.enkiconsulting.net</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pcalcada</title>
		<link>http://www.cloudviews.org/2009/03/coghead-post-mortem/comment-page-1/#comment-140</link>
		<dc:creator>pcalcada</dc:creator>
		<pubDate>Thu, 05 Mar 2009 10:14:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.cloudviews.org/?p=500#comment-140</guid>
		<description>Good catch Hugo, this is exactly why I think that the work done by the UCI working group is fundamental. Without interfaces like the one they are promoting, we are in danger of lock-in inside a Cloud provider..</description>
		<content:encoded><![CDATA[<p>Good catch Hugo, this is exactly why I think that the work done by the UCI working group is fundamental. Without interfaces like the one they are promoting, we are in danger of lock-in inside a Cloud provider..</p>
]]></content:encoded>
	</item>
</channel>
</rss>
