A new take on cloud taxonomies: Migration

I was on a panel in the Bay Area a couple of weeks ago at Cloudconnect. As always, the topic of cloud taxonomies came up. It’s hard to discuss clouds without having a framework about which to discuss them. But taxonomies abound (with good ones from James Urquhart, Peter Laird, David Chappell, John M. Willis, Christopher Hoff, and Sam Charrington) and there’s no clear winner.

I came up with a new way to look at them, which didn’t immediately embarrass me. So here it is, for you to tear apart.

The problem with clouds, you see, is that  criticism levelled at one kind of cloud is a strength of another. For example, infrastructure-centric clouds where IT operators still need to add machines to grow aren’t inherently scaleable; whereas service-oriented clouds that “just work” aren’t as open.

So this model — which I’ll call the “cloud migration taxonomy” for want of a better label, looks at the issue in a way that matters to enterprises: How do I migrate to the cloud?

Here’s how to read the diagram:

  • If you have an existing data center application (say a WordPress instance, or a JBoss server) you can migrate to an infrastructure-centric cloud such as EC2 by simply building a machine image in the cloud. There are companies like rPath that can help with this, and Amazon has a payment system that lets firms like Red Hat get a share of the proceeds from your cloud usage.
  • If you have app code you like, and want to simply “paste” it into a form, you can do so with a service-centric cloud. If you wrote something in Python, you can take that code, tweak it (to remove cloud-incompatible functions such as RDBMS joins) and paste it into App Engine. Microsoft is betting that legions of Windows developers will take the server code they’re familiar with and port it to Azure. This is also why Joyent bought Reasonablysmart, so it has a service-centric cloud offering.
  • The next level of cloud use is to rewrite the process. If you have an in-house process — say, trouble ticketing — that was written on a legacy system (Fortran on a mainframe) you can’t just move it to the cloud. Instead, you’re going to map the business process, and then use a tool to recreate that process in the cloud. This is where Platform-as-a-Service companies like Coghead, Quickbase, Longjump, and many others can play. The app won’t be sexy; but then, neither was your legacy one.
  • At the highest level is Software-as-a-Service. Here, you’re simply copying your content to the cloud app. You might be saving your directory full of Word documents to Zoho, or Google Apps, or Microsoft Office Live. The only thing you’re migrating is the content itself.

When you’re trying to figure out how to embrace the cloud, these are your four options. The lower down you go, the more control you have (and the more work and testing you need to do); the higher up you go, the more turnkey (but the less flexibility and customization you get.) It’s that simple.

There are vendors who blur these lines, of course. Salesforce has SaaS, PaaS, and (arguably) a Service-centric cloud. Google certainly offers Apps, App Engine, and a number of tools like Googlebase that sit in the middle.

Anyway, I’m kinda sick of taxonomies, but what I like about this perspective is that it’s oriented to the issue of enterprise cloud migration that we’re all going to deal with in 2009. It’s going to be front and center at the Enterprise Cloud Summit (ECS) in Vegas (where, amazingly enough, most of the people who’ve been driving the taxonomy debate will all be gathering.)