How do you choose where to enter the Cloud?

You recognize that “utility computing” is part of your future: you’re ready to outsource some portion of your computing load to outside providers. You spend money, and they assume daily headaches of maintenance, backups, and so on: that’s a fair deal. While you know there are risks, you recognize the advantages of being able to control your costs and get help with all the time-consuming parts of operations.

How do you go from that general goal to contracting for a specific service from a specific vendor, though? This is what celebrated author David Linthicum labels as the “API” problem in a recent posting. API here, of course, it the initialism for “application programming interface”. It’s really, really hard to compare two different cloud offerings–sometimes even two different ones from the same vendor!–because they have so little in common. Linthicum, as well as Michael Steinhart, in a follow-up comment, focus on APIs for IaaS (infrastructure as a service). For me, the problem is even more general: I see similar difficulties in analysis of SaaS (software as a service), PaaS (platform as a service), and other cloud offerings.

Linthicum and Steinhart fear “lock-in”: choose a particular vendor, construct your applications to depend on that vendor, and you become vulnerable to mishaps within the vendor. In the worst case–a worst case that happens rather often in computing history–the vendor might vanish just a short time after it seemed like a market leader. Part of the reason you’re probably considering the Cloud is to eliminate risk, so lock-in makes all of us feel queasy.

Linthicum and Steinhart don’t offer solutions; the former has only “a few nuggets of advice”. This is largely correct: there is no real solution to the API problem. To some extent, the best that we can do during the next few years is to observe Linthicum’s advice–plan, analyze, experiment–aware that it will be a while before the winners and losers are known.

I have several tips to supplement theirs, though, that will further reduce your cost and risk:

1. The Cloud is not just about IaaS. Deployment of production applications into IaaS is particularly susceptible to lock-in. You don’t have to start there, however; you can run pilot projects or proof-of-concept or experiments with SaaS. You can push development, testing, or other non-production activities into the Cloud first. The experience and knowledge you gain will teach you a lot about what you eventually need for Cloud-based deployment of mission-critical applications.
2. Make your analysis into an asset. Write up your organization’s situation, requirements, and alternatives with enough care that they will still make sense and be valuable next year. A good analysis has the potential to be a resource for many related projects; parts of it can be re-used as you collect requirements and express designs for other work. Even if lock-in catches you, and you have to change Cloud API and re-work what you’ve developed on top of that API, to have a well-written analysis in hand gives you a head start.
3. Emphasize hybrid solutions. Expect that you’ll eventually run combinations of public and private Clouds. Design for hybrids from the start, and insulate yourself from the extremes of lock-in.