"GAE" redirects here. For the airline, see Grand Aire Express.
Google App Engine is a platform for building and hosting web applications on Google servers. It was first released as a beta version in April 2008. During its preview release, only free accounts are offered.[1] According to Google, a free account can use up to 500 MB of persistent storage and enough CPU and bandwidth for about 5 million page views a month. Google has also indicated its intentions to provide additional resources for purchasing in the future. The engine enables creating databases (called datastores) and managing users, among other things. The user subsystem is an extension of Google's own. Users sign on to the App Engine by logging to their Google accounts. Applications created do not concern themselves with the creation of users, managing user data, password recovery, etc. The engine also frees the developer of the application from having to deal with user security. This lowers the barrier to entry for new users of an application, removing the need for each user to register with any given App Engine site. The service competes with Amazon Web Services, a set of application services that enable web sites to host files and execute code on Amazon's servers. Many tech analysts have been predicting Google's entry into this field for years. "Google finally realizes it needs to be the web platform," Techdirt publisher Mike Masnick wrote. "The easier it is to develop and deploy highly scalable web applications, the more innovative and creative solutions we're going to start to see."[2] At its launch date, the only supported programming language was Python, as well as a limited version of the Django web framework. Google has indicated an intention to support more languages in the future.
Differences from traditional application hosting
Unlike more traditional virtual-machine setups such as Amazon's EC2, Joyent's Accelerator, or Slicehost's Slices, AppEngine is a tightly controlled and tightly integrated product that places many restrictions on users. While others allow for the installation and configuration of nearly any *NIX compatible software, AppEngine requires developers to use Python as the programming language and "Datastore" - a version of Google's proprietary BigTable - for data persistence. While most Python will run with few modifications on AppEngine (exceptions being anything that accesses the system or network), the datastore presents a more radical departure from what most programmers are used to using. Scalability Benefits Gained From Removing JoinsGoogle App Engine has a SQL like syntax called GQL. Select statements in GQL can be performed on one table only. GQL does not support the join statement on purpose. Some people would believe this to be a detriment to the app engine. However, one to many relationships and many to many relationships are simple using ReferenceProperty().[1] This shared nothing approach allows disks to fail all they want without worrying about the system failing.[2] The where clause of select statement can do >, >=, <, <= operations on one column only. Therefore, only simple where clauses can be constructed. Switching from a relational database to the datastore requires a paradigm shift for developers when modeling their data. App Engine currently limits the maximum rows returned from an entity get to 1000 rows per datastore call. Most web database applications use paging and caching anyway, hence they don't need this much data all at once, so this is a non issue in most scenarios. Enterprise queueing and task scheduling applications are not good candidates for usage with google app engine currently. Both queueing and task scheduling are heavily requested features by users of the app engine to google for future releases.[3] App Engine does not allow users to back up their databases with a graphical user interface they have not written. Unlike MySQL and PostgreSQL (two of the most popular open-source database systems), the Datastore API is not relational in the SQL sense. This is likely because Google intends AppEngine applications to scale without any intervention from the developer and database joins can often run in O(n2) time. By eliminating the possibility of developers using costly joins, it becomes more likely that the application will scale. At the same time, such a restriction might make it more difficult for junior developers to develop an application and provides the impetus for junior developers to use alternative services. RestrictionsGoogle's AppEngine environment allows developers to control a small subset of what could be done on a traditional *NIX based operating system and presents challenges to application development. Developers have no access to the filesystem on AppEngine. Rather, the only way to persist data is in the Datastore (a non-relational, highly scalable database). This also means that most session storage systems that rely on the filesystem will not work on AppEngine. However, Google has provided a Memcache API that allows applications to store user data across requests during sessions. Google's documentation also suggests developers build in Google Accounts authentication and use the get_current_user() method to track logged in users. AppEngine can only execute code called from an HTTP request. This means that persistent processes or batch updates that take longer than a few seconds cannot be executed. This has been seen as curious by some developers who have noted Google's large use of MapReduce, a highly-scalable system of running parallel computations over large data sets using clusters of computers. Many have speculated that once the free quota restrictions are lifted, Google will introduce support for such operations. Python is currently the only programming language available, but people have speculated that PHP and Java will be supported before AppEngine leaves its preview phase. Scalability Restriction In theory, Google claims App Engine can scale nicely. But Google currently places a limit of 5 million hits per month on each application. This limit nullifies App Engine's scalability, because any small, dedicated server can have this performance. Google will eventually allow webmasters to go beyond this limit (if they pay). May 28, 2008 GAE pricing was announced: free to get started (with usage limits), fee if over the limit. And two important modules added. References
External links
| | |||||||||||||||||||||||