By Clint Ecker
Last night at a Campfire One event at Google headquarters in Mountain View, a new service was announced called Google App Engine. Aimed almost squarely at the loosely-coupled Amazon Web Services, Google is betting that developers and startups will opt to host their applications in Google's cloud, taking advantage of Google APIs, and leveraging the nearly unlimited processing power and storage capacity of Google's servers.
In comparison, Amazon's offering is broken out into functional services. You can use Amazon's S3 storage solution by itself, or in conjunction with their computing capacity services, or with their payment service, fulfillment service, or queuing service. While Amazon's services are broad, generalized, and language/platform agnostic, Google's wager is geared exclusively towards web applications and the services developers require to make their applications run.
Google has built an infrastructure that allows developers to create web applications programmed in Python code and upload them to and run on Google servers. Developers are provided with a number of optional Google-related services such as an authentication service built on top of Google accounts, a fast datastore backend based on Google's BigTable project, and Google's infrastructure for delivering e-mail.
The Google App Engine currently only supports the Python runtime for running applications and supports any frameworks that speak CGI or WSGI (with a CGI adaptor). While individuals who are unfamiliar with Python may find this initial requirement a setback, there are a number of web frameworks compatible with the service to make their transition easier. These include Django, CherryPy, Pylons, and web.py. Although many of these work just fine, the App Engine does not support certain aspects of some of these. Most noticeably, Django's models are not supported due to the unique nature of Google's datastore. These have been supplanted with Google APIs for storage, authentication, and more. Google also provides some workarounds for applications that depend on Django database models to function, like a bridge for Django form validation.
Google has also provided its own lightweight web framework called webapp tailored specially for the nuances of AppEngine.
One of the sample apps provided by Google Oh, and by the way, all of this is free.. with certain constraints. During this limited trial, only the first 10,000 registered users will be allowed to participate. Once this period ends, the service will be open to the public, for no charge unless your application goes over the prescribed, hard-and-fast limits that cannot be overaged. These include a 1,000-result limit in queries and a few-second limit on how long your application can take to respond to a request. During this beta period, applications will be limited to 500MB of storage, 200 million megacycles/day CPU time, and 10GB bandwidth per day. The Google FAQ equates this to approximately five million pageviews a month. While these limits cannot be breached during the trial period, at some point in the future, overages will cost the developer money, most likely in a manner similar to Amazon's billing structure.
It's not all good...
The downsides to this program are fairly apparent. First, developers must write all of their code in Python. While Python is a great dynamic language with a robust standard library, and over 15 years of active development, there will be some prospective users who would rather deploy their code in a different language. Google reiterates several times within the documentation that Python is only the first of many, but that they are still in the process of considering other languages for use in the project at this time.
Perhaps the most blatant downside is being locked into Google's platform. Existing projects will have to be ported or written from scratch, and those that rely on traditional relational databases will probably have difficulty making the transition. Even more difficult would be transitioning your application to your own servers if you choose to leave Google's tender embrace. Once you've created an established application on top of Google's authentication service and stored all your data within the company's datastore, removing all this code and data and moving it to another location would appear to a be fairly onerous task.
Why would a developer want to deploy their application on Google's servers and within Google's constraints? First up, it allows you, the developer, to begin coding without having to worry about all the nitty-gritty issues involved with hosting, buying expensive hardware, and scaling your code. You'll also be able to integrate more closely with Google's services, which offers some advantages.
This sounds great to small developers with small sites, but what happens when your cool idea takes off and you've got thousands or millions of users? You'll be paying a lot of money to Google each month—with no easy way out. No matter how much your user base and technology is worth, almost no company will be willing to purchase your idea because of the high cost of migrating that code out of Google.
Everyone except Google, of course.
Although Google App Engine offers some clear advantages and lowers the barriers to entry for startups and independent developers, the potential for lock-in creates risks that could prove more costly in the long-term. The constraints of the service could make it look considerably less appealing than Amazon's more open-ended EC2 service. Without a clean glide-path for moving App Engine web applications out of Google's nest, developers with aspirations of large-scale success might be reluctant to adopt the service.
No comments:
Post a Comment