IT Central Station is now PeerSpot: Here's why

Google App Engine OverviewUNIXBusinessApplication

Google App Engine is #12 ranked solution in PaaS Services. PeerSpot users give Google App Engine an average rating of 8 out of 10. Google App Engine is most commonly compared to Amazon AWS: Google App Engine vs Amazon AWS. Google App Engine is popular among the large enterprise segment, accounting for 69% of users researching this solution on PeerSpot. The top industry researching this solution are professionals from a financial services firm, accounting for 26% of all views.
Buyer's Guide

Download the PaaS Clouds Buyer's Guide including reviews and more. Updated: June 2022

What is Google App Engine?

Google App Engine is a Platform-as-a-Service (Paas) provider that equips web application developers with all the resources and tools that they need to develop, test, and run their applications on Google's infrastructure. Everything is built into the kit, so with one download of the SDK, you'll be well on your way to first-rate apps.

Google App Engine Customers

Khan Academy, Best Buy, Gigya, MetOffice, Getaround, Mimiboard, NewsLimited, WebFilings, and CloudLock.

Google App Engine Video

Archived Google App Engine Reviews (more than two years old)

Filter by:
Filter Reviews
Filter Unavailable
Company Size
Filter Unavailable
Job Level
Filter Unavailable
Filter Unavailable
Filter Unavailable
Order by:
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Showingreviews based on the current filters. Reset all filters
Francis Ikemenanwa - PeerSpot reviewer
Teaching Assistant at a government with 201-500 employees
Real User
Ability to test before deployment and security authorization are key features
Pros and Cons
  • "Seurity features - unauthorized individuals are unable to access certain applications."
  • "Difficult to assess how pricing is managed."

What is our primary use case?

This solution is a model for us right now, and I'm using it with my classmates. We are resellers. I'm currently a Masters student and teaching assistant. 

What is most valuable?

The most valuable feature in the solution is basically the security where you're required to use the AIP to initialize the accessibility process. It means that unauthorized individuals are unable to access certain applications. Mostly it is based on the workplace environment. Testing deployments is also a valuable feature as it enables you to test your app before you deploy on cloud.

What needs improvement?

Everything so far has gone smoothly, I've never had a struggle with the solution.  In terms of product improvement, when it comes to billing, I think they should include something that would give the client or user an indication of what's happening so they can be aware of how pricing is being managed. 

For how long have I used the solution?

I've been using this solution for the past few months. 
Buyer's Guide
PaaS Clouds
June 2022
Find out what your peers are saying about Google, Microsoft, Amazon and others in PaaS Clouds. Updated: June 2022.
608,010 professionals have used our research since 2012.

What do I think about the stability of the solution?

It's a stable solution. 

What do I think about the scalability of the solution?

I think it's a scalable solution. because basically you can add the amount of storage you want. When it comes to bugs, mostly there are no errors. It has happened, but rarely although I do think a little bit of improvement could be made in that area. 

How was the initial setup?

Initial installation is very straightforward, it takes no more than 45 minutes. 

What other advice do I have?

This solution is cheaper and more efficient compared to other similar solutions with cloud vendors.  I would rate this solution an eight out of 10. 

Which deployment model are you using for this solution?

Public Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.
OnyaToochukwu - PeerSpot reviewer
CEO/Programmer at Tech Elight
Real User
An easy to deploy solution that's scalable and not too expensive

What is our primary use case?

We primarily use the solution for business purposes for our clients. We develop software.

What is most valuable?

The solution allows you to create apps right on Google.

What needs improvement?

It would be helpful if they could improve the user interface. It could use some modifications.

There needs to be more directions in terms of how to use the solution.

For how long have I used the solution?

I've been using the solution for five or more years.

What do I think about the stability of the solution?

The solution is mostly stable.

What do I think about the scalability of the solution?

The solution is scalable.

How was the initial setup?

The initial setup is okay. It's not too complex. Deployment took about one day.

What about the implementation team?

We handled the deployment ourselves. There were four of us, including a back-end developer, a front-end developer, and an HR manager.

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

The pricing is okay. It's not too expensive.

What other advice do I have?

I'd rate the solution ten out of ten.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Buyer's Guide
PaaS Clouds
June 2022
Find out what your peers are saying about Google, Microsoft, Amazon and others in PaaS Clouds. Updated: June 2022.
608,010 professionals have used our research since 2012.
IT Manager Assistant at Aras
Real User
Good product functionality with an easy, simple setup process

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.

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 technical 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: I am a real user, and this review is based on my own experience and opinions.
Juan Pereigua - PeerSpot reviewer
Personal docente at U.E.N Aime Bonpland
Real User
Its ability to integrate with most devices helps users who have different or old devices

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: I am a real user, and this review is based on my own experience and opinions.
it_user195504 - PeerSpot reviewer
System Programmer at a non-profit with 201-500 employees
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: I am a real user, and this review is based on my own experience and opinions.
Richard Kiss - PeerSpot reviewer
Developer at a media company with 51-200 employees
Real User
Good-bye App Engine
I’d been running my web site for comedians 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: 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 domain, the Google domain that supports SSL for free (signed with a Google SSL certificate). Then I realized, I could just write a tiny Google App Engine app that proxied requests to by fetching content from 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: I am a real user, and this review is based on my own experience and opinions.
it_user7527 - PeerSpot reviewer
CTO at a media company with 51-200 employees
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.


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.


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: I am a real user, and this review is based on my own experience and opinions.
it_user9309 - PeerSpot reviewer
Consultant at a tech company with 10,001+ employees
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 ( 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 ( 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: I am a real user, and this review is based on my own experience and opinions.
it_user9231 - PeerSpot reviewer
Architect at a computer software company with 501-1,000 employees
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 -!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 -
Disclosure: I am a real user, and this review is based on my own experience and opinions.
it_user8361 - PeerSpot reviewer
Developer at a tech services company with 51-200 employees
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 -

-- 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:

Disclosure: I am a real user, and this review is based on my own experience and opinions.
it_user7629 - PeerSpot reviewer
Consultant with 51-200 employees
3 reasons I would choose to use AppEngine

There are 3 reasons I would choose to use AppEngine
1. Software is super simple and working with servers in the future is a no go.
2. Software is going to have 100+ millions users overnight. Will still need to be tweaked and optimized to handle the traffic on AppEngine. I have never seen anyone with this crystal ball but who knows you may have one.
3. Google integration is at the core of the software. AppEngine is really easy to do things like authentication with a Google account. Using Google storage or say the Google SQL service would greatly benefit from the software running inside the Google network.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
it_user7533 - PeerSpot reviewer
Developer at a tech vendor with 51-200 employees
Real User
The hidden cost of Google App Engine

Google App Engine's pricing model costs me way more than the small amount of money I'm charged every week. It costs hours of time.

Now what do I mean by that. I love App Engine and use it every day, there is currently no faster way to get an experiment up and running. The pricing model sounds great: Pay only for what you use. But without realizing, that this model can take giant tolls on development time, it will. At least if you have to care about money.

The problem develops as follows:

1. You have a great new feature to implement.
2. You design a rough implementation, that will get it working asap.
3. You notice a few unnecessary datastore/bandwith/cpu calls/bytes/hours (which AppEngine charges for), that might cost you thousands, if the first few million users hit your site on launch day...
4. But no worries, this can be solved with a slightly redesigned data-model. Go back to 2.

All the momentum you can build up with GAE (setting up a new project in about 5 minutes) can be destroyed in this vicious circle.

Maybe this is common knowledge, but if you are like me, try this:
Ignore everything you know about GAE optimizations and get your feature implemented.
If, one day, millions of people should hit on your site, be happy, pay a higher bill that month and start optimizing.

This should apply to a lot of "Pay as you go" - models out there.

Again, maybe this is just me learning obvious stuff, but this mindset saved me hours, and saving time is great.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
it_user7524 - PeerSpot reviewer
Developer at a manufacturing company with 10,001+ employees
One of the first PaaS solutions around and still one of the best

One of the first PaaS solutions around and still one of the best, Google App Engine is a solid choice to launch your next app idea. You can deploy Java, Python or Go based web apps and enjoy a variety of free and low-cost add-ons.

If you want a mostly-static website with some dynamic content, strongly consider the webapp2 framework. It is light-weight and easy to learn. With just a few lines of Python code, you can deploy an app that can serve a website, provide database backed storage, send emails and make HTTP requests. If you want to go enterprise, it is rare to find a Spring compatible hosting service for cheap, let alone free, but here it is.

One thing that App Engine can do better than any other free service is send emails. If your app needs to send emails, I would strongly consider App Engine. As if that is not enough, your app can actually receive e-mails as well. You can also send and receive instant messages using the XMPP protocol. If your users likely have a Google account, you can authenticate them and consume other Google APIs with ease.

If your website gets incredibly busy you have the option to scale up the performance of your website and pay a small fee. For example, a single massive burst to your site may cost you $0.50 –  $1.00. A constantly busy site will cost you more. You have complete control of the billing and can set quotas and alerts. Unlike the other PaaS services, pricing ramps up gradually as your traffic increases.

If your website is not very busy then there is a down-side: Your website may pause for a couple seconds the first time someone accessess a page after it has been idle for some time. In the grand scheme, this is a very minor point, but it is present. Also, signing up for App Engine requires you to authenticate your identity by receiving a text message. Once confirmed, you can deploy a website in about 30 minutes.

  • Pros: three languages, database support, excellent email sending, Google integration
  • Cons: Performance can be poor on idle websites, signup requires a text message

Checkout the 5 minute tutorial or sign up.

While Google’s App Engine has a more linear price curve as your app grows in popularity, I have to give creds to Heroku for making pricing simple and clear.

Which to choose?

  • If you want a static website that showcases your open source involvement, use Github pages.
  • If you need a static website with geographic diversity and you don’t mind paying a very low amount, or if you need to host large amounts of data (like Videos or file downloads) use Amazon’s S3 service
  • If you want to host with PHP or you want a very generous PaaS solution and can tollerate unclear vendor support, use Openshift
  • If you want Ruby on Rails support use Heroku
  • If you are OK with Python support and/or you need excellent e-mail sending capability use App Engine
  • If you just don’t know what you want then use App Engine and see if it meets your needs. If it doesn’t, by then you’ll know what you do want and can pick the right tool.
  • Read the full post on my blog.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
Principal Consultant/VP of Technology
Easy to upload from IDE. ...

Valuable Features:

Easy to upload from IDE.

Room for Improvement:

Need a better documentation and tech support.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
it_user1158 - PeerSpot reviewer
Developer at a tech company with 51-200 employees
Overall a good and cheap platform with scalability support. Good for individuals and startups, but not suitable for heavy/large applications.

Valuable Features:

- A very good platform for those applications that store something and retrieve it back. - Google takes care of deploying the code to the clusters, monitoring, failover, and launching application instances as and when necessary. This takes a lot of the administrative work off the user. - Easy and cheaper (in the short term) - Unlimited scalabity to your application, and scales with demand. - GAE supports MySQL db as well. - App Engine doesn't provide you with the flexibility to use an equivalent service if you need to pick something else for your app.

Room for Improvement:

- Developers have read-only access to the filesystem on the Google App Engine. - GAE is not suitable for CPU intensive calculations. - You cannot produce a social graph using Google app engine. - Once you think of migrating out of the AppEngine world, you'll face a lot of problems. For example, having to change your code to use your own datastore, task queues, and other services. If your application is fairly large, this will be a very difficult process. - Since the backend is completely manage by Google, you don't have control over the environment your application runs in. - Apart from the free space and to build some "Hobby" websites, Google App Engine is not the place java guys should look in as Java is quite heavy on memory front.

Other Advice:

Overall a good platform for running small applications that basically deals with storing and retrieving data from backend. Since the backend is handled by Google, you get a scalable app platform, but at the cost of losing control over the backend environment. You cannot tweak the backend and you just have to leave with whatever Google has to offer.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
it_user981 - PeerSpot reviewer
Manager of Development at a tech company with 51-200 employees
A good application hosting option for short term, low budget startups

Valuable Features:

Zero maintenance cost for web servers Reliable for scalability Free basic account with limited quota for trial Suitable for startups with limited users and limited resources

Room for Improvement:

No filesystem access More expensive than the alternate options if a product/service has a lot of users Language support limited to Java and Python Database options limited to MySQL and Google data store

Other Advice:

I have been using it for a startup for over an year. Initially it was great, but with an expanding user base, it makes more sense to host my own servers.
Disclosure: I am a real user, and this review is based on my own experience and opinions.