8 Comments

Summary:

Two weeks ago, Google announced a significant price increase for use of its App Engine Platform-as-a-Service. With vendor lock-in comes vulnerability to price increases. And for developers and app makers, this drastic shift may have been a “bet-the-company” decision without ever realizing it.

Master Lock

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:

  1. 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.
  2.  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.
  3.  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.
  4. 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.
  5. 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.

  1. Great post. OutSystems has been talking about the dangers of Cloud vendor lock-in for quite a while: http://www.outsystems.com/cloud/

    Share
  2. Interesting analysis. would sites like ercado (which uses facebook platform) gets affected? http://www.ercado.com

    Share
  3. You can’t relate to “cloud lock-in” as only on PaaS. Cloud Computing includes also IaaS and SaaS and the lock-in aspects can be way different than what you describe. I suggest you to go to >>> iamondemand.com<<< and read the a deep analysis of cloud lock-in relating to each layer specifically and basing statements on real cloud cases and interviews with leading market vendors.

    Share
  4. Totally right that lock-in can be anywhere in the ecosystem – not just PaaS. Its just that people at SaaS don’t think about cloud and people at IaaS explicitly know about the lock-in. At PaaS, its a lot more murky.

    Share
  5. 1. Understood.
    2. Any suggestions for installable PaaS options?
    3. Are there specific architecture diagrams in the public domain?
    4. What flavors and types of frameworks and Web scripting environments are more difficult to change in a pinch? What by nane do you recommend that we avoid/embrace?
    5. What is better thanNode.js?

    Share
  6. One strategy you did not mention is to use W3C standards for your entire stack. If you stick with XForms on the client and XQuery on the server (the XRX architecture) you have a lot more flexibility about where and how you deploy.

    Share
  7. Great article Alex. Glad to see you’ve got your head in the clouds. The next major frontier for cloud is in the broker role and the value proposition is arbitrage. What are cloud architects doing to enable agility, so that their cloud consumers can benefit? PaaS is especially tricky doe to the inherent lock-in to a application architecture and technologies. But it can be resolved with selection of standards based technologies and thoughtful architecture.

    Share
    1. I Am OnDemand Monday, October 10, 2011

      Mark – I am not sure why do you think that the article is so great. In regards to PaaS lock-in picking the right technologies is one of the issues. I find that the major discussion is that the open source world that already put its heavy foot inside the cloud world and put the traditional software platform giants in risk.

      Share
  8. 5 ways to protect against vendor lock-in in the cloud http://t.co/PSI9Yq9q

    Share
  9. RT @adron: 5 ways to protect against vendor lock-in in the cloud http://t.co/PSI9Yq9q

    Share

Comments have been disabled for this post