Google App Engine: Lock in, what lock in?

Peter Magnusson is Google’s engineering director for App Engine

On occasion I encounter the argument that Google App Engine is a proprietary platform, which implies lock-in, which many developers consider a Bad Thing. I’d like to address that complaint.

The argument I will be making is this: it’s not as true as you think, it’s mostly unavoidable, and it’s not our strategy – in fact we actively work to minimize it.

It’s not as true as you think

Let’s acknowledge the problem outright: if you develop an application on App Engine, it will require some work to move it somewhere else.

My first “yes, but” to this is to note that there is a bit of an illusion going on. If you’re new to App Engine, you probably feel a sense of lock-in because the runtime environment is very different: it doesn’t allow you to invoke some system calls, write to the file system directly, choose an operating system, or listen to an arbitrary network port, to name a few fundamental ones. These things might be doable with other platforms, especially infrastructure ones, but they are restrictions, not lock-ins to anything proprietary and non-portable. These restrictions are there for good reason, as I’ll point out shortly. And restrictions are always portable.

Software is always built on top of other stacks of software and hardware. No matter how well abstracted, this will leak into your own code to some extent. But the main design principles of App Engine are generic – structure your code so that small front-end workers can respond to requests quickly, pushing longer-running tasks onto a queuing model; separate out short-lived data from long-lived data, and leave the former in memcache and the latter in a key-value store; don’t assume a local file system, because they scale poorly and fail often; don’t hard-code to specific versions of operating systems or libraries; etc. These are good practices for any modern system that strives to be scalable, reliable, efficient and easy to maintain.

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.

This is not just a theoretical argument. We sample thousands of developers every month to track our customer satisfaction ratings (to a statistical significance sufficient to catch daily variations), and the numbers are rock solid. But it’s important that our developers know that if they became dissatisfied, it should be reasonably straightforward to leave.

And it is.

We know this because we’ve had unhappy customers who have decided to migrate off App Engine (shocking). For every such large customer, we do an exit interview to determine exactly how we failed them – and we’re working hard to fix everything that comes up in these reviews. As a side effect of these interactions, we know very well what it takes: for a large application, it’s about 3-4 months of work. Nota bene: that’s for a large, at-scale application; 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.

Even if you did code to “standards”, the plug-and-play promise of standards aren’t here yet. Google supports standards – they are key to our success. But the cloud computing and big data areas are new and rapidly evolving.

It’s mostly unavoidable

Things in life have plusses and minuses.

The restrictions of the App Engine programming model allow us to do a laundry list of things on your behalf: you don’t need to worry about firewalls, most denial of service attacks, viruses, patches, network configurations, failover, load balancing, capacity planning, OS patches and upgrades (in particular security related), hardware upgrades or fixes, certification levels, most security issues, routing, etc.

Because the runtime is minimal for most web and mobile applications, we can start new instances real quick, so that your app can scale fast, and we can move your application to another datacenter when there’s trouble.

You don’t have to wire up supporting services like memcache, email, authentication, backups, SQL, logging, etc. They’re all there, preconfigured and ready to use when you want them.

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.

Engineering is always about trade offs. The more you use someone else’s abstractions, the more productive you will be, and the more tied your implementation will be to that platform. But guess what? You got more done. The platform did more work for you. Time is opportunity. Now when (not if) you rewrite your service/app, there will be less of it to rewrite, because the platform did more of the work, and it also guided you to a good structure. Sure, some of the abstractions leaked in to your design. But, they’re just different from the other abstractions that would’ve leaked in had you used something else.

Any good platform will result in this net effect. Namely: that it’s not trivial to migrate, but neither are you artificially locked in. With some work you can move somewhere else. That’s why we set our deprecation policy to one year: no matter what we do, you should have plenty of time to say bye-bye. That’s why we’re serious about our data liberation policy, too: your data should not be locked in.

Giving you options is, after all, one of the reasons we’re doing Google Compute Engine as well. In fact, we’re specifically investing in making it simpler for you to choose appropriate trade-offs between managed and unmanaged infrastructure.

It’s not our strategy

We do not want to lock you in. We don’t like lock-ins. We believe we can both build and run the best underlying stacks and infrastructure in the world. As a company, we disavow artificial use of APIs or Data Jails to tie customers down. Any APIs we design, we strive for them to be the simplest possible encapsulation of the underlying service.

But we go further than this. AppScale is a fully open source implementation of App Engine, and we partner closely with them. CapeDwarf is a Red Hat project to support App Engine APIs on JBoss and OpenShift, and we work closely with them too, as some of you have noticed. With JBoss, for example, Red Hat supports Datastore functionality using Infinispan, and our engineers have worked directly with them to develop a TCK for compatibility testing.

We actively direct customers to these partners. It’s good for them, but it’s good for us too: A false sense of lock-in simply blocks potential customers from trying us out. And once they try us, they generally like us.

Lock in, what lock in?

I think you’ll find it best to try to leverage key features with whoever is your public cloud vendor, so that you can be more productive in developing your core product. Just structure your code properly. It’s coding hygiene. If you’re a CEO, CTO, or VP of E
ngineering, your decision on “lock-in” should be: “can we refactor parts such that we could migrate everything in a 3-6 month timeframe, if we had to, without disrupting the business?”

If the answer is yes, that’s all you need to know. Choose a vendor that fits you best, and focus on your product.

The truth is that the public cloud market is a highly competitive business. That’s good for you.

Peter Magnusson is Google’s engineering director for App Engine. This post was initially published on his Google+ account.