Why Google App Engine Rocks: A Google Engineer’s Take | Hacker News Reader

Why Google App Engine Rocks: A Google Engineer’s Take

cloudplatform.googleblog.com

50 pointscjdrake68 comments

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.)

> (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.

Agreed; GAE's initial feature set was not great, and I think some of that launch stink unfortunately still sticks. As a counterpoint, you see lots and lots of love on HN for Heroku, which is a PaaS in much the same vein as GAE.

It's not protectionism; it's ignorance? ;)

Ignorance about getting locked into an ecosystem its harder to get out of? Hardly.

But heh! You do you, I'll keep my platform agnostic config management thank you very much. Life's too short to be beholden to any one vendor.

There is really no lockin at all if you use e.g. Flask via the WSGI interface. That is the beauty of it.

You can downgrade to manally managed servers with the the same codebase.

> You can downgrade to manally managed servers with the the same codebase.

Or you spend the few extra hours upfront wrapping your app in config management so it can run on any bare VM.

Don't be lazy! Not being able to run anywhere is technical debt. Unless you're running a hobby site that generates no revenue; in that case, do whatever.

YAGNI. Do it when you know that you need it.

YAGNI does not apply to risk mitigation.

I think Google would let us know in advance if they ever decided to retire AppEngine.

Reputations are hard to shake. When it launched GAE was one big vendor-lockin, and we all avoided it.

When GAE launched I found it to be a cool toy, played with it a little and dismissed it - way too much lock-in.

After revisiting it the past year.. I don't really understand why the in comparison pathetic AWS Lambda gets so much more attention, for instance.

> Python only (maybe also PHP?),

I think the order in which GAE added languages was Python, Java, Go, PHP.

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

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!

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

GAE vs. EC2 is kind of the wrong comparison though... GAE is kind of more like AWS Lambda, or maybe bit like ECS or Elastic Beanstalk (and even then not really).

> App Engine is brilliant and strangely under-appreciated at HN

No, it's the worse PAAS in existence. Horrible proprietary NoSQL DB, filtered headers, must perform http requests with custom SDK (horrible SDK BTW...). It is absolutely not worth it.

The new Google "managed VMs" or whatever are closer to what Appengine should have been all along.

I'm not saying AWS is great, it has a horrible UI, but AWS has none of these silly limitations.

App Engine screwed so many people over. First they couldn't get it working. Then they tripled the price. Fuck App Engine.

I can't imagine anyone reading HN who'd think this is the right solution in 2016. Even if you want to jump on the Google train (there are valid reasons for this, including free outbound bandwidth to YouTube and Google Drive...), there's no excuse for App Engine. Use the other Google cloud offerings. The container stuff is top notch.

I find the history of app engine and how it compared to the competition back then quite uninteresting. What I find interesting is how it works today.

They didn't "triple the price". They changed the model of what they charged and how. For some users, this definitely screwed them. For many others the list price could have gone up quite a bit, but with just a bit of performance tuning could have been perfectly fine. I speak from experience... the pricing shift incentivized me to do some refactoring, and my monthly bill dropped by ~50-60%.

And AppEngine is absolutely the right solution for some users, like people who don't want anything to do with sysadmin work, configuring containers, etc. (Like myself.)

Eh, I don't know that I agree that there's no reason for App Engine. For a simple, low traffic Django app it's both simpler and cheaper than say standing it up on GCE or GKE.

I hear you about the pricing change. We talk a lot about not getting pricing wrong internally (now), as that's exactly what happened. Initial trial pricing is ... dangerous.

Disclosure: I work on Compute Engine.

> Horrible proprietary NoSQL DB

First, why do you think Google Datastore is any more or less proprietary than AWS Dynamo? (Which has its own eccentricities- like having to forecast and/or overallocate capacity in advance; while with Datastore you only pay for actual usage?)

Oh; and you can also use Cloud SQL or BigTable from within AppEngine.

> must perform http requests with custom SDK

What do you mean?

Are you saying the raw sockets API doesn't allow you to use port 80? (I don't believe that to be the case).

The filtered headers thing is a common issue in many https load balancers, particularly ones like ours that have global anycast routing.

I've shown a bunch of people that a modern App Engine standard environment app can run stock Django talking to MySQL (which we manage for you with Cloud SQL) just fine. If you need native C-code extensions, sure use our new Flexible Environment (neé Managed VMs) but you don't need to for many simple apps.

Finally, as others have pointed out, App Engine is just one piece of our overall platform (though it was first, so it's common to have this misperception).

Disclosure: I work at Google on Compute Engine (so of course I want you to use our products).

> App Engine work inside China though

There is this: https://www.appscale.com/

It's an open source implementation of the App Engine APIs. The website doesn't make it very clear but the source is on Github: https://github.com/AppScale/appscale

Good point. AppScale has always been on GitHub under an Apache 2 license and has customers in production in China.

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.

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."

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.

We have avoided GAE at our startup simply because we depend upon google for so much already. we made an explicit choice to avoid putting all our eggs in that basket, and are completely happy with AWS.

> I wonder why do they would need a fluff marketing piece like this.

Because, there is a huge gap between market perception and their product offering.

Google was never big on Enterprise marketing materials in the past.

Now that things have changed (re-org Alphabet, new Cloud leadership), they seem to take marketing/sales (and hopefully support) more seriously (and with more traditional approach).

It's a good sign; they're maturing.

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.

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

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

> 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.)

The google cloud documentation is definitely sub-par. I tried to build a simple Go app trying to use the pubsub api and eventually gave up. None of the documentation provided a full working example and any example you can find references an old version of the api. And this was with Go!

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.

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

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.

> I believe many see AWS offer as "we have the same *nix boxes you already have but cheaper/on-demand/easily scalable".

That's specifically EC2. To which Google's direct competitor is GCE, not GAE.

AWS's component most directly competing with GAE is Lambda.

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

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

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?

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

His point is that using App Engine cut down maintenance time. I find that noncontroversial.

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).

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

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/

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

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.

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

Recently there was one liner linked here on how to dramatically improve Angular's speed. Would help that new console too :)

The console was deprecated in favor of a new console that lives in the larger Cloud console.

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

-----

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.

Do you have javascript disabled?

Nope

Are you using uBlock?

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.

It seems like you might be better served by the new Flexible environment. You've got a desire for longer running tasks, C-extensions for Python, etc. which fits the App Engine Flexible (neé Managed VMs).

Disclosure: I work at Google on Cloud.

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.

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

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.

You know appengine has been around for 8 years right?

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

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

What happened once it (GAE) reaches 9 year? gasp ...

Does Google appear bored with this? Long before it was even a product, this kind of service was a very core competitive advantage that Google has cultivated, and the much larger competitive landscape means we're looking at a product category of the size & scope that would make sense for Google to tackle.

It's heavily used inside Google. Tons of google-internal tools are built on App Engine.

Reply on news.ycombinator.com