Cloud lock-in: Google comes back at App Engine criticisms
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.