Refuting Cloud 'Lock-In': Zero, One, Too

Arguments against the cloud are a lot like Disney movies: every few years, the people who make money from them get to re-release them to a whole new audience.

My informal measures of cyberspace FUD are now showing just such a cyclical spike in an oft-heard excuse for postponing cloud platform adoption: the putative threat of 'lock-in'. It's an oldie, but it seems that some think it's a goodie.

There are three good reasons why the 'lock-in' myth should not get in the way of using the cloud – to your own best advantage.

0: Let's start with what I'll call the Zero-Based Argument against the notion of 'lock-in' for any pure service. The customer of a service has zero fixed-asset cost. The client of a service provider will never have to wrestle with the question, "Are we willing to write off the undepreciated portion of that great big capital investment?" – because the customer hasn't made one.

This is fundamentally different from the situation facing the buyer of on-premise hardware, and the licensee of on-premise software. Those are big sunk costs. The chief financial officer wants to depreciate those over time, not let them take a Megalodon bite from the current year's bottom line. This is the problem with deciding to stop throwing good money after bad: it requires acknowledging the "bad" part, in an auditable statement that's bound to get painful attention.

Get over it: freedom from "sunk-cost fallacy" is a true competitive edge for any decision maker. Sadly, though, if your choices are (i) spend $X on annual maintenance and keep on limping along for one more year, or (ii) write off $3X or $5X and announce that you're starting over with something that works, that X may mark the spot where the arrows will hit the person who makes the more costly call. That's lock-in, but buyers of services don't have that problem.

1: The next rung up the ladder is the One-Based Argument, as in The Myth of 'One and Only'. You'll see people wring their hands over the idea that developing applications on some particular platform (cloud or otherwise) will deprive them of all the good things that other useful platforms can do.

This is almost purely an imaginary problem: developers don't settle for the single least unsatisfactory technology, but overwhelmingly tend to have more than one wrench in their toolbox (and probably a couple of hammers as well). It's easier to find work that way.

You want numbers? OK, I like numbers too. Zend Technologies Ltd. caters mostly to developers using PHP, widely employed in server-side scripting and estimated by Tiobe Software BV to have about 6% of programmers' mind share. Zend's survey of 3,335 developers using PHP also found them using an average of roughly two other languages as well: I calculate this by adding up the percentages of "check all that apply" and getting a total of 294%, including the 100% who presumably use PHP.

Is PHP the world's best language? Who cares? At least 82% of its surveyed users are using at least one other; in fact, fully one-sixth of them are using C or C++ (which are pretty much the opposite of PHP in every respect). Likewise for enterprise adoption of database engines: in one Forrester survey, 90% of companies were found to be using more than one DBMS for mission-critical applications.

That's why it's silly to pretend that users of any service are being forced into a mutually exclusive choice: it's clear that companies are accustomed to the idea of integrating multiple vendor offerings, and there are entire ecosystems built around doing that more affordably and effectively.

Even so, I continually hear straw-man arguments against "putting everything in the cloud" – but I'll be the first to say that the cloud is where you should do the things that either don't work well, or haven't been made to work at all, in the legacy IT environment.

My recommendation is to treat the toxic sludge of legacy apps the way you'd treat a Chernobyl in your basement. Put a concrete cube around it, feed power in and get data out, but don't go in there and try to innovate in it: instead, innovate in mobile experience delivery, and social community creation, with cloud platforms that are designed to integrate and add value instead of being built to wall out alien technology.

Too: Last up is the Argument of Too – as in its taking "Too Much Money, Too Much Time" to insist on using only the purest non-proprietary ingredients in real applications delivered to solve real problems in the real world.

When platforms are turning over on a cycle of three to ten years, you can build your cathedrals out of toothpicks and still have a market for the application when it's done. If you'd started writing the world's most highly optimized Windows XP application a decade ago, almost half the world's PCs would still be able to run it today – even if neither Vista nor Windows 7 were sufficiently backward compatible (and you'd have to try to achieve that dubious distinction).

That was then, this is now. In a world of mobile devices on five-month product cycles, it's not tolerable to require at least that long to build a custom application. Fortunately, IDC research found that application cycles for companies using Force.com shrink to roughly two months, yielding significant time-to-market advantage when mobile users demand a first-class experience on their devices.

I call that 'leverage' rather than lock-in – and anyone who's ever used Visual Basic, rather than write a glass-TTY application for 80x25 text-mode interaction, has already demonstrated agreement with me on this. But Windows-only delivery is no longer needed as the reluctant concession to reach the most people in the least time: write it, and run it, in a way that lets people access it from a standards-conformant browser, and it pretty much doesn't matter how you do it.

Further, arguments 1 and Too combine: by all means, write the computational core of an application in pure Java (or even pure FORTRAN) so that it can run on just about anything, just about forever – then add the business value of the mobile experience, or the high-value externally offered API, by integrating across the boundaries of data centers and interoperable cloudlets. That way, you won't consume your capital in building a long-delayed but short-lived market offering, but you will be able to maximize the productive life of your differentiating intellectual property. What's not to like?

The last point I'd like to make, not directly involved in the 'lock-in' furor but related to that topic, is the question of whether using clouds will save money over the long haul. After all, if people were certain that the economics were enduring, would lock-in be a problem?

I don't like shining the spotlight on clouds for cost reduction, because ultimately a higher ROI leads to more investment rather than less. If you promise a lower IT spend, you're building an uphill ramp that you'll later have to ascend when you want to invest in a strategic opportunity.

Even without that consideration, though, I have some more numbers – this time, on the subject of cloud adoption for long-range cost reduction. I won't repeat the calculation, since it's right here with even the HP-12C keystrokes to perform it. Bottom line: with the cost of a major data center as an endowment, I could fund decades of cloud services for the same number of workers.

It seems to me that these are the points that are necessary and sufficient.

• The customer can always walk away.
• The choice of using a service need not exclude complementary services.
• The economics of shunning all platform leverage are bad in the short run, and the use of cloud services remains economically attractive in the long run.

Perhaps this will leave more oxygen in the room to do what's needed – "to address the tough challenges by amplifying enterprise strategies and operations," in the words of today's Gartner release. Given the choice between upside opportunities and retro myths, it seems clear which matters more.

Licensed under Creative Commons Attribution-No Derivative Works 3.0.