Google Explains Why Its Cloud Service Is Different When It Comes To Lock-In

A Google engineer concluded on his Google+ page last week that a cloud platform can’t be built without some form of lock-in. That’s evidently true but there really is one main reason for making such a point. Google wants to show that it is not much different from its competitors when it comes to this hot topic with cloud customers.

The post by Google Engineering Director Peter Magnusson has to be read with a dash of skepticism. Magnusson does focus on the lock-in issue with Google App Engine (GAE), but he also uses the topic to show the difference between its managed services and the infrastructure as a service (IaaS) from a provider like AWS. He says without restrictions Google could not offer the service that it does. What they do try to do is offer alternatives such as from services like AppScale.

Reading into what Magnusson says, it appears that some customers are not accustomed to the restrictions that come with Google App Engine: The run-time environment is different and customers can’t make systems calls, write directly to the file system, or choose their own operating system.

In the end, Magnusson says that lock-in is inevitable for Google to offer the service that it does with GAE:

You can’t build an innovative platform without some measure of lock-in. For example, the Datastore is unlike any other NoSQL or NearSQL service or stack out there. It has multi-datacenter synchronous replication, cursors, distinct queries, projection queries, zigzag merge join, transactional tasks, automatic sharding/load balancing, managed secondary indexes, and multi-row and multi-machine transactions. Our developers don’t want us to dumb down those features to some lowest common denominator; they want us to build more features that leverage the unique underlying software systems.

GAE comparess to other PaaS providers such as Cloudbees, Heroku, and AppFog, acquired in June by CenturyLink.  Google abstracts the actual hands-on work of managing the infrastructure that is a hallmark of other services. That means there are certain aspects of Google’s app service that have to be restricted. These restrictions allow Google to take responsibility for a customer’s firewall, most denial of service attacks, viruses — the list goes on.

The upside, Magnusson argues, is that for most mobile and web apps, instances can be started quickly, allowing apps to scale fast. Google manages that scale and the problems that arise when, for example, an app has to be moved to another data center.

But the real problem are closed, custom APIs that lock customers into a proprietary platform. People on Twitter who responded to my question about the issue pretty much universally agreed that some form of lock-in is inevitable.

AWS was cited as an example of a lock-in service:

ThinkJar Founder and Principal Analyst Esteban Kolsky said minimizing lock-in comes with open standards, which are not as much a reality at this early stage in the market:

While in theory there is no lock in when using common standards, there are few organizations that are using them.

It is in the vendor’s best interest to build a certain amount of lock-in for their platform, else it would be too easy to leave and hard to predict revenues (based on the current models of licensing). If their revenues were to be based on pay-as-you-go/rent/use as the cloud promises (which we are starting to see in smaller vendors) then the issue of lock cannot exist, as renting power means you should be able to rent it from more than one vendor (again, mostly theory at this time – but is applies far more to platforms than to infrastructure, where lock-in still remains quite strong – see amazon v rackspace for an example).

There is also a small part of being in the user’s bests interest, so leaving is not so easy and they are not pressured, especially for IT.

So the issue becomes one of convenience for the user/vendor versus what the stakeholder’s best interests are – as with anything that is Enterprise Software.

The lock-in issue is always there for the cloud service providers. OpenStack is bound to have lock-in with the platforms emerging from the likes of Red Hat, IBM, Cloudscaling, HP and Rackspace.

Magnusson admits as much but says it is just too early in the game for standards to play a meaningful role. That’s one way to look at the issue.

And the position certainly supports the numerous vendors in the market that have learned to provide services for moving data and apps from cloud to cloud. These companies represent a growing ecosystem that will continue to thrive as long as the cloud vendors continue to focus on making interoperability a challenging feat even for the most sophisticated of customers.