Google App Engine Reviews and Pricing - page 3

Try our new research platform with insights from 80,000+ expert users

IT Manager Assistant at Aras

Sep 25, 2019

Good product functionality with an easy, simple setup process

Pros and Cons

"The WhatApp feature is the most valuable."

"I am limited to sending a photo to five people. I want to be able to send a photo to many people, not just five."

What is our primary use case?

We are using this application for learning purposes.

How has it helped my organization?

It helps with my work and my customers.

What is most valuable?

The WhatApp feature is the most valuable.

The functional is good.

What needs improvement?

I am limited to sending a photo to five people. I want to be able to send a photo to many people, not just five.

Google App Engine

Free Report: Google App Engine Reviews and More

Learn what your peers think about Google App Engine. Get advice and tips from experienced pros sharing their opinions. Updated: June 2025.

857,028 professionals have used our research since 2012.

For how long have I used the solution?

I have been using the solution for about three years.

What do I think about the stability of the solution?

It is stable.

What do I think about the scalability of the solution?

We have one user on the app (me). I can download the app on my phone.

I plan to use the app more in the future.

How are customer service and support?

The technical support is good enough.

Which solution did I use previously and why did I switch?

I have not used another solution previous to this.

How was the initial setup?

The initial setup is simple and easy.

The deployment and implementation did not take a long time.

What about the implementation team?

The deployment was done in-house. I deployed it. I maintain it now.

What's my experience with pricing, setup cost, and licensing?

I would like to have more free application with it. Some of the applications, I am paying more for them. I think that they must be free.

Which other solutions did I evaluate?

I did not consider another solution.

What other advice do I have?

I have found it useful in my work and life.

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

Personal docente at U.E.N Aime Bonpland

Jul 16, 2018

Its ability to integrate with most devices helps users who have different or old devices

Pros and Cons

"Its ability to integrate with most devices helps users who have different or old devices."

"Data consumption of the device could be improved."

What is our primary use case?

This solution is very efficient and easy to use. It is easily integrated with the needs of each user without the having to go to a third party.

How has it helped my organization?

Each application we choose meets the needs of the organization. The applications are very interactive and their prices are very accessible to each user.

What is most valuable?

Its ability to integrate with most devices helps users who have different or old devices.

What needs improvement?

Data consumption of the device could be improved.

For how long have I used the solution?

One to three years.

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

Google App Engine

Free Report: Google App Engine Reviews and More

Learn what your peers think about Google App Engine. Get advice and tips from experienced pros sharing their opinions. Updated: June 2025.

857,028 professionals have used our research since 2012.

it_user195504 - PeerSpot reviewer

System Programmer at a non-profit with 201-500 employees

Jun 26, 2017

Allows you to test your development. The programming interface is not easy.

What is most valuable?

Free Tier is basic if you simply want to test your development or if are not sure whether the product you are trying to launch will be successful. Free tier is unlimited in time. Other platforms used to offer a one year Free Tier. This unlimited time feature lets you work without worrying about money. If you need to pay, you know you are getting traffic.

Being that Free Tier is getting better on other platforms. I think Google App Engine Free Tier will keep on beating its rivals.

How has it helped my organization?

It lets you forget about everything not related to development, while allowing great load variations.

What needs improvement?

The programming interface is not easy, but I can't talk deeply about it, as I have used a framework which hid the API.

I can't detail anything about GAE API, as I didn't use it. Nevertheless, I could have a look at it. I could especially look at what is related to its DataStore database, in terms of its keys or its ancestors.

It seems to be a totally different approach, compared to traditional SQL databases. The Web2py framework hides this complexity.

I searched for some information about how to use GAE API, both on official
docs, forums or books. The conclusion I took after these searches was this
API was not easy to use. And this reality was one of the reason why I
started searching for a framework that could hide GAE API. I have to
recognize this impression could be caused because of my previous work with
SQL related API -note that GAE is build upon a NoSQL database.

For how long have I used the solution?

I have used Google App Engine for three months.

What do I think about the stability of the solution?

I have not had any stability issues.

What do I think about the scalability of the solution?

I have not had any scalability issues.

How are customer service and technical support?

I did not need to use support.

Which solution did I use previously and why did I switch?

I didn’t have a previous solution. This was my first option, due to it being the only one with a real free tier.

How was the initial setup?

The setup was really straightforward thanks to the framework. It does not seem to be difficult.

What's my experience with pricing, setup cost, and licensing?

It has really competitive pricing when talking about low usage tiers, but prices rise quicker than other options.

Which other solutions did I evaluate?

I checked documentation about other solutions:

PaaS (Heroku)
IaaS (Amazon, Azure, and Google Cloud)

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

Developer at a media company with 51-200 employees

May 1, 2014

Good-bye App Engine

I’d been running my web site for comedians LaffQ.com in Google App Engine for nearly two years. Google App Engine seemed pretty neat when it first came out: it was the only free hosting service I knew of where you could deploy dynamic Python apps (using Django no less, a framework I was already familiar with) with the promise of Google managing the backups, scaling, and provisioning. But as time went on, the sunny optimism began to fade. Although Google supported Django, it uses a proprietary BigTable-backed database which was not compatible with Django’s object-relational wrapper (ORM). The originally unbelievably high free limits during the beta period which reduced drastically, in some cases absurdly, when the product came out of beta. Visiting my internal operations page just twice could blow out nearly the entire day’s quota because it produced counts of many tables — so each item counted towards a daily quota of 50000 “small operations”. Developing for Google App Engine was always a pain. It was non-standard enough that a lot of libraries and tools wouldn’t work or need annoying changes. There was a single point of documentation, written in a sort of corporate Google-ese — not horrible, but not the nicest documentation I ever read. There were a lot of layers of abstraction. It was proprietary. It was slow to fetch data. The pdb debugger didn’t work very well. Getting data out of production was an ordeal. It was even hard to launch a instance on the command line, which meant on those rare occasions when I decided to do development on my Linux netbook, I spent most of my time getting the newest version of Google App Engine to work again. I don’t exactly remember how or why, but late one Sunday evening in November I suddenly came up with the bright idea to port the Google App Engine infrastructure to “sqlite” (as I referred to it in my head), ie. to use the standard Django database back-end with the idea to deploy it to some unknown host using sqlite3. I started almost immediately, figuring at the very worst, it would just be an abandoned experiment. It turned out to be… well, if not “surprisingly easy”, remarkably painless. By Monday afternoon, I had gotten most of the core public functionality working just fine (insert show, edit show, delete show, list shows). The data model ported straight across with, one exception being a GeoPt latitude/longitude structure, which I simply reformatted into a string containing a comma-separated pair (which is was probably stored as in Google anyway). By 9 pm on Monday, my entire test suite was passing. The internal pages hadn’t been ported yet, nor the “post on Facebook” functionality. I decided to work on the non-critical internal pages first, or else I wouldn’t have any excuse to not deploy (and that’s scary!). I ported these components which gave the code base a chance to “set” (like Jello™) and time for that unease associated with massive changes to dissipate somewhat. Some changes that occurred more than once: - adding “objects” everywhere, so Model.get becomes Model.objects.get - changing Property to Field (ndb.StringProperty => models.CharField for example) - ndb.KeyProperty => models.ForeignKey - put => save - key.get. => key. - .query() => .objects - required=False => null=True - obj.key.delete() => obj.delete() - query.order => query.order_by - query.filter works very differently (no more fancy Google App Engine custom types based on operator overloading and deferred evaluation… fancy, but pretty opaque) On Tuesday, I started working on the automated posts to Facebook. Not much needed to change here, but it was a bit nasty as there were only limited automated tests for this, so I had to be very cautious. Somewhere along the line, I decided I would deploy on my unlimited Dreamhost account (promo code: “RICHARD_SHARES”), which costs about $9/month and already hosts a bunch of domains. There were a few gotchas in getting the wsgi configuration working with Django (and it was tremendously difficult to debug until I hit on this idea of marshaling the requests to a file, then invoking the server by hand using the marshaled request), but this was reasonably straightforward, and I had built a local installation of Python 2.7 in the past, so I reused that. I worked on the code to import the data. Google Data Export is another things that’s way too complex and slow, but I had done a trial run of the export on Sunday, so I used that as a testbed. I found some sample code to read the sqlite database (which is very simple) into Google Entity objects, so it was fairly simple to read properties out of the Google objects and put them into Django objects. I ended up doing it in two passes; the first pass included root objects that other objects have foreign keys to, which ensures that the second pass can refer to those already created objects without dangling foreign keys. I waited until midnight, so the daily stats would be generated on Google, with Google data, then immediately put the site into read-only mode on Google and began the dump of data from Google. It was infuriatingly slow. It finally finished around 12:42 am, so about 40 minutes total, to produce a 21 MB sqlite database file. Finally, one little file with ALL my LaffQ data in it! Here’s the script that converted the exported Google App Engine data to native Django objects in sqlite3: https://gist.github.com/richardkiss/4576523 I had already brought up the new site on Dreamhost, using two day old data, so it was just a matter of running the conversion tool, which read the Google sqlite database (which was essentially a BigTable dump, with one entity) and wrote out the Django sqlite database (which much more closely resembled the actual structure of data in my database). The new sqlite file was 8.7 MB. Compressed with bzip2, it was under 2 MB. That was the entirety of my web site data that took Google 40 minutes to export!!! I copied it to Dreamhost in about five seconds, deployed it, restarted the Django app, and poked around a bit. Everything seemed to be in order and up to date, so I update DNS to point to the Dreamhost version of the web site, and waited for the change to propagate around the world (it’s funny to think about how LaffQ came up at different times for different people). One thing I forgot is the Facebook integration required SSL. I didn’t have an SSL certificate (or a unique IP!) so I was flustered for a bit. I thought about how this used to work: it went to the laffq.appspot.com domain, the Google domain that supports SSL for free (signed with a Google appspot.com SSL certificate). Then I realized, I could just write a tiny Google App Engine app that proxied requests to https://laffq.appspot.com/ by fetching content from laffq.com. These pages are very low traffic (since they don’t really do anything), and it worked! (I had problems serving CSS to Chrome, which were resolved by making sure the content-type header was set correctly). I’m kind of glad I didn’t remember this until it was deployed because I didn’t see the answer right away, and it might have made me not go through with it due to my tendency to know every move in advance. All in all, the port went unbelievably well. The sqlite version is MUCH faster than Google even though memcache is no longer in the mix (I do use built-in Django caching in the same memory space as the Django app, although I’m pretty sure I could turn it off and it would still be very fast). It uses very little CPU on Dreamhost, and there are no annoyingly arbitrary quotas. Since then, my work on LaffQ has accelerated beyond my wildest dreams. I didn’t realize just how much the Google App Engine restrictions were holding me back. Now I can back up my entire production database in just a few seconds. I can run a copy of production database locally, which gives me a much better feel for how changes will perform with production data, so I use production data in development all the time. This gives me a much better feeling about new features. Debugging is much easier. Deploying is as simple as a git push/git pull. I can look at logs. I can make tweaks in production. I can ssh to the production machine. I can diagnose problems in production. Pretty much everything about it is better. I’ve refactored, tweaked, optimized, added tests. It’s code I’m almost proud of now. (Almost.) I saw on Hacker News the other day about how Google App Engine was down. I was happy it didn’t affect me.

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

it_user7527 - PeerSpot reviewer

CTO at a media company with 51-200 employees

Dec 15, 2013

The Problem with Google App Engine

Google App Engine is amazing, we got our prototype up and running in no time, and for no expense. We then decided it was the right platform to run a big part of our platform. We particularly appreciated the following features:

No sys admin needed.
Automatic scaling.
Amazing uptime (despite earlier reports)
Impeccable security credentials
Deploy scripts out of the box.
Clean well documented API.
Extremely flexible data model.
Great web UI management console.
Nice task queue (though this is perhaps to mitigate some of the limitations.
Carbon neutral

But the devil is as always in the detail…

As we have grown, so too has the impact of the limitations of app engine. Like many others we were surprised at the new pricing, but the analysis showed it would not be much more than a home grown solution, and we could still keep all the benefits. Here are some of the problems we have faced.

Domain and SSL.

Until TLS is supported more widely and app engine adopts that you cant have a custom HTTPS domain, you will have to do a bit of sys admin, and run a reverse proxy. Now you have just introduced a bottleneck, and depending on how you implement that possibly a single point of failure. So is you have two small VPS’s running behind some custom load balancer or DNS balancer to introduce some resilience – you have added an admin overhead and possibly another £30 per month.

Price.

We have grown, from nothing to a small startup, we have 20,000 registered users and 2,000,000 transaction records – not even approaching ’big data’

This costs us $5 per day or $150 a month

Detail of our daily cost

Map Reduce costs More

As we add more processing the number of reads will go up and sowill the price, in fact in some test Map reduce jobs show that if we ran a nightly analysis job on our transaction data set the price hikes by 50%. I’m only glad we dont have 14 million rows to process, cos we certainly dont have $6,500

Extracting data costs More and is SLOOOOWWW

We recently extracted the xact data set to look at processing them with other tools. The first effect of this was a further 25% hike in the daily price because of the increase in datastore reads. Worse than that though was that it took TWO DAYS to extract 2 Million records.

request hike over the two day extraction period

This alone makes it next to impossible to use App Engine as the main data store and extract data for processing. Work around – we ended up setting up a schedule that monitors any changes and pushes the changed data out to the processing servers. The price impact is minimal on GAE – the development time was not insignificant, and we now have another set of servers to manage and pay for.

Front End Instance Hours, Latency and Concurrency.

Prior to App Engine Team releasing support for python 2.7 last February there would be a linear relationship between the number of front end instance hours you needed and the the sum of your number of concurrent users * you average request latency / the latency you want your customers to experience.

So if you had 10 concurrent users, and you wanted their requests to return within a second, and your average request takes 500ms to do its thing you would need 5 front end instances: 10 *0.5 / 1 or if you did not mind them waiting 2 seconds you should aim for 3 instances.

Now the calculation is less clear, once you have enabled, and tested for or possibly redesigned for concurrent requests because the memory handling of each instance , and how its performance characteristics affects request latency whilst handling concurrent requests needs to be considered.

Even though you can control some aspects of instances, there still feels like there are some strange behaviours, why are our reserved instances not serving any requests but some extra (aditional cost) instances busy…

Idle instances

Now we are about to test on Python 2.7 I’ll report back on any cost savings.

General Performance and Design Compromise.

There are known considerations with respect to GAE’s big table-esq de-normalised design, and they really turn out to be not a major issue, storage is still cheap on GAE, though you will want to look at how the indexes are being constructed, thought the dev environment takes care of the default situation, in that if you ran a query on the development server during testing, that hist a field that field will be marked for index. In production you can’t limit by any field that is not in an index.

My biggest concern is simply how long it takes to return even slightly large result sets, we have seen 2 to 10 seconds just to retrieve 1000 rows!

1000 rows used to be the limit until cursors were introduced GAE always advised paging through result sets, but beyond 1000 rows the limit and offset approach becomes slow as well. With the introduction of cursors the 1000 row limit is gone, but using them could involve (as in our case) considerable re-factoring

One Alternative to App Engine for Comparison

As our need for more processing increases and we spent some time investigating what we could get done, so had a look at setting up a small MongoDB cluster that would be an architecture that would be robust enough to support our live app.

Instead of Amazons EC3 we plumped for Rackspace Cloud to run 6 small instances and a cloud load balancer…

2 App servers – 512 MB RAM, 20 GB Disk
4 Data servers – 1024 MB RAM, 40 GB Disk
1 Cloud load balancer.

The price – £14.60*2 + 29.2*2 + £7 for the load balancer – £153.00

We are actually using the two app servers for the main nginx proxies for Money Toolkit and 8 other processes, so the extra £123 for the mongo install is comparable with the $150 for GAE.

The 4 data servers were set up as a pair of replicated shard servers, and the app servers host the mongos routers and our own app server code, each with nginx proxies to better control routing to the app servers.

We got munin running across the cluster to see how things were going…

Spot the app server memory leak..

Munin illustrates our memory leak nicely

We wanted our own server to be as slim and performant as possible so that we could basically exclude that from any argument about bottle-neck so hacked together a json based restful web server in C and C++ using Mongoose. We chose Mongoose because it is pretty stable very flexible and can handle multiple concurrent requests only capped by how much memory you have as it runs a thread per concurrent connection. We configured each app server to have 20 threads – so we should easily be able to cope with 40 concurrent requests.

We coded against the C++ drivers for MongoDB on the backend.

With Mongo stubbed out (and with no in app memcache or other nginx caching) we could happily run a simple Apache Benchmark (ab) of 40 concurrent users returning over 5000 requests per second.

Running ab with a request that returns the full set of transactions for an individual account we see…

112 requests per second

There are a few anomalies - we got a few SL handshake errors (I think because of a limit we have in nginx), but the result is that each individual request takes 0.3s average and we can server 40 of those a second.

Each 40k request returned an array of just under 1000 json objects.

So with this simple setup we can easily server 112 queries a second before we even start thinking about memcache.

No More Paging

The results for larger documents – 30,000 rows showed we could return those within about 0.5 of a second.

Free Map Reduce.

We ran a simple Map reduce job to find the most popular vendors and average spend (MongodB now has aggregate queries built in) it took 2 minutes, and cost us nothing more, plus our request performance only dropped slightly – 100 rps.

Free and Fast data Import and Extract

Importing our 2 Million records (from our two day long CSV extract) – via one process took under 10 minutes (3,400 records per second), and a data dump – to CSV took around 5 minutes – so roughly 500x faster than GAE. both cost noting extra.

Summary

This was not meant as a fair like for like comparison, and the home-brew mongo install is kind of the exact oposite of what google app engine is. It was simply to highlight some fundamental limitations in GAE and how that necessarily affects design decisions, and illustrate one narrow alternative possibility for a similar monthly cost.

If you have a relatively simple app, small to medium sized app, with a reasonably static data model (deleting lots of records is also expensive) and say – less than 10 million records that do not require regular data processing and analysis then Google App Engine remains an incredible choice.

If your data is starting to scale and you really want to extract full value from your data by running analysis jobs and you need access to large-ish record sets during each request (like our case of synching full record sets to mobile devices) then Google App Engine is the wrong hammer for your nut.

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

it_user9309 - PeerSpot reviewer

Consultant at a tech company with 10,001+ employees

Sep 2, 2013

Google’s App Engine Available For On Premises Deployment.

The public cloud is a great solution to a wide selection of problems however there are times when its use is simply not appropriate. This is typical of organisations who have specific requirements around how their data is handled, usually due to data sovereignty or regulatory compliance. However whilst the public cloud is a great way to bolster your infrastructure on the cheap (although that’s debatable when you start ramping up your VM size) it doesn’t take advantage of the current investments in infrastructure that you’ve already made. For large, established organisations this is not insignificant and is why many of them were reluctant to transition fully to public cloud based services. This is why I believe the future of the cloud will be paved with hybrid solutions, something I’ve been saying for years now.

Microsoft has finally shown that they’ve understood this with the release of Windows Azure Pack for Server 2012R2. Sure there was beginnings of it with SCVMM 2012 allowing you to add in your Azure account and move VMs up there but that kind of thing has been available for ages through hosting partners. The Azure Pack on the other hand brings features that were hidden behind the public cloud wall down to the private level, allowing you to make full use of it without having to rely on Azure. If I’m honest I thought that Microsoft would probably be the only ones to try this given their presence in both the cloud and enterprise space but it seems other companies have begun to notice the hybrid trend.

Google has been working with the engineers at Red Hat to produce the Test Compatibility Kit for Google App Engine. Essentially this kit provides the framework for verifying the API level functionality of a private Google App Engine implementation, something which is achievable through an application called CapeDwarf. The vast majority of the App Engine functionality is contained within that application, enough so that current developers on the platform could conceivably use their code using on premises infrastructure if they so wished. There doesn’t appear to be a bridge between the two currently, like there is with Azure, as CapeDwarf utilizes its own administrative console.

They’ve done the right thing by partnering with RedHat as otherwise they’d lack the penetration in the enterprise market to make this a worthwhile endeavour. I don’t know how much presence JBoss/OpenShift has though so it might be less of using current infrastructure and more about getting Google’s platform into more places than it currently is. I can’t seem to find any solid¹ market share figures to see how Google currently rates compared to the other primary providers but I’d hazard a guess they’re similar to Azure, I.E. far behind Rackspace and Amazon. The argument could be made that such software would hurt their public cloud product but I feel these kinds of solutions are the foot in the door needed to get organisations thinking about using these services.

Whilst my preferred cloud is still Azure I’m still a firm believer that the more options we have to realise the hybrid dream the better. We’re still a long way from having truly portable applications that can move between freely between private and public platforms but the roots are starting to take hold. Given the rapid pace of IT innovation I’m confident that the next couple years will see the hybrid dream fully realised and then I’ll finally be able to stop pining for it.

¹This article (http://www.theregister.co.uk/2013/05/20/newvem_analytics_for_azure/) suggests that Microsoft has 20% of the market which, since Microsoft has raked in $1 billion, would peg the total market at some $5 billion total which is way out of line with what Gartner says (http://www.arnnet.com.au/article/455595/cloud_services_market_reach_us131bn_gartner/). If you know of some cloud platform figures I’d like to see them as apart from AWS being number 1 I can’t find much else.

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

it_user9231 - PeerSpot reviewer

Architect at a computer software company with 501-1,000 employees

Sep 1, 2013

Cloud Foundry vs Google App Engine

Over the past months I had some experience on the Cloud Foundry and the Google App. Engine. Below are my reviews on them, mostly on a developer perspective, not on performance or on cost. Another note is that CF is still in beta so it may seem a bit unfair comparison but as long the philosophy stays the same I think points I made will hold. Google App. Engine Appengine is the first one I tried to deploy. You have a nice web console to control your instances and application. Google offers you api's to replicate your data across instances. Google also offers you some nice api's like the Channel api which you may use as a serverside push. Cons; being an experienced Java developer I wasn't excited to the fact that I had to add an appengine.xml on my jar even though I wouldn't be using any service from Google. I discovered that Google does not give you access to some JDK classes, like the NIO stuff. So you can't just use/do anything you like. HttpSession's are not enabled by default, you have to enable it on your appengine.xml. Google apparently wants you to use it's own api's, DataStore stuff in particular. Once you are committed to Google it does not seem easy to move away from it. Lastly HttpSession.contextDestroy method does not get called, yet... So you have to do some more stuff like suggested here - https://groups.google.com/forum/#!topic/google-appengine-java/Tw2a8cYz05o . Makes me thing what else they have omited ? Cloud Foundry With cloud foundry you get tomcat instances. I configure/manage my apps using an ruby app. called 'VMC'. Community is helpful questions asked are answered pretty fast. It follows the Java standards. Rarely something thats working on my tomcat instance does not work within the CF. Provides services like Redis, MongoDB ... Cons are it's still in beta. You can't purchase instances yet. To access the services I had to use CF api though there may be other options that I don't know, anyway still it seemed less invasive than Google to me. Lastly Although CF is still in beta I believe it offers a better, non-invasive environment compared to GAE. Disclosure: The company I work for is partners with several vendors - http://www.innova.com.tr/en/innova-business-partners.asp

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

it_user4401Developer at a transportation company with 1,001-5,000 employees

Report as inappropriate

Oct 19, 2013

I think that the best feature of App Engine is that it provides application scaling for computer platforms. It automatically allocates both memory and power resources to meet the growing load, bandwidth or CPU demands. The projects are allowed to consume resources up to a limit quota for free; the additional resources are nonetheless chargeable. I also think that App Engine is a nice base for launcing low bandwidth projects with no money upfront.

it_user8361 - PeerSpot reviewer

Developer at a tech services company with 51-200 employees

Aug 3, 2013

Google Application Engine Review

Google Application Engine (GAE) is a cloud computing platform for developing and hosting web applications in Google-managed data centers.

-- Frameworks --

Google App Engine was written to be language independent, however it currently supports Google-friendly languages such as Python, Java, and JVM languages, as well as Go.

GAE supports most of the Python related frameworks (Python web frameworks) as well as Google-written webapp framework and some others.

-- Massive Scalability and Pricing --
The App Engine provides application scaling for computing platforms. I consider this to be its best feature because of ever increasing data processing demands. It automatically allocates both memory and power resources to meet the growing load, bandwidth or CPU demands.

Each Google Application Engine application can use a certain amount of computing resources for free, as defined by a set of quotas. With a low bandwidth for your application on the Google AppEngine platform, the cost is zero or close to zero. If your application grows to a point where it serves millions of requests a month, at that point you will probably generate enough money to afford the increased cloud framework demands. It’s free to start – very convenient for startups. The full GAE pricing info is available here - https://developers.google.com/appengine/docs/billing

-- High Replication Datastore configuration --

Since the beginning of 2011 Google Application Engine provides High Replication Datastore configuration under which to run applications in addition to the default Master/Slave configuration. This High Replication Datastore of the App Engine is for those developers who want the highest possible level of availability for their data and applications. Such an application in data centers configuration was made possible through writing increased latency and some changes in consistency guarantees in the API. The High Replication Datastore provides a high-level, 99.95% uptime Service Level Agreement. However for low cost or non-critical applications, one can use the initial Master/Slave App Engine configuration.
Developers’ Guide and downloads

The Developers’ Guides for both Python and Java can be found here. The SDK and AppEngine downloads can be found here. I started my first application with GAE within 5 minutes using the video as a guide.

-- GAE advantages over other application cloud hostings --

Google Application Engine’s noticeable advantage over AWS or Azure is that you are charged for only the time your application is handling requests (with minimum charged time span being 15 min). Compared to the competitors, GAE’s fees for application availability to handle requests are of lower degree. So if the traffic is low (like with a startup project or something similar), application owners do not have to pay much for it.

-- Summary --
Google Application Engine is a good cloud framework supporting JAVA and Python (Google’s favorite :-) ) web development languages. It’s a nice base for launching low bandwidth projects with no money upfront. The huge advantage of the Application Engine is the automatic resource scalability so that the application can grow. The projects are allowed to consume resources up to a limit quota for free; the additional resources are nonetheless chargeable.

The original post: http://extract-web-data.com/google-application-engine-review/

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

it_user3876Database Manager at a tech company with 51-200 employees

Report as inappropriate

Dec 21, 2013

In my opinion, Automatic CDN replication is the major advantage of GAE. Static content including image, CSS, JavaScript are automatically replicated all across the globe resulting in speedy transfer, routing time and latency.

Buyer's Guide

Download our free Google App Engine Report and get advice and tips from experienced pros sharing their opinions.

Updated: June 2025

Product Categories

Buyer's Guide

Download our free Google App Engine Report and get advice and tips from experienced pros sharing their opinions.

Google App Engine

Quick Links

Learn More:

Questions: