Hacker News Reader

Comment by pokstad | Hacker News Reader

Does anyone have any numbers on the cost difference between standard vs flexible app engine usage?

Flexible environment supports any language/environment you want as long as you implement the HTTP endpoints it expects. I would be much more impressed if they brought Python3 to the standard environment which seems to be much more cost effective for many types of web apps. Flexible environment essentially requires you to run a VM all the time, which can get pricey, versus a much more managed sandboxed environment that can sleep and be awaken quickly as needed to serve requests. Also, Python 3.5 would be awesome to leverage asyncio, but that's probably still a bit too bleeding edge.

View on HN

We use a combination of both at my company. We use the standard environment for the majority of our services, doing things like proving APIs, serving webpages, performing datastore interactions, etc. The flexible environment starts to make a lot of sense when you're doing heavier weight processing, text analytics in our case. App Engine instances are relatively cheap when you're using the smallest instance sizes, and have even more benefits if your application has idle time when they can spin down completely, but costs start to go up very quickly if you need to move to the bigger instances in the standard environment [1]. The flexible environment is current billed at the rate of the machines you're using, so is much cheaper for bigger instances [2].

[1] https://cloud.google.com/appengine/pricing#standard_instance...

[2] https://cloud.google.com/compute/pricing#predefined_machine_...

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.

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.

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.

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?

If you have very little traffic then what you are saying is true, flex GAE requires you to keep one VM running.

For our our app (Streak) we run 100's of instances, we moved some of our services from standard GAE to flex GAE and saw a HUGE reduction in costs. Depending on workload we saw 5x-10x reduction in cost. To see why this is possible, look at the price of a standard GAE instance and the price of a default flex instance. For roughly the same price you get a way more capable machine.

You just have to have enough traffic where you'd like to keep at least one instance running all the time. Enough traffic in this case is a really small number. If you're traffic is lower than that number than who cares about optimizing costs, its gonna be cheap no matter what.

On lowish traffic apps, it's way way more expensive as you have to pay for the VM's to be permanently running. AFAIK you also need to have 2 app servers running as they get restarted once w eek (at least thats how it is for Java apps I believe)

Reply on news.ycombinator.com