Jay HeiserOther than some analysis and speculation about how the takedown changed traffic patterns without actually reducing global piracy, and regular reports about the legal status of Kim Dotcom, the Megaupload drama hasn’t provided much in the way of news for a couple of weeks.
On the theory that putting the string ‘Megaupload’ into the title of a blog posting increases readership, this seemed a good opportunity to revisit the idea of a cloud continuity service sometimes referred to as ‘SaaS escrow.’ In brief, this is the idea that the customers of a SaaS provider might pay a bit extra for a sort of ‘vendor viability insurance.’ If the SaaS vendor went belly up, a third party would continue to provide service to those customers that paid for the premium service. It seems an intriguing way to reduce one annoying form of risk that is uniquely significant for SaaS, but in practice, it seems to be a service that nobody is offering.
Just to make sure that some new vendor hadn’t set up shop overnight, I searched on the the term SaaS escrow, and was surprised to get a Wikihit inside the article on Software as a Service. It turned out that the reference for that brief mention was some Gartner research from 2009. That published research caveated the concept with multiple mays, finally concluding “we have not seen evidence of this, it may be a viable alternative“. It may still be, but we still are not aware of any signficant example.
At a minimum, the offerer of a ‘SaaS escrow’ would need a relatively recent copy of 1) the object code, 2) a platform to run it, 3) the user accounts, 4) the data from those users, 5) access rights and configurations, 6) all the other configuration needed, 7) somebody familiar enough with the service to maintain it, 8 ) someone familiar enough with the service to provide user support, 9) source code and someone familiar enough with it to fix it if it broke, 10) etc, etc, etc (more stuff that I can’t think of until I don’t have it). The idea of picking up a million users, their data, and the code from a defunct provider doesn’t seem as practical as the idea of the provider’s hosting service continuing to run something that is already in their facility.
Although the Megauploaders were never given the slightest assurance that such a thing would ever happen (quite the opposite), speculation continues on the potential that Carpathia, and the other hosting services in multiple countries, might resurrect Megaupload so all those individuals and small businesses can get their data back. One of the wonderful things about today’s chain of providers is that the US Federal Government can’t just kill the piracy beast by putting it out of business. Although the non-too-subtle written instructions from the Department of Justice to the US-based hosting providers expressed a hope that the Megapetabytes be digitally destructed, all indications are that the digital carcass lingers on.
Although Carpathia has disavowed possession of the root passwords (not in so many words), if the DOJ would return control of the domain, presumably, the systems could just be powered on. Given that the reason for seizing the domain in the first place was the compelling Federal case that they were chock full of illegal content, it seems highly unlikely that the US justice system would approve of such a step, unless the toxic material is blocked. And how would you do that?
Aside from the practical considerations of picking up a defunct SaaS service and moving it, or just powering it back on in place, the Megaupload situation highlights what may be an even more significant factor: the intangibles. Megaupload is unique in that it contains such a huge amount of inconveniently illegal content, and it represents a huge liability for a service to undertake the responsibility of only serving the good bits. While an enterprise-oriented SaaS offering is much less likely to be full of such toxic data, there’s no telling what’s inside anybody else’s service. Today’s hosting provider bends over backwards to insulate themselves, logically and legally, from their SaaS tenants. I don’t see that changing.
If you have an application running on your hardware, inside your own data center, you are somewhat insulated from the business failure of the provider. You can probably run the thing indefinitely, while you figure out how to migrate to something else. If your app in the cloud dies, or the vendor goes bankrupt (or goes to jail), you have no such grace period. While your data won’t immediately disappear, its unlikely that anyone in the chain of providers will let you access it.
Comments Off
Category: Cloud risk management Vendor Contracts Tags: continuity, recovery, SaaS escrow
