Google App Engine: love the pros and hate the cons.

Some users love App Engine others hate it. Why?
Sure, App engine have it poor and cons. You might love it or hate but it only depend what your trying to achieve.


Handle irregular traffic load

The feature every GAE users love is the automatic scaling. App Engine starts more servers when more users come. It also kill the extra server when traffic decrease, going as low a 0 server running.

We did an App Engine Load test who scale up form 0 server 180 servers in 5min.
Those servers was able to handle 3000 heavy query per second.

The most difficult and expensive things to build yourself: scaling
- Google App Engine

Pay for what you use

If you experience a massive traffic load who required 400 servers for one hour. You pay 400x one hour price $0.08 (September 2013). Maybe at nighttime you have no traffic at all. So you pay nothing during this time.

Same billing rules apply for the database use, emailing and other. You only pay for what you use.

Quick to get started

Everything is already configured and ready for development.
App Engine idea is to focus on code not on configuration and maintenance. The database (Google Cloud Storage) is ready to use. You don’t even need to configure a login/password. As it’s a NoSQL database no schema needed, it mean no configuration. Memcache is also up and running.

All the others products are configure and ready. You simply choose to use them or not from you code.

Free quota

App Engine give you kindly free quota renewed every day(September 2013):
- 28 free instance hours
- 1Go database
- 50 000 database read/write/small
- 1Go Outgoing Bandwidth
- 1Go Incoming Bandwidth
- 100 email

Free quota does one more step in lowing your project initial investment. Before you success it’s free! Google estimate this free quota at 163.000 pageview per day. Of course it depend of the use. If one of the features above goes over quota the whole app go down.

It’s enough quotas for development and early adoption. Be careful don’t choose App Engine only for it free quota. It needs to adapt your need otherwise you will hate it. Making this mistake might cost a lot when traffic increase.

Free quota also applies when billing is enable. 29 instance hours will be billed at the price of 1 instance hours.

Automatic CDN

App Engine application use CDN replication automatically. Static content like image, CSS, JavaScript are replicated all across the globe. Users while be serve with the geographically closest file. Speeding up transfer, routing time and latency.

App Engine CDN is pretty good. Some even use App Engine only for it CDN.

Lot of Google services

App Identity – Authenticate GAE with other Google service.
Blobstore – Store large binary in database
Google Cloud Storage – most famous NoSQL database with App Engine
Capabilities – detect outages and scheduled downtime
Channel – persistent connection client / server
Google Cloud Endpoints – webservice made easly
Images – image manipulation
Logs – Writing log
Mail – Sending email
Memcache – distributed in-memory data cache
Multitenancy – multitenant application
OAuth – Grant a third party permission
Prospective Search – “pre-build” search query
Search – index structured data
Sockets – Socket programming
Task Queues – perform work outside of a user request
URL Fetch – Request for efficiency and scaling purposes
Users – authentifiaction system
XMPP – using XMPP protocol
Mapreduce – using map reduct on App Engine

No server maintenance

App Engine idea is to focus on code only.
With App Engine no need to hiring a sysadmin and a database administrator. Google team does it for you and they know their job very well. Very nice to save this cost at the end of the month.

Google high speed network

Google network is reputed to be on of the best network in the word. It’s reliable and fast. Between two regions transfer rate at 300Mbit/s and 20ms latency. Connecting to any Google product will use Google Network.

SDK and languages

You can use App Engine in Python, Java, Go and PHP. As it can run Java by extension, other JVM languages such as Groovy, JRuby, Scala, Clojure and PHP can run on App Engine using the JVM.
App Engine is well integrated with GWT. The Google Plugin for Eclipse even choose by default GWT when you create an App Engine project.

No multithreading

The leak of threading support is the most hated missing feature. Many libraries can’t run on GAE as they use multithreading. Don’t expect migrating to App Engine seamlessly if you’re using threading.

Your app run with other app on a share server. To prevent one application from interfering with another, the application runs in a restricted “sandbox” environment.

30 second per request

Everyone hates this limitation. You only have 30 second to complete a request. It’s understandable from a user point of view. But cron task and maintenance task follow the same rules.

App Engine introduce backend instance to solve this problem. Now you have 60 second to complete a request.
The frontend instance push “long” task to the Task Queue. Backend instance will retrieve the task and process it in background. It’s a good design but it involve so much work for administrative task.

This limitation might turn into a nightmare.

Expensive for constant load

App Engine is a wrong choice when load stay stable. It will cost fare too much.

A small application working 24/7 using 10 instances will cost $517 / months. ( 10 (instance) * 24 (hours) – 28 (free tier) ) * 30.5 (days in months) * 0.08 (price per hour)
= $517 / months

10 GAE instance mean 10*128Mb and 10*600Mhz
For $517 / months

Amazon EC2 c1.medium instance is 2*2.2Mhz and 1.7Gb
for $106 / months (on demand)
or $60 / months (1years subscription)

Don’t miss the point when comparing PaaS with IaaS. With IaaS you loose some of the advantage above.

Develop with your wallet

App Engine let you focus on your code. That’s right. It also focus you on your wallet. During development you keep thinking about the cost of it running in production. Costly operation usually need extra care to implement a caching system. Using caching drastically lower the bill but it cost time and money to implement.

App Engine is all about scale. The pain expect the gain when you serve 100 users/day. Serving 1 million users/day surly worth the development.

Free quota is tricky

Be careful with free quota. It gives the wrong idea about how much the bill will be.

Running 2 instance 24h a day will cost:
(24 hours * 2 instance) – 28 free hours quota = 20 billable hours * 0.08 price by hour
= $1.6 / day
= $48.8 / month

With 10x more traffic, the common mistake is to think it will cost 10x more. Free quota hides the sad reality. App Engine is expensive in the long term.

(24 hours * 20 instance) – 28 free hours quota = 452 billable hours * 0.08 price by hour
= $36.16 / day
= $1102 / months

Expensive? Maybe, depend of the situation. App Engine suppose to required less maintenance. So Remember to substrate part of the cost of a sysadmin and database administrator to the bill.

Not task intensive

You can choose 4 types of instance depending on your need:
F1: 600Mhz – 128Mb – $0.08/h
F2: 1200Mhz – 256Mb – $0.16/h
F4: 2400Mhz – 512Mb – $0.32/h
F4_1G: 2400Mhz – 1024Mb – $0.48/h

All those instance are weak for this price.
Avoid intensive task in request. Also using Memcache when possible will save a lot of computer power.

Locked to App Engine

Yes and No.
We all hate to be lock into a system.I agree it’s not easy to switch from App Engine to your own hosting. But no more than any architecture changes.

Memcache can be installed on your own server. Google Cloud Storage is “just” a NoSQL database. MongoDB or Cassendra can replace Google Database.Google Cloud SQL can be replace by MySQL.

All in one, you always lock yourself into technical decision. But App Engine didn’t try to lock you down.

It’s not a “standard” server (PaaS)

It’s a Plateform as a Service. Accessing the OS isn’t possible. Running third party software neither. All the usually administration task from the command line are not possible. In fact you don’t even have SSH.

Trying to “hack” the system is very difficult. Workaround can take days for something simple to do on a Linux server.


Conclusion

Choosing App Engine for the bad decision will result in hate and frustration.
The opposite is also true, choosing it for the good raison and you will fall in love.

Nothing is black or white. You don’t have to use App Engine for you whole architecture. It’s often possible to do part of the job with App Engine and the rest with “traditional” technology.

Google App Engine is expensive. But it suppose to required less maintenance. When subtracting the price of hiring a sysadmin and a database administrator it might be very cheap.

  • Jesaja Everling

    Thank you, great list of pros and cons!

  • Carl S

    Google App Engine is for scale – the whole ideas of the app engine is this. The problem isn’t with App Engine, if it costs ‘too much’ then your application is built incorrectly to provide a globally-scalable application to people.

    This seems to be a consistently overlooked point when people are investigating Google App Engine. The app you built based on 5 year old knowledge of writing software wont just magically work when you push it into GAE. EC2 makes scaling servers a bit easier, but isn’t anywhere near the little work required for GAE to scale automatically for you. You still need to design your application with scaling in mind, otherwise neither will be cost-effective if your app isn’t built with scalability in mind.

    The Google App Engine does all the scale for you – if you just follow its rules. You would have to eventually follow specific scaling guidelines if you used EC2 or dedicated servers or anything else that provide some type of scalability with its infrastructure.

    For $500/month you could run a 100 million user application with real-time messaging, webpage serving, or a host of other tasks.
    10 instances @ 128megs is a LOT of power. That is 6ghz worth of CPU calculations, crunching ‘something’, swapping 1 Gig of ram every second 24/7 – why on earth are you calling this a ‘small’ website???! An instance should be considered handling a single user request – of which it can actually handle about 1000-2000/requests per second, per instance. 10 of those is in no way shape or form a ‘small’ application.
    10,000 requests per second, 24/7 for a month is: 25.9 billion to 50 billion requests per month using 6ghz of CPU…

  • HumaNature

    Thank you! This is great stuff.

  • Pingback: Welcome | GWT central()