The move to turnkey computing

At this year’s Cloud Connect, Werner Vogels predicted a future in which everything-as-a-service is the norm. While enterprise IT often equates virtual machines with the cloud, the reality is that virtual machines are only one of dozens of services Amazon offers. Its competitors aren’t far behind: companies like Google offer a horde of APIs, and even more traditional memory/compute/storage providers like Joyent are adding turnkey products for large storage.

In the end, nobody wants to see the sausage being made. Recent announcements by folks like VMWare, public provider acquisitions of PaaS products, competing private stacks like Openstack and Cloud.com, and private cloud tools that run higher up the stack remind us of one thing above all else: herding your boxen is a distraction from the business of building software and deploying applications.

I tried to argue this point at Cloud Connect, in a presentation entitled The Move to Turnkey Computing. Here it is on Slideshare, as a PDF with speakers’ notes.

Delivery Strategies opener from Enterprise 2.0

Yesterday, we opened up the Delivery Strategies track at Enterprise 2.0 with a session called, “apps don’t deploy themselves.” The basic idea was that IT managers have many more options to consider when deploying applications, from the platforms on which things run to the economics of building versus buying.

Here’s the deck in Slideshare.

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.)

The Enterprise Cloud (part 1)

I was hassled by Alistair last year about the infrastructure choices at my company because I chose not to leverage the capacity and cost benefits of EC2. The reason, I explained, had everything to do with SLAs. My servers dish up content and application flow for phone calls. Jitter and delay are everything in that scenario because unlike web browsers that give visual cues to show they’re working, a phone call just gives dead air. And dead air is dangerous. Continue reading “The Enterprise Cloud (part 1)”