Hacker News Reader

Comment by alooPotato | Hacker News Reader

From the pricing docs you qouted - the smallest standard instance is an F1 which costs $0.05/hr and has a 600mhz cpu + 128mb ram.

Compare this too flex VMs where the smallest machine is $0.038/hr and have beefier CPU and 3.75Gb of ram.

Doesn't it always make sense to use the flex VMs? The only downside being min 1 instance and slower autoscaling.

View on HN

The other downsides are the deploys are slower, for now at least, and it's still in Beta. Beta means it has SLOs, which are like reliability goals, but it doesn't have SLAs, which means you get refunds for downtime. App Engine Standard does have SLAs:

https://cloud.google.com/appengine/sla

Beta products are also more willing to make backwards incompatible changes with shorter deprecation timelines. But overall it's certainly a lot more, ahem, flexible. Sneaky awesome feature is ability to install things like imagemagick , phantomjs, or ffmpeg, which to shamelessly self-promote I wrote about here:

https://medium.com/google-cloud/scalable-video-transcoding-w...

That's using a custom runtime, which won't be as officially blessed, but you can of course just extend from the official runtimes, since they're on Google Container Registry and open-source:

https://github.com/GoogleCloudPlatform/python-runtime

Just write a Dockerfile that starts with: FROM gcr.io/google_appengine/python

Obvious disclosure again I work for GCP.

For flex: "While in Beta, based on Compute Engine Pricing for each VM. Pricing will change in the future." [1].

I'm guessing the flex price will go up when it leaves Beta?

[1] https://cloud.google.com/appengine/docs/the-appengine-enviro...

Can't edit the parent anymore: Actually the flex price should go down compared to Compute Engine because it should be optimised for a more specific use-case?

waprin's comments are on the nose with what we've experienced.

There are pain points with the flexible environment that we don't have to worry about at all with standard runtimes. The two biggest ones for us are slower deployments and a lack of monitoring tools.

Just today we actually switched one of our App Engine modules to Flexible runtimes out of necessity as we we're hitting quotas for App Engine infrastructure, and in doing so we no longer have easy access to metrics on how many instances are running or memory usage for the service. The "Cloud Trace" tools are also impaired when you aren't using standard runtimes. In short, you lose visibility into your instances. It ends up being a tradeoff between developer time and cost.

With certain runtimes in the flexible environment, you also lose out on pieces of the App Engine infrastructure like memcache, which are invaluable in optimizing services.

Ahhh yes we've been hit with this. There are subtle differences in the GAE APIs when using flex. Trace as you mentioned, but also channels api doesn't work at all, cloud debugger only sometimes works, etc.

Most of these have gotten a lot better since managed vm's first rolled out (3 years ago!?!?!?!?!)

We preload a memcache proxy on your VMs for your non-gae runtimes:

https://github.com/GoogleCloudPlatform/appengine-sidecars-do...

In a nutshell, you can use a standard memcache library from your favorite language.

Disclosure: original author of this proxy when I was on the App Engine team.

Reply on news.ycombinator.com