3 Comments

Summary:

Google App Engine’s engineering director, Peter Magnusson, took to Google+ on Tuesday to dispute a lingering reputation the company is trying to lock in developers with its PaaS offering.

Google App Engine engineering director Peter Magnusson has some good news and some bad news about his product. The good news: Contrary to its reputation among some people, Google isn’t locking anybody in by design. The bad news: In practice, it is kind of locking in developers, though.

Magnusson laid out his case in a lengthy Google+ post Tuesday morning in which he explains away lock-in as a case of necessary trade-offs. Essentially, he argues, you can either have access to the guts of the infrastructure and the flexibility — and operational effort — that comes along with that, or you can free yourself of those headaches by using someone else’s abstractions. If you’re using App Engine, that means you also get to use rad features such as Datastore and take advantage of Google’s know-how around things such as load balancing and fending off DDoS attacks.

With the right practices, portability is possible

Additionally, Magnusson writes, there are generic best practices developers can use to create applications that should be relatively easy to port between modern web application platforms. And, he continues:

“The stacks that these abstractions map to are replaceable by you. The Google Cloud Datastore is “just” another NoSQL/NearSQL solution and can be replaced by stacks such as MongoDB; memcache is memcache; MySQL can obviously replace Google Cloud SQL; and the language containers are mostly forward compatible with other containers. Significant portions of the client environment, such as NDB, are open sourced by us already. When we add new building blocks like the Go language, we open source the whole language.”

Want more proof? Magnusson points to Google’s partnership with open-source App Engine implementations such as AppScale, as well its work with Red Hat to bring the App Engine APIs to the JBoss and OpenShift platforms. Oh, and the rollout of the Google Compute Engine platform for users who really do want control at the infrastructural level.

The App Engine homepage.

The App Engine homepage.

Now here comes the “but …”

All that said, there is the cold, hard truth that running on a platform like Google App Engine (or, one could argue, almost any other cloud platform) inherently involves some degree of lock-in. Google does exit interviews with large-scale customers when they leave, and it has found the average time for them to successully move their application to a new platform is three to four months. “I would posit that this is not materially worse than any other public-cloud-to-public-cloud transition once you have a complex system up and running,” Magnusson wrote.

All biases considered, Magnusson does make some good points. I’ve argued essentially the same thing before about Amazon Web Services — it’s a matter of expectation lock-in more than technological lock-in — and it probably holds true for just about every Platform-as-a-Service and Infrastructure-as-a-Service offering around. You could technically rewrite an application for any number of similar database or storage services, for example, but it’s the parts you like about a particular provider’s service that are hard to replicate.

Even with an open source project like OpenStack, easy portability isn’t guaranteed. Yes, the underlying code and building blocks might be the same, but it’s the differences among OpenStack-based providers that makes a market. If everyone looked and functioned exactly the same, there would be no reason to consider anything other than Rackspace in the public cloud.

Beside, moving a serious application from one cloud to another will never be enjoyable no matter how architecturally similar they are. Although, management layers such as RightScale, Scalr or Enstratius (now Dell Multi-Cloud Manager) could help mitigate some of that pain, and the Cloud Foundry community is trying to make portability among Cloud Foundry instances, at least, relatively pain-free.

As with so many things in life, the “which cloud to choose?” debate really boils down to picking your poison. You can probably count on loving some aspects and hating others. But you’re also probably stuck with it for a while, so choose carefully.

Feature image courtesy of Shutterstock user Mopic.

  1. Reblogged this on ABCD of Cloud Computing and commented:
    Google defends, quantifies App Engine lock-in concerns

    Share
  2. This news on Gigaom add to
    Google News Hub ( http://www.hubsfeed.com/Google )
    More than 100 news about
    Google on the HubsFeed in last month.

    Share
  3. This entire argument is a symptom of the past (and PaaS) but not acceptable if cloud is to prevail. Cloud lockin is both a cause and result of an early cloud market. Small numbers of clouds, simple web apps made it easy to either migrate these using gen 1 tools, such as those listed, which required the app to conformed/modified to infrastructure or use Paas’s to build new apps that can only use specific clouds. Today, there are many new cloud providers, leading to an acceleration of commoditization, in turn forcing differentiation by launching new value-add services and instances. This coupled with broader business acceptance of cloud to support apps that range from simple to complex, now makes the debate over lockin a non-starter and unacceptable. With today’s new diverse cloud environments and hybrid cloud use cases e.g. HA/DR, Dev/test etc, be able to move and manage different apps on diff clouds is now the expected standard. For the cloud industry to scale, tools that forced apps to change to conform to each unique infrastructure just wont survive. There must be a new way of thinking that enables new and existing apps to move to one or more clouds such that each infrastructure can expose its unique best practices and dynamically provision the app and its interdependencies as is. Today, these Application-Defined Cloud Platforms exist.

    Share

Comments have been disabled for this post