13 ms·

Does anyone have any numbers on the cost difference between standard vs flexible app engine usage? Flexible environment supports any language/environment you w

by pokstad 10y ago

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.

dabeeeenster 10y ago
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)
alooPotato 10y ago
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.
kujenga 10y ago
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_pricing https://cloud.google.com/appengine/pricing#standard_instance... [2] https://cloud.google.com/compute/pricing#predefined_machine_types https://cloud.google.com/compute/pricing#predefined_machine_...
- alooPotato 10y ago
  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.
  - waprin 10y ago
    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 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-with-app-engine-flexible-621f6e7fdf56#.boyvfstt6 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 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.
  - kujenga 10y ago
    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.

by pokstad 10y ago

dabeeeenster 10y ago

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)

alooPotato 10y ago

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.

kujenga 10y ago

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_pricing https://cloud.google.com/appengine/pricing#standard_instance... [2] https://cloud.google.com/compute/pricing#predefined_machine_types https://cloud.google.com/compute/pricing#predefined_machine_...

alooPotato 10y ago
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.
- waprin 10y ago
  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 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-with-app-engine-flexible-621f6e7fdf56#.boyvfstt6 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 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.
- kujenga 10y ago
  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.