Can Google App Engine compete in the enterprise?

Google (s goog) has killed its App Engine for Business offering,┬áthe enterprise-friendly version of its Platform as a Service that included a partnership with VMware around the Spring Java framework. Part of a bevy of changes to App Engine announced at last month’s Google I/O conference, the news went largely unnoticed in the shadow of major pricing adjustments. But the missteps with App Engine for Business are indicative of the types of challenges Google faces as it attempts to ready its PaaS service to compete with companies like Red Hat (s rht) and (s crm) in luring enterprise developers.

No more App Engine for Business

I spoke with Gregory D’alesandre, senior product manager for Google App Engine, who explained to me Google’s new approach to selling PaaS to businesses. In retrospect, he said, Google might have announced App Engine for Business too early — more than a year ago — before it had a chance to gauge reaction to some of its more-limiting features. The company’s “trusted testers,” it turns out, liked many of the features, but they didn’t like the idea of a separate offering or the fact that App Engine for Business locked down API access from outside the owner’s domain.

So, D’alesandre explained, many of App Engine for Business features have or will be rolled into App Engine proper, which Google actually will take out of “preview” mode later this year and make an official part of its Google Enterprise portfolio. D’alesandre said that SQL support, SSL encryption and full-text search, all parts of the App Engine for Business offering, are top priorities not just for the App Engine team, but for Google overall, and should be ready once the product loses its “preview” status. SQL support, he added, is particularly important because of its appeal to enterprise developers, but it’s a complex process incorporating it into a platform that wasn’t designed with SQL in mind.

App Engine also still will support Spring for developing Java applications, D’alesandre said, and Google is actively working with VMware to figure out the next steps to advance their cloud computing partnership even beyond Spring. Other features of the new, improved App Engine will be a 99.95 percent SLA and additional support options. D’alesandre noted that expanded Python support and some new API improvements are in the works, too.

Too little, too late?

What’s not clear, however, is whether enterprise developers will buy into the new App Engine or whether its existing hundreds of thousands of developers will stick with the platform once the changes finally take effect. The latter group will have to adjust to higher prices than they were paying in the “preview” phase, and the former group — notoriously wary of vendor lock-in — will have to contend with Google’s very specific set of technologies and coding practices. As The Register‘s Cade Metz explained in a recent in-depth look at App Engine, the platform is very proprietary and requires sticking to a defined set of best practices.

D’alesandre isn’t convinced the concerns around limited language support and proprietary technologies are dealbreakers. The way he sees it, owning the App Engine stack from servers up through APIs means Google can easily troubleshoot and optimize will full knowledge of all the components. As for language support, he sees benefit in providing deep sets of features for the languages it does support — Python, Java and Google’s own Go. It’s difficult to argue with his stance regarding languages considering that PaaS is notorious for being single-language-only and only has begun to break those chains recently in the forms of VMware’s Cloud Foundry (s vmw), DotCloud and Red Hat’s OpenShift . Google actually was ahead of the game by adding Java support relatively early on.

However, even D’alesandre acknowledged that he’s impressed with some of the PaaS offerings that have hit the market lately. If anything, timing might be critical for Google, which will need to get the production-ready App Engine into the market before any of the myriad other PaaS offerings gather too much momentum. I thought App Engine for Business was a formidable competitor when announced, but time and new PaaS launches — including from Amazon Web Services — have dulled its edge.

Software inferiority?

There’s also the issue of Google “outdated” architecture, as so described in a recent blog post by ex-Googler Dhanji Prasanna. He opined that while Google’s data center infrastructure is second to none, its software stack is aging and has become a hindrance in terms of performance and development flexibility. D’alesandre declined to comment specifically on Prasanna’s criticisms, but called him a “good friend” and “absolutely brilliant engineer” who “was looking for something different” than Google’s development culture.

On his personal blog today, IBM’s (s ibm) Savio Rodrigues offered a down-to-earth take on the debate over Google’s software stack. While Prasanna cites Hadoop and MongoDB (among others) as being superior to their Google counterparts MapReduce and MegaStore — a position that very well might be accurate — Rodrigues notes that “[c]ombining 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.”

Of course, he added, that Google’s strict adherence to its own code raises a big question: “how your enterprise needs will be prioritized against the needs of internal Google developers.”

We’ll discuss the potential potholes for PaaS at next week’s Structure 2011 event, many of which are exemplified by the questions surrounding Google App Engine. It’s still early enough in the game for Google’s strategy change to pay off, but it will require some serious effort to convince enterprise developers that Google’s approach to PaaS is worth buying into.

Image courtesy of Google.