Google boss on App Engine: Lock in, what lock in?
Engineering director Peter Magnusson offers rebuttal to PaaS critics, admits leaving could take 3-4 months.
Google’s Engineering Director has countered accusations of “lock in” on Google App Engine, the internet giant’s PaaS product.
In a lengthy entry on Google+, titled “Lock in, what lock in?”, Peter Magnusson outlined the company’s approach to the issue and provide a response to critics.
“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,” he wrote. “You can’t build an innovative platform without some measure of lock-in.”
This “trade off” between convenience and lack of portability is an inherent aspect of today’s PaaSes, said Magnusson. “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.”
However, he admitted that the process of untangling an app from Google’s system is no trivial task, and that larger applications this can take “about 3-4 months of work”, even with help from Google engineers. “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 added.
Magnusson went on to mention two third-party open source implementations of GAE: CapeDwarf, which we covered Monday, and AppScale. Google cooperate with and “actively direct customers” to both projects to remove any “false sense of lock-in”, he said.
His advice to those trying to reduce the cost of moving was as follows:
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 3-6 month timeframe, if we had to, without disrupting the business?” If the answer is yes, that’s all you need to know.
In many ways, Magnusson is correct in his assertions. Any good PaaS will abstract certain aspects of the stack by necessity, and it’s up to developers to make these easy to change later on.
That said, if Google were truly against lock-in, they would be taking a leading role in an effort to standardise PaaS APIs between providers, rather than complaining that “the plug-and-play promise of standards aren’t here yet”. While the CAMP spec may not have proven itself just yet, it suggests there is a desire to cooperate among much of the sector.
Until then, Magnusson’s claims that Google “disavow[s] artificial use of APIs or Data Jails to tie customers down,” are difficult to truly believe.
Photo by Genista.