An ex-Google employee recently expressed concerns about the antiquity of Google’s software infrastructure. This is the same software infrastructure underpinning Google’s App Engine. Learn more before your enterprise considers Google App Engine.
Engineer claims Google’s software infrastructure is obsolete
In a post explaining why he’s leaving Google, former Google Wave engineer Dhanji R. Prasanna wrote:
Here is something you’ve may have heard but never quite believed before: Google’s vaunted scalable software infrastructure is obsolete. Don’t get me wrong, their hardware and datacenters are the best in the world, and as far as I know, nobody is close to matching it. But the software stack on top of it is 10 years old, aging and designed for building search engines and crawlers. And it is well and truly obsolete.
Protocol Buffers, BigTable and MapReduce are ancient, creaking dinosaurs compared to MessagePack, JSON, and Hadoop. And new projects like GWT, Closure and MegaStore are sluggish, overengineered Leviathans compared to fast, elegant tools like jQuery and mongoDB. Designed by engineers in a vacuum, rather than by developers who have need of tools.
Prasanna argues that Google’s software infrastructure hasn’t kept up with alternatives developed in an open community forum.
Don’t take Prasanna’s statements as those of a disgruntled ex-employee. He writes that working for Google was the “best job I’ve ever had, by a long way”. Additionally, Prasanna had built up serious technical credibility, both within and outside of Google, especially in the Java arena.
As interesting as Prasanna comments may be, Google software infrastructure has little impact on your enterprise, right? Correct, unless you’re considering Google App Engine.
Google’s software infrastructure bleeds through Google App Engine
Google isn’t going to open source its back end software infrastructure. However, as the Register’s Cade Metz writes, Google’s software infrastructure is surfaced for enterprise usage through Google’s App Engine.
Google App Engine product manager Sean Lynch, who has since left the company, explains how Google exposes their internal software infrastructure to 3rd party developers and enterprises. Lynch states:
We decided we could take a lot of this infrastructure and expose it in a way that would let third-party developers use it – leverage the knowledge and techniques we have built up – to basically simplify the entire process of building their own web apps: building them, managing them once they’re up there, and scaling them once they take off.
Make no mistake, Google App Engine is a success with developers, with over 100,000 developers accessing the online console each month and serving up 1.5 billion page views a day according to Metz’s story. However, keep in mind the difference between success with developers versus success with enterprises.
Lynch stated that Google App Engine is a long term business focused on the enterprise space. Later this year, Google App Engine expects to exit of a three-year beta period and introduce enterprise class service level agreements.
Google App Engine started as a way to expose Google vaunted, to use Prasanna’s description, software infrastructure to third party developers. But it appears that the market has moved faster than Google’s internal users demanded.
Enterprises seek vendors whose core business is linked to the software platform they’re selling
I would propose that part of this gap between Google and outside technologies is driven by the fact that offering a cloud platform as a service is not core to Google’s business. This is why I’ve argued that commercial software vendors have little to fear from vendors that produce software primarily for their own use and then opt to secondarily open source the code. Unless and until the open sourced code is picked up by one or more vendors whose core business is tied to the project, enterprises will shy away from adoption.
Consider where Hadoop, first developed and open source by Yahoo!, would be if not for Cloudera and other vendors whose core business is linked to the enterprise success of Hadoop.
In the case of Google App Engine, a key question to ask is how your enterprise needs will be prioritized against the needs of internal Google developers.
While both user groups would share a set of feature requests, there are undoubtedly features that enterprises will seek that Google developers will not need. With both user groups vying for the next feature on their wish-list to be completed, will Google address the needs of its internal developers or third party enterprise? Keep in mind that revenue from projects that internal developers are working on will far outweigh revenue from third party enterprises through Google App Engine for the foreseeable future.
According to Prasanna, developers and enterprises can get more innovative, state of the art and high performance software infrastructure from open source projects that have replicated some of Google’s best ideas, like Hadoop or mongoDB, than by using Google’s software infrastructure itself.
Combining individual best of breed software building blocks into a cloud platform as a service environment that offers the functionality of Google App Engine, requires enterprises to do a lot more work than simply using Google App Engine.
Another alternative would be to consider a vendor whose business is tied to the success, or failure, of the cloud platform as a service offering. For instance, SalesForce.com, VMware, Red Hat, Microsoft, and IBM, to name but a few vendors, offer environments designed and built for third party enterprise use.
Keep these considerations in mind while evaluating Google App Engine, or any cloud platform as a service offering for enterprise use.