<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>ISV Survival &#187; SaaS Platforms</title>
	<atom:link href="http://isvsurvival.com/tag/saas-platforms/feed/" rel="self" type="application/rss+xml" />
	<link>http://isvsurvival.com</link>
	<description>A blog for ISVs on Software as a Service (SaaS)</description>
	<lastBuildDate>Sat, 04 Feb 2012 17:59:10 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
		<item>
		<title>SaaS downtime: ISVs will always take the blame</title>
		<link>http://isvsurvival.com/isvs-take-blame-saas-platform-downtime/</link>
		<comments>http://isvsurvival.com/isvs-take-blame-saas-platform-downtime/#comments</comments>
		<pubDate>Mon, 07 Jan 2008 22:06:24 +0000</pubDate>
		<dc:creator>Andrew Biss</dc:creator>
				<category><![CDATA[Articles]]></category>
		<category><![CDATA[SaaS Platforms]]></category>

		<guid isPermaLink="false">http://isvsurvival.com/?p=103</guid>
		<description><![CDATA[ISVs must isolate their applications from today's SaaS platforms to benefit from the improved SaaS platforms expected in the future.]]></description>
			<content:encoded><![CDATA[<p><strong>ISVs must isolate their applications from today&#8217;s SaaS platforms to benefit from the improved SaaS platforms expected in the future.</strong></p>
<p class="figure"> <img width="302" height="192" src="http://isvsurvival.com/wordpress/wp-content/uploads/broken-disk.jpg" alt="Broken hard disk" title="Broken hard disk" /> <br /><br /><span class="figcaption"><em>Image: A disk failure at an on-premise customer is their problem. If your SaaS solution is offline because of problems at your storage service provider then it&#8217;s now your problem. And that&#8217;s a new world of hurt you&#8217;re facing.</em></span></p>
<p>Data storage is very reliable, but still has unexpected and catastrophic failures. That&#8217;s why you backup your data. You must plan for when things go wrong. It&#8217;ll almost certainly not go wrong <a title="The Black Swan - The Impact of the Highly Improbable" href="http://en.wikipedia.org/wiki/Black_swan_theory">in the way you expected</a>, but it <strong>will</strong> go wrong &#8212; sooner or later.</p>
<p>I&#8217;ve seen my fair share of data disasters over the years so I use a variety of media and archive cycles for local backups. For offsite backups I use <a title="Reliable online storage powered by Amazon S3" href="https://www.jungledisk.com/">Jungle Disk</a>. Jungle Disk is a remote storage solution built on the <a href="http://aws.amazon.com/s3/faqs/">Amazon Simple Storage Service</a> (S3) for data storage and the <a href="http://aws.amazon.com/ec2/faqs/">Amazon Elastic Compute Cloud</a> (EC2) for block-level file updates and other services.</p>
<p><span id="more-103"></span></p>
<p>As a <a href="http://aws.amazon.com/">Amazon Web Services</a> user, I follow with interest the <a title="Amazon EC2 offers a shortcut to SaaS" href="http://www.zdnet.com/blog/saas/amazon-ec2-offers-a-shortcut-to-saas/415">increasing acceptance</a> in using Amazon&#8217;s S3/EC2 as a SaaS platform. It now seems to be the default assumption that Web 2.0 startups will use Amazon&#8217;s platform from day 1 to <a title="Amazon S3: Show me the money" href="http://don.blogs.smugmug.com/2006/11/10/amazon-s3-show-me-the-money/">save a lot of money</a>. Of course, they are also happy to leverage Amazon&#8217;s reputation: <em>&#8220;If it&#8217;s good enough for amazon.com then it is good enough for our users&#8230;&#8221;</em></p>
<p>This is all well and good &#8212; until the SaaS platform fails &#8212; and it will &#8212; and then it&#8217;s <strong>your</strong> fault!</p>
<p>If you cannot provide your application services to your customers then it is <strong>always</strong> your fault! It will not matter what <a title="Outages caused by raccoons, thieves and random gunfire" href="http://royal.pingdom.com/2008/01/03/outages-caused-by-raccoons-thieves-and-random-gunfire/">unusual and totally unexpected event</a> has struck your SaaS platform provider.</p>
<p>If your customers cannot get at their data then it is your fault. The trust relationship you have invested a lot to build with your customer will be damaged. It is you that is going to suffer the consequences, not your SaaS platform provider.</p>
<h2>Choosing the right SaaS platform</h2>
<p>It goes without saying that it makes absolutely no sense for you to try to build and run your own SaaS-capable data centre. You must depend on one or more external suppliers for your SaaS platform.</p>
<p>To gain the trust of your customers, the level of service you commit to your customers will be higher than that offered to you by your SaaS platform provider.</p>
<p>This <strong>&#8220;SaaS Trust Gap&#8221;</strong> between what you must offer your customers &#8212; and what your SaaS platform provider offers you &#8212; is one of the major risks you must manage to survive and profit from the shift to SaaS.</p>
<p>The right choice of SaaS platform provider is therefore critical to your success.</p>
<h2>SaaS platforms will always be unreliable</h2>
<p>As the market for SaaS platforms develops they will become increasingly reliable. However, they can never be 100% reliable. For the short term probably. In the medium term probably. But in the long term, no. There are just too many things that can (and will) go wrong.</p>
<p>Assume for the moment that your SaaS platform is unreliable. How can you still provide a higher level of service to your customers than that provided to you by your SaaS platform provider?</p>
<p>The basic concept is the same as you are using today with storage arrays. Simply assume your SaaS platform is unreliable and architect your SaaS infrastructure around this fact of life.</p>
<h2>My provider guarantees 100% uptime&#8230;</h2>
<p>At this point you might object that <strong>your</strong> provider commits to 100% uptime. They have redundant power supplies, redundant Internet connections, fail over this and that.</p>
<p>While 100% uptime might be their stated goal, even the leading tier 1 data centres <a title="Royal Pingdom - The major incidents on the internet in 2007" href="http://royal.pingdom.com/2007/12/27/the-major-incidents-on-the-internet-in-2007/">have major outages</a>. Even Amazon&#8217;s <a title="Amazon - 10 Billion Objects on S3 Storage" href="http://www.datacenterknowledge.com/archives/2007/11/06/amazon-10-billion-objects-on-s3-storage/">widely-used</a> S3 has not been immune to <a title="Data Centre Knowledge - Amazon EC2 Outage Wipes Out Data" href="http://www.datacenterknowledge.com/archives/2007/10/02/amazon-ec2-outage-wipes-out-data/">occasional downtime and claims of lost data</a>.</p>
<p>Even if your deployment platform provider really was 100% available, that does not always help your customers. There are a lot of &#8220;moving parts&#8221; between your SaaS platform and your customers desktops. You will never be able to guarantee100% end-to-end uptime.</p>
<p>So, what do you do?</p>
<h2>Standardised SaaS platforms?</h2>
<p>In the ideal word there would be a standard for SaaS platforms and a range of suppliers competing on price and availability. You could then develop and manage your applications independent of the underlying deployment platform provider.</p>
<p>This ideal world would make it easier to move from one SaaS platform provider to another in order to improve service to your customers, and to reduce your risks as SaaS platform providers gradually catch up with the commitments you are already making to <strong>your</strong> customers.</p>
<p>The current market for SaaS platforms is too immature, however, for such a standard to have emerged. And, based on past experience, it is pretty unlikely that anything will happen anytime soon.</p>
<p>We are still at the stage of proprietary platforms, each with their own proprietary interfaces and architectures. We have the well-known players such as Amazon, IBM, Microsoft, Oracle, Salesforce.com etc, plus <a title="OpSource - The Software as a Service (SaaS) Delivery Experts" href="http://www.opsource.net/">OpSource</a>, <a title="Apprenda - Software as a Service (SaaS) Platform" href="http://apprenda.com/">SaaSGrid</a>, <a title="FlexiScale - Utility Computing On-Demand" href="http://www.flexiant.com/products/">FlexiScale</a> and a range of smaller players.</p>
<p>I think the solution to this problem of depending on proprietary SaaS platforms is essentially the same one you have successfully applied to a whole range of technical problems in the past: abstraction.</p>
<h2>Abstracting the SaaS platform</h2>
<p>In the same way that you developed a &#8220;database abstraction layer&#8221; or a &#8220;platform abstraction layer&#8221;, you should consider adding a &#8220;SaaS deployment platform abstraction layer&#8221; to your application architecture.</p>
<p>There are already some SaaS platform technologies coming to market which are clearly moving in this direction.</p>
<p>Take the Amazon EC2 platform as an example. The Amazon EC2 architecture makes it possible to manage and run instances in a flexible, reliable and cost effective manner. However, the way in which you need to interact with the Amazon EC2 &#8220;management system&#8221; is fairly complex and proprietary.</p>
<p>To address this problem SaaS platform vendors such as <a title="Setup and Manage 1 to 1000+ Servers on AWS" href="http://www.rightscale.com/">RightScale</a> and <a href="http://www.cloudscale.net/">CloudScale</a> are developing technology that abstracts away the details of the Amazon EC2 platform.</p>
<p>While the current focus is on making it easier to use EC2, the same approach can be extended to make your SaaS applications independent of the underlying SaaS deployment platform.</p>
<h2>Leveraging the future</h2>
<p>The market is driving towards &#8220;Cloud Computing&#8221; and &#8220;Utility Computing&#8221;, but those clouds and utilities will never be 100% reliable. An often-used analogy <a title="The Big Switch -  Rewiring the World, from Edison to Google" href="http://www.nicholasgcarr.com/bigswitch/">compares cloud computing to the electrical grid</a>. We need to bear in mind, however, that more than 100 years later we still have blackouts from time to time!</p>
<p>A competitive market for SaaS platforms will emerge, but to benefit you will need to:</p>
<ul>
<li>Treat your SaaS platform as just another piece of technology to be abstracted away.</li>
<li>Always bear in mind that your current SaaS platform will almost certainly not be your future platform.</li>
<li>Protect yourself against being locked in to your current SaaS platform provider.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://isvsurvival.com/isvs-take-blame-saas-platform-downtime/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

