Cloud lock-in: Google comes back at App Engine criticisms

Cloud lock-in: Google comes back at App Engine criticisms

Summary: Google says it's not company strategy to tie customers into its App Engine development platform but admits that with the cloud some degree of lock-in is inevitable.


Google has hit back at accusations of lock-in over its App Engine cloud development platform.

In a lengthy Google+ post entitled Lock in, what lock in?, Google engineering director Peter Magnusson last week said where lock-in is occurring, it's mostly unavoidable and not deliberate — and that Google is doing its best to minimise it.

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

According to Magnusson, Google knows precisely how long it takes to shift an application thanks to the exit interviews it conducts with large organisations that have decided to migrate off App Engine.

"We know very well what it takes: for a large application, it's about three to four 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," he said.

Magnusson argued that the sense of lock-in is partly illusionary and caused by restrictions in the runtime environment, which prevent developers from doing things such invoking system calls, writing direct to the file system or choosing an OS.

"These things might be doable with other platforms, especially infrastructure ones, but they are restrictions, not lock-ins to anything proprietary and non-portable," Magnusson said.

"These restrictions are there for good reason ... And restrictions are always portable."

He said software is always built on other stacks of software and hardware, which will leak into code to some extent, no matter how well abstracted those stacks are.

"But the main design principles of App Engine are generic," he said.

The answer is to use good practice in the design of your code, such as not assuming a local file system, or hard-coding to specific versions of operating systems or libraries.

Magnusson said restrictions in the App Engine programming model are only there to perform a number of tasks and undertake a number of measures, ranging from security to load balancing and patching, on behalf of customers.

"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," he said.

"Sure, some of the abstractions leaked into your design. But, they're just different from the other abstractions that would've leaked in had you used something else."

Whichever public cloud vendor you employ, Magnusson said, it makes sense to exploit the key features of the service to make the development of your core product as efficient as possible.

"Just structure your code properly. It's coding hygiene. If you're a CEO, CTO, or VP of engineering, your decision on lock-in should be: 'Can we refactor parts such that we could migrate everything in a three- to six-month timeframe, if we had to, without disrupting the business?'," he said.

Topics: Cloud, Enterprise Software, Google, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Worth reading the comments as well.

    It's worth reading some of the comments as well.
  • lock in

    An app like Microsoft office is just as much a lock in as the cloud. Anything you use, develop, and modify has some degree of log in. I distrust the cloud because the server owner has the control, not because there is lock in.
  • The distrust I have has more to do with

    the sudden disappearance of the Google App Engine. If Google abandons the App Engine, then migrating off of it will be necessary. Microsoft is less likely to abandon Office 365 or Azure and Amazon is also less likely to abandon its cloud offerings. Microsoft's Azure can run any server with any application, and could be migrated to Amazon's, as they offer the same possibility. Whereas, Google is more of a lock-in than the others.