Try our new research platform with insights from 80,000+ expert users
BO
Director- Technical Services at Soft Alliance
Real User
Top 20
Download
Shared drive allows for communication, collaboration, and documentation in our company
Pros and Cons
  • "I've found that all of the features are valuable, especially the shared drive and the ability for multiple people to use their documents at the same time."
  • "I think there's still a lot that can be done with Google Meet and the video conferencing part of it. It could be more dynamic in terms of what can be done with it."

What is our primary use case?

We use this solution for communication, collaboration, and documentation. We're using Google Business Starter. The solution is deployed on a public cloud.

There are about seven people using this solution in my company.

What is most valuable?

I've found that all of the features are valuable, especially the shared drive and the ability for multiple people to use their documents at the same time. If I share my Google Sheets, as I'm updating, other people can see the updates happening at the same time.

What needs improvement?

The main thing that could be improved is the pricing. It could be cheaper, especially for those in Africa where we have a high exchange rate.

I think there's still a lot that can be done with Google Meet and the video conferencing part of it. It could be more dynamic in terms of what can be done with it.

For how long have I used the solution?

I have been using this solution for about seven years.

Buyer's Guide
Google App Engine
May 2025
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: May 2025.
DOWNLOAD NOW
851,604 professionals have used our research since 2012.

What do I think about the stability of the solution?

It's stable.

What do I think about the scalability of the solution?

The solution is scalable.

How was the initial setup?

Initial setup was straightforward. On a scale of 1 to 5, I would give it a 4.

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

We pay the license yearly. It's about $6 a month, which is $72 a year per person, so it's about $500. 

I would give the pricing a 2 on a scale of 1 to 5. The pricing is really not bad. The kill is that my country's economy is causing problems. So with each passing day, our currency loses value, and it sort of looks more expensive each day.

What other advice do I have?

I would rate this solution 8 out of 10.

It is a good product. For someone looking to implement this product, I would advise them to go with it. It's better for people in a stable economy where their pricing is constant and they can predict what it will cost throughout the year.

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.
Flag as inappropriate
PeerSpot user
Darasimi Ajewole - PeerSpot reviewer
Software Engineer at Formplus
Real User
Download
Has very intuitive dashboards and it scales very well; documentation needs a lot of improvement
Pros and Cons
  • "Administering App Engine is simple; it has intuitive UIs and a very scalable app engine."
  • "The documentation and community are lacking for this product."

What is our primary use case?

A lot of services we offer are developed and hosted on App Engine,.

How has it helped my organization?

As a serverless platform, it saves the effort needed in provisioning and administering backend servers.

What is most valuable?

App Engine scales really well and It's very clear to know where you're at with App Engine, whether it's the total amount of memory you're using or the number of instances being used by your application. 
Additionally, Administering App Engine from a user's perspective is simple with their very intuitive dashboards.

What needs improvement?

The documentation is an area that could definitely be improved. Another area of improvement would be the community which is poor and Google could do a lot better on that front. 

I know that my team members who have been working with the solution for just a year or two find the architecture to be quite difficult. 

For how long have I used the solution?

I've been using this solution for three years. 

What do I think about the stability of the solution?

The solution is stable, we've only had two disruptions in our three years of using this product. 

How are customer service and support?

We use a third party support partner of Google for our support. We're very happy with the service they provide and they have always managed to resolve our issues. 

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

I think the major difference between Google App Engine and every other similar product is its management. It's easier to manage App Engine than many of the other platforms that I've used. Google did a good job in terms of building a user interface so you can easily explain it to a non-technical person. It's just that the use case is very, very limited. Apart from web apps, you can't run other specialized applications on App Engine. 

If you're building a multi-threaded application on App Engine it's very tricky. For multi-threaded applications, I would go for something much more robust like Cloud Run or Cloud GKE, not App Engine.

How was the initial setup?

The initial setup was straightforward for me because I understand the App Engine architecture. I've heard from other developers that they find it very difficult to set up App Engine. For web applications, setup is very very easy and straightforward; for non-web or other special applications, setting up App Engine is challenging. 

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

We use the paid version under the standard environment and it's relatively expensive compared to other services.

What other advice do I have?

App Engine was built to handle a particular use case which is web applications and that's what it's good at. For applications running in containers or requiring Linux dependencies or applications requiring multiple processes, App Engine is not really your go-to product. You would choose a different solution for that.

I rate this solution seven out of 10. 

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
PeerSpot user
Buyer's Guide
Google App Engine
May 2025
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: May 2025.
DOWNLOAD NOW
851,604 professionals have used our research since 2012.
RN
Principal Technical Architect at NTT Security
Real User
Top 20
Download
The tool offers reliability and ease of management
Pros and Cons
  • "The product's initial setup phase was straightforward, considering that there is good documentation explaining the implementation part of it."
  • "The support for the Indian region is not as good as compared to the support that is offered to the regions in Europe."

What is our primary use case?

The type of platform my company generally uses for a project that needs no maintenance of any infrastructure for our customers and needs only Lambda functions is Google App Engine.

What is most valuable?

The most valuable features of the solution are reliability and the depth of Google App Engine's services, which are some of the reasons why I would like to give it a high rating when compared to AWS.

What needs improvement?

The support for the Indian region is not as good as compared to the support that is offered to the regions in Europe. My company faces a lot of problems with the support team, especially when Google's technical team is not able to help us immediately when we are stuck with something related to the tool. The support of the product is an area where improvements are required.

Google App Engine is a good product, and its support needs to be improved as it is a new technology that few people know about. There is a need to spread some awareness about the product while also ensuring that some online forums related to the product need to be updated with a lot of documentation related to the tool.

For how long have I used the solution?

I have been using Google App Engine for six years. My company has a partnership with Google.

What do I think about the stability of the solution?

I have not had any issues with the stability of the product.

What do I think about the scalability of the solution?

The scalability of the product is fine.

Around 1,500 customers of my company use the product.

How are customer service and support?

I rate the solution's technical support in India a five out of ten.

How would you rate customer service and support?

Neutral

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

In comparison to other solutions offering similar functionalities, I can say that I have not found any issues with Google App Engine. Google App Engine is at par with the best solutions in the market.

How was the initial setup?

The product's initial setup phase was straightforward, considering that there is good documentation explaining the implementation part of it.

Initially, our company invested time in understanding the entire product. My company went ahead with the PoC phase based on the briefing we received from Google's team, after which we went ahead with the production part.

The solution can be deployed in fifteen days, though Google had claimed that the process might take a month.

A lot of people, including developers and Google administrators, were involved in the product's development process.

What other advice do I have?

The use case where the product has significantly improved the development was attached to one of the scenarios where one of our company's customers wanted a tool to deal with continuous integration and deployments in the infrastructure. In the aforementioned scenario, my company used Google App Engine to deploy an infrastructure for our customer, and the product helped solve a lot of problems, reducing the time required to complete the project by half.

Google App Engine has supported the need for scalable applications for our company's customers since whenever the tool was used, it used to get integrated with a lot of new technologies, like Chef, Puppet, and with some of the APIs, after which my company was able to deploy the product on an on-premises model for our customer.

The feature of Google App Engine that I found to be the most essential for workflows is the high availability and scalability.

The serverless aspect of Google App Engine has benefited our company's customers since it has reduced the time required for the implementation of their applications. The tool also has been able to solve conflicts between developers and the people in operations. The tool offers the convenience of time and ease of implementation, which has improved and solved a lot of problems. The bug-fixing process in the tool is very fast compared to the manual thing.

The product does not require any maintenance.

The advantages of the product revolve around the fact that it offers a lot of depth, ease of management, scalability, and is fast. Developing and hosting applications is possible with Google App Engine. Google App Engine is more beneficial for those who deal in e-commerce.

I guess Google App Engine is a very good tool for infrastructures or when you need some machines that work twenty-four hours, seven days a week. Google App Engine is like a FaaS tool for its users, so users don't need to maintain any infrastructure, thereby drastically reducing their costs. Google App Engine is a very user-friendly, accessible, highly scalable product that allows users to opt for a pay-as-you-go model.

I rate the overall tool an eight out of ten.

Disclosure: My company has a business relationship with this vendor other than being a customer: Partner
Flag as inappropriate
PeerSpot user
FI
Teaching Assistant at a government with 201-500 employees
Real User
Download
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. 

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.
Flag as inappropriate
PeerSpot user
Francis Ikemenanwa - PeerSpot reviewer
Francis IkemenanwaTeaching Assistant at a government with 201-500 employees
Real User
Report as inappropriate

My appreciation to IT central station for this wonderful opportunity.

Like(0)Reply
it_user195504 - PeerSpot reviewer
System Programmer at a non-profit with 201-500 employees
Vendor
Download
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.
Flag as inappropriate
PeerSpot user
RK
Developer at a media company with 51-200 employees
Real User
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: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
PeerSpot user
it_user7527 - PeerSpot reviewer
CTO at a media company with 51-200 employees
Vendor
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: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
PeerSpot user
it_user7524 - PeerSpot reviewer
Developer at a manufacturing company with 10,001+ employees
Real User
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.
Flag as inappropriate
PeerSpot user
it_user4401 - PeerSpot reviewer
it_user4401Developer at a transportation company with 1,001-5,000 employees
Vendor
Report as inappropriate

You are right, I can deploy Java, Python or Go based web applications. Related to this topic, do you know which JVM languages I can use in my App Engine application?

Like(0)Reply
Buyer's Guide
Download our free Google App Engine Report and get advice and tips from experienced pros sharing their opinions.
Updated: May 2025
DOWNLOAD NOW
Product Categories
PaaS Clouds
Buyer's Guide
Download our free Google App Engine Report and get advice and tips from experienced pros sharing their opinions.
Buyer's Guide
Google App Engine
May 2025
DOWNLOAD NOW
Quick Links
Learn More: Questions: