5 ways to protect against vendor lock-in in the cloud

Two weeks ago, Google announced a significant price increase for use of its App Engine Platform-as-a-Service. The increase itself was not a huge surprise. Google had been making noises that something like this was in the offing for a number of months. But the size of the increase shocked the Web development and cloud applications community. For most users, the cost of using the Google runtime environment effectively increased by 100% or more.

A huge online backlash ensued. For its part, Google put off the increase by a month and moderated some of the increases. But the whole incident brought many nagging doubts about the cloud to the surface. Said one poster on one of the many threads that lit up the Google Groups forums after the increase:

I like so many of us have spent a lot of time learning app engine – i have been worried like so many that using app engine is a mistake because any app you invest/build can only be run on… app engine.

Because the Google PaaS requires that developers customize code specifically to run in that environment and nowhere else, rewriting that code takes a lot of time, effort and money. With salaries for programmers hitting record highs in the Bay Area and recent CS graduates pulling in $ 120,000 or more to code, any big move that forced major code rewrites would ultimately wallop the bottom line. Ironically, these increases disproportionately affected numerous hobbyists and small developers running interesting applications – the creators of the next proverbial Google. Certainly corporate IT departments took notice, as well.

Vendor lock-in will make you vulnerable

Unquestionably, Google App Engine price increase revealed a key fundamental weakness of many cloud businesses. Namely, vendor lock-in does exist in the cloud. This seems odd because one of the benefits of the cloud specifically was to obviate the advantage of vendor lock-in and make applications more portable. In that worldview, no cloud rules them all (not even Amazon) and companies operating applications in the cloud can quickly and easily port their applications to other PaaS offerings or to other IaaS providers.

With vendor lock-in comes vulnerability to price increases. In all likelihood, Google – a data-driven business if there ever was one – was rebalancing pricing to reflect its own need for profitability. But for developers and app makers, this drastic shift effectively turned their decision to go with Google App Engine into what may have been a “bet-the-company” decision without ever realizing it. For the PaaS industry in general, the move raises significant uncertainty. If Google has to raise its prices this much, who’s next?

Start thinking defensively before you choose a platform

In a similar vein, developers who put their applications up on Heroku may not have realized that their business fate depended on the fidelity of the Amazon EC2 cloud. If a company had been planning a big sales event or promotion during the extended EC2 outage, those three days of hard downtime may have had an outsized impact.

So clearly the rules of the game have changed for anyone who wants to put an app in the cloud and run a real business. Defensive thinking is in order. Here are five key rules to avoid getting gouged by Google App Engine or eviscerated by an EC2 outage:

Avoid vendor lock-in at all costs. This is now a no-brainer. Make sure that your app can be easily ported to other clouds if you need to move due to service outages. If you must write apps that require serious customization, make sure you have a back-up plan and, if you can swing the cost, an alternative cloud running your code as a backup.
Know thy PaaS. Spreading the risk among multiple PaaS providers makes a lot of sense – unless they are all totally dependent on one big cloud to deliver your applications and cloud business. Explore installable PaaS options that you yourself control. So ask pointed questions about where your PaaS is running and how they are managing their risks of failure of a big cloud.
Ask hard questions about redundancy and system architecture. Deep under the covers of most clouds are core system architectures that may replicate single-points-of-failure. That’s because, at its core, the cloud infrastructure ecosystem is not a terribly diverse environment. Only a few hardware and software companies rule the roost. Similarly, ask your cloud provider to completely open their architecture and software kimono and let you examine everything. If they won’t, then you caveat emptor. If they will, you can judge their redundancy steps for yourself. So ask for specific architecture diagrams if you are going to be dependent on a cloud environment and its reliability. And get a network engineer or system architect buddy to review the diagrams. Think this is overkill? Ask FourSquare, Reddit and the other huge sites that have corporate backing or VC money and went down hard in the EC2 outages.
Pick code that’s easier and faster to modify. Not all runtime environments and frameworks are alike. Certain flavors and types of frameworks and Web scripting environments are more difficult to change in a pinch due to the core architecture of the way the scripting language works. Until recently, PHP was far harder to clean up than RoR, and Python, pre-Django, was more unwieldy.
The most popular code may not be the cheapest code. Think about the availability of coders. Many applications companies have a horror story about how their iOS app needed modifications and they either had to pay a high-end dev shop $ 200 per hour or had to wait for weeks to make the mods. At the same time, some runtime environments like Node.js can be built with Javascript code throughout the application stack. (We’re biased as we are strong backers of Node.js). That means you eliminate the need for differentiated front- and back-end coding teams, in a best case scenario. When building your cloud app, think hard about the code selection before you start filling up your GitHub repository.

By no means are these five steps comprehensive. And for the most part they are obvious. But in the cloud things move pretty quickly and sometimes slowing down to think about what your cloud application will be in six, 12 or 24 months is hard to do. So put on your crash helmet, watch your wallet, and be careful out there, people.

Alex Salkever is Director of Product Marketing at Joyent Cloud (@Joyent). He was formerly a technology editor at BusinessWeek.com.

Image courtesy of Flickr user kreg.steppe.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.