On the cusp of launching its Azure cloud computing service, Microsoft is also making a savvy bid to lock up a patent for one of the main worries--vendor lock-in--of cloud users. (The other big concern is security.) The folks from Redmond have filed a patent application for migrating data to a new cloud, which is what you'd have to do when leave your first vendor.The patent has a number of unusual angles, so bear with me while I deconstruct it.

The application is number 20080080526, filed by Microsoft this past April, and entitled "Migrating Data To New Cloud." (The current application appears to be a refile of a doc originally submitted in Sept. 2006. Such resubmittals are common practice, by the way.)

Two things immediately jump out at the reader. First off is the fact that this patent proposal addresses data migration not so much from a vendor lock-in perspective (as in, you have to migrate your data because you want to bag your provider and go get a better deal) but rather as an auto fail-over data protection mechanism. (I'll get to the second thing, which is that this is constituted as an automated migration process, later on.)

Here's the abstract, which spotlights that first fail-over aspect via the "termination notice" language:

"The claimed subject matter provides a system and/or a method that facilitates preserving and maintaining data and/or services associated with a network service. . .An interface component can receive a termination notification related to the network service. An executor component can relocate at least a portion of one of data and a service associated with the terminated network service to a disparate replacement network service in order to preserve any services and/or data related therewith."

Actually, the application does address cloud migration prompted by finding a better deal, but that's in the fine print further down. Like this:

". . .the termination notification is data related to identifying a termination of the network service based on at least one of a retirement, a bankruptcy, a buy-out, a dissolution, the network service dissolving, the network service terminated, the network service terminating, the network service dissolving, filing bankruptcy, a closing, a shutdown, a strike, a buyout, the network service ceases to exist, a planned dissolution, a termination of services based on geography, a re-structuring, a user wanting a cheaper rate, a user desiring a better service, a machine deterioration, a virus infections, and a replacement of at least one of a machine and a service."

OK, so that's the when. Now for the how, which is pretty simple. Click through the images I've posted from the patent application, which show how the data migration process works. Basically, there's a detection component (what Microsoft calls the "interface component" in the abstract) which gets the notice that it's time to bake the cookies, er, transfer the data. Then the "executor component" goes and initiates the transfer over to the "replacement network service."

Diagram from Diagram from Microsoft's Migrating Data To New Cloud patent application.(Click picture to enlarge, and to see 42 additional diagrams.)

Pretty straightforward if you ask me. The only thing, though, is that the patent is written up so that all of the data migration will happen automatically. This, in turn raises many questions, all under the general heading of, What the heck?

The biggest is, if you're going to auto migrate on an auto-failure detect, you have to set up where to migrate in advance. In which case you've presumably got a data backup strategy in place, which negates the need to auto migrate your data on a failure to a second service which you probably haven't yet selected. Plus, if your prime cloud provider has failed, what's to say its storage component is accessible?

This is not to mention that the cloud provider itself provides some internal failover protections. (Aha, so perhaps what this patent is trolling for is to protect a method for internal failover within a single providers cloud?)

The other thing this patent application doesn't seem to overtly account for is that transfers of humungous quantities of data can't be done at some discrete point of time, and then nattily completed. When you're talking serious cloud setups, you're going to be dealing with truly Titanic quantities of data. Say, petabytes.

To put this in perspective, if you're talking about the typical links between you and, say, your Amazon EC2 or Microsoft Azure cloud, straight migration of petabytes of data in one fell swoop is a non-starter. I refer you to Sun Microsystems CEO Jonathan Schwartz's blog, Moving A Petabyte of Data. Schwartz, who notes he was trained as a mathematician, runs that numbers and makes the point that, for most Internet connections, it's faster to do such transfers by shipping tapes by boat.

Of course, internal network transfers over Gigabit Ethernet can obviously be done in a couple of hours, but that's not the kind of link you're going to have between your data center and your public cloud provider.

As well, as I think I hinted at earlier, any user with serious quantities of data is going to be backing up and striping that data so that you're not left holding the bag when something goes down.

OK, so I'm not a patent lawyer, even though I've played one on this blog. Still, I can't help but think that the most interesting aspect of this patent application is that fact that it planted a flag in the ground for migrating cloud data.

[Update, Monday, Nov. 30, 6pm: @swardley on Twitter came up with an interesting thought, regarding Microsoft's cloud intentions. He tweets: "This patent pretty much hints that when Azure launches, they'll launch with multiple providers (ISPs) along with their own."]

Follow me on Twitter: (@awolfe58)

What's your take? Let me know, by leaving a comment below or e-mailing me directly at alex@alexwolfe.net. Like this blog? Subscribe to its RSS feed: (here)

 My videos on ( YouTube)

 Facebook 

  LinkedIn

Alex Wolfe is editor-in-chief of InformationWeek.com.