
Why Google App Engine Rocks: A Google Engineer’s Take - cjdrake
https://cloudplatform.googleblog.com/2016/04/why-Google-App-Engine-rocks-a-Google-engineers-take.html
======
johansch
App Engine is brilliant and strangely under-appreciated at HN, I think. (A
cynical person might thank that it's AWS "devops" people protecting their
jobs, but I guess it's more likely that the cause is groupthink.)

Last summer I switched jobs from a company where we developed loads of cloud
thingies ourselves, because there really weren't any good options around ten
years ago when we started a product line that needed a high quality global
service (involving processing, networking and storage). We had a lot of fun
basically building our own little (if 5000+ machines qualifies as little)
AWS/Google-style Cloud. I heard about Amazon Dynamo in 2007 and then we
basically re-implemented it ourselves. We added lots of neat features like
datacenter-aware global replication, etc.

When I joined the new company last June, it was basically just me. A few
months later we hired a great python dev. I'm so happy to find that the level
of the openly available products/services had caught up _quite_ a bit by then,
enabling us not to spend so much time on just making sure things were
available all of the time, and ~infinitely scalable.

I spent _a lot_ of time evaluating AWS vs GC, but my inevitable conclusion was
that.. in a small company where you don't want to invest in a 24/7/365 devops
team you should go for the Google App Engine.

I would really like it if Google found some pragmatic way to make App Engine
work inside China though, at least for companies that have chinese ICP
permits.

(Why hasn't AWS launched a PaaS? Lambda is so neutered that it doesn't really
count.)

~~~
untog
> (Too many AWS "devops" people protecting their jobs?)

I don't think so. A good while ago GAE was incredibly limiting - it certainly
was when I tried it. Python only (maybe also PHP?), forced to use Google Cloud
whatever for storage, etc. By comparison, AWS was using MySQL databases and
EC2 boxes that let you use whatever language you wanted.

I know things have come a long way since then, but the reputation persists.

~~~
johansch
> Python only (maybe also PHP?)

They now support Python, PHP, Java, Go.

And in beta, "flexible environment", which is like elastic beanstalk but more
sensible: Python, Java, Go, Node.js, Ruby, <random docker images>.

~~~
democracy
While they are java keywords as we know them this is not a complete jdk, so
many (almost single good one) libraries dont work. I remember spending a week
trying to port itext pdf generation lib to gae. While it worked we got
concerned by the legal issues of us riping code out of sun/ibm/harmony jdks to
add missing jdk classes.

Java here is a pure marketing effort to convince a clueless manager saying hey
we got java!

~~~
edwinnathaniel
> Java here is a pure marketing effort to convince a clueless manager saying
> hey we got java!

What if there exist Java-based system that somehow can be deployed to GAE with
minimum changes...? (e.g.: not needing itext)

What if there exist a company that the majority of developers prefer Java?

------
neals
Is Google App Engine under performing? I wonder why do they would need a fluff
marketing piece like this.

I hope they're not in trouble or anything, I have been moving my project from
VPS over to GCM for the past year now. I love it.

~~~
flurben
I love using GAE as well, but I'll be damned if I can find a job using it. It
is almost impossible. The few that exist are in the highest-cost locations in
America.

In that sense I think it's a failure; it simply hasn't been widely adopted.

At my last job I pushed for using it, and the suggestion was shot down, on the
basis that "If I left they'd never find another person who knows GAE."

~~~
vthallam
Guess, it's about time there are more developers/devops who know GAE! Google
have been quietly building a fantastic product line and when they start
heavily marketing, there would be tons who would want to learn and switch.

------
NearAP
I believe I've made this comment before - Google App Engine is good and
quickly allows you to get a proof of concept off the ground. But the
documentation SUCKs big time - the language is obtuse, the documentation is
repeated in multiple places (meaning different paths to documentation
explaining the same thing in different ways), and it is not uncommon to find
that the documentation is not current.

~~~
pseudobry
You should take another look, as we literally rewrote most of the
documentation in the last few weeks.

~~~
alttab
What's missing from this fluff piece is the top 5 reasons why its better than
AWS.

~~~
dragonwriter
> What's missing from this fluff piece is the top 5 reasons why its better
> than AWS.

AWS and AppEngine aren't even the same kind of thing. AWS is a high-level
collection of services (Google's equivalent is Google Cloud Platform.)

AppEngine is a PaaS offering within Google Cloud Platform. And, AFAIK, its one
piece of GCP that AWS doesn't have a direct competitor to. (Lambda is, I
think, the closest thing.)

------
oxplot
A trend of comments I see whenever App Engine is mentioned is how limiting App
Engine platform is and how it doesn't have MySQL, etc. No one seem to ever
mention scalability? App Engine is built for just that! Datastore is
infinitely salable so is the application and every other API on GAE. I can
spend an hour writing an app from scratch that scales infinitely on GAE
without a thought. I personally do not know of _any_ other PaaS (e.g.
Openshift, Heroku) that's capable of doing that unless you spend a month
learning ins and outs of devops for that particular platform.

EDIT: Also the Datastore is replicated in multi data centers and again, you
don't have to think about backups either.

~~~
deepsun
It has MySQL, by the way. I wish they had PostgreSQL, though.

------
democracy
I believe many see AWS offer as "we have the same *nix boxes you already have
but cheaper/on-demand/easily scalable". Plus nice feature as local storage of
your data (can be a legal requirement for some industries). Create an account
and start deploying now with the smallest investment and commitment.

GAE on the other hand is "we can solve your scalability problems" that many
simply don't have and "you should write/re-write your apps to use our
framework" which is a red flag to many as well.

~~~
deepsun
Actually, GAE is more about easier development for starter projects. GCE is
more like a competitor to AWS, not GAE.

~~~
democracy
For starter project in starting companies maybe, for existing companies not
that easy...

------
ocdtrekkie
A Google engineer's take on a Google product? I don't feel like this
testimonial holds a lot of real value. Why not have someone who isn't being
paid by Google tell you that Google products are cool?

~~~
alttab
Or at least minimally compare it to other products that do similar things and
are more widely used to provide some basis for comparison?

------
NearAP
One other 'thing' \- there are some services that you have to enable billing
before they are available on app engine. Google also typically gives you a 30
day/$XXX credit for it. That is a nice feature. The 'challenge' for me is that
typically, at this point I'm still trying to test out my code and basically
have no traffic so the $200 credit basically becomes a waste. It would be nice
if one could be allowed to 'decide' when to use this credit. At my
testing/experimenting/design phase, the free quota would be enough for me or I
would be willing to pay out of pocket (since I'm still testing I would keep
the amount to the barest minimum).

------
kevando
According to my depreciated appengine console, I would not say that Google
thinks "App Engine Rocks."

~~~
justinblat
Of course we do :) We deprecated the original appengine console, and we've
moved all of the UI over to the Cloud Developers console:

[https://console.cloud.google.com/](https://console.cloud.google.com/)

It has all of the cloud stuff in one place. Should be a lot nicer to use too
:)

~~~
NearAP
With the old appengine console, you just went to one url -
appengine.google.com and you found all the links in one place - application,
logs, datastore, etc

Since the old appengine console was deprecated, it is difficult to remember
the urls for the different services. One has to try and remember multiple
urls. It is quite confusing and frustrating.

~~~
cbsmith
The golden rule of UI is that if you change it, it will ruin the experience
for someone.

------
balls187
Just logged into my GAE Console to see how my old apps were doing, and was
treated to this:

[https://annotate.driftt.com/view?i=7zvk40ibtjaaxhs%2F2016-05...](https://annotate.driftt.com/view?i=7zvk40ibtjaaxhs%2F2016-05-06_at_1.57_PM.png%2F)

\-----

If you get that error, somewhere you need to agree to new T's and C's. The
site doesn't redirect your properly, so you need to click around until you are
prompted to agree.

Pretty cool to see my simple little GAE Emailing app I wrote for my startup
back in 2012 was cranking away 3 years later.

~~~
nissehulth
Do you have javascript disabled?

~~~
balls187
Nope

------
filleokus
Hehe, we're running GAE at work and I'm constantly looking for other options /
trying to persuade management to spend the time on migration. I spend 8-12
hours a day fighting with GAE in one way or another, even though I very well
might experience the "green is grasser" symptom.

Many things are nice with App Engine, outlined in the post. But so many things
are not nice:

\- For us the performance characteristics for some queries in the NDB (NoSQL
datastore) have really left much to be wanted.

\- The inability of calling C-libraries from Python code (except those
provided by Google, they provide standard stuff like cPickle etc)

\- The UI for logs / querying the database / admin is quite bad and buggy.
Can't really use it in Safari at all (might very well be the wrong doing of
Safari, but still)

\- Limitations in how long functions / tasks can run. I've spent all of my
Friday night tonight (I'm in CET) re-writing code for a batch-processing task
that took just above the hard imposed limit of 10 minutes to run. According to
the docs an exception is to be thrown when the task is nearing its limit but
most of the time (intermittently…) the exception is not thrown and just kills
the process…

\- Limited community / toolset. Using GAE feels somewhat like using something
really old or obscure, quite few SO questions/answers (the upside is that many
of them are written by Gudio, which lead the NDB project before quitting from
Google), and extremely limited third party tools / plugins for enhancing the
developer experience. For example I haven't found any good way, except the GAE
provided one, to do performance profiling.

\- GAE has somewhat of a bad rep in some parts of the Python community I've
found. A couple of Python libraries I've tried to use have not worked and then
I've found bug reports where the maintainers have explicitly stated that GAE
is not supported because of some limitation they have imposed. The biggest
example I can come up with right now is probably Requests

With that said however, I feel like Google has started giving GAE more love
recently. The documentation seems to improve, the dashboards/web UI:s have
undergone major rework (not all of them improvements per se but still!). I
actually said to my management a while ago that we need to move away from GAE
in the medium term (1-2 years) because I feared that Google would start to
"sunset" GAE. I wouldn't say that is the case today, but I could not go so far
as to say that I would recommend GAE.

GAE is a very nice platform in many ways, but very limited. The tradeoffs for
all the ease is quite high and should probably be considered very carefully
before picked.

~~~
deepsun
I have many years of experience with GAE, and still love it, the point is to
use it where it fits.

Agree about slow web console, especially for logs. Datastore viewer got
better, though.

I don't know about Python ecosystem, but I think that if you need C-libraries,
then you shouldn't be running it in GAE. Low-level stuff sounds better fit for
GCE, or AWS. Our team lives in Java world, and pretty much everything there
plays fine with GAE. There are some low-level areas (like Unsafe memory
management) where it doesn't -- but it's not web-serving part anyway, so it
doesn't fit in GAE, IMHO. For example, we offload our recommendation
regressions to Docker container engine.

Recently they released so-called Flex environment which is basically container
engine (Kubernetes) for any Docker container that listens on port 80. And they
have several pre-build containers for different languages and with stubs for
Standard environment, so you can throw-in your existing GAE app there. I
didn't like Flex environment for my web serving part, though, for two reasons:

1\. Too slow to deploy a new version, like 10 minutes. Really? It seems to
upload all the files (Standard uploads only what's changed), and after that
they spin up a GCE instance to build a Docker container from the files. And
that takes time.

2\. I now must care about serving static files myself. In current Standard
environment, statics are automatically served by Google's servers, even if my
app has no instances running. For Flex env they suggest to upload statics to
GCS, but it's additional ops work.

------
dominotw
>Some were a LAMP stack on a managed hosting service. Some were running as a
cron job on someone’s workstation.

All that whiteboard interview pedantry doesn't seem to shield them devs who
don't know how to deploy a basic production grade app. But hey they were able
to memorize tree inversions before interviews so thats good.

------
diyseguy
They're probably going to end of life it like everything else they get bored
with. I can't imagine any sane business would risk putting any amount of
development time investment into their stuff.

~~~
alooPotato
You know appengine has been around for 8 years right?

~~~
saool
Same number of years Google Reader had been around when it was sunset.

~~~
ariwilson
I bet it's earned Google infinitely more dollars than Google Reader!

