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.)
Good delineation. The lines are blurring. For example, QuickBase can do some SaaSy things as well. A minor nit. QuickBase is not the name of the company. It is Intuit.
Alistair,
Nice roundup! There are two predominant viewpoints for these taxonomy discussions – inside-out, and outside-in.
Much of the existing work to date has been inside-out: insiders in the industry discussing the nuances of different technical solutions and defining buckets to categorize them. This is very important for insiders to help drive detailed debates into who is doing what and with what technologies. But that is not the right focus for outsiders looking to solve a problem.
I think you have hit on the outside-in view. An outsider wants a solution to a project they already have or plan to build. They don’t need to know the nuances to start with – they just want that short list of numbers to call to get engaged with the right providers. The sales teams will then help them sort out what they need. I like your “If you have [this], look to [these] guys.” approach for this.
A consumer friendly taxonomy!
PJL
I really like this taxonomy. I’ve talked to a lot of people referring to EC2 and App Engine as if they were interchangeable cloud services. Your taxonomy makes the differences stand out.
For completeness, you could add a “Colocation” (“rackspace” ?) layer at the bottom for just power-pipe-and-ping hosting. Examples are rackspace.com, Savvis, Verio, etc.
Jim