Live data from Hacker News

Python 3 on Google App Engine flexible environment now in beta

cloudplatform.googleblog.com

41–49 of 49 posts

Re: Python 3 on Google App Engine flexible environment now in beta

#41
post #40

Earlier quoted context omitted.

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'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,…

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

Re: Python 3 on Google App Engine flexible environment now in beta

#42
post #28

Earlier quoted context omitted.

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…

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.

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

Re: Python 3 on Google App Engine flexible environment now in beta

#43

Earlier quoted context omitted.

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.

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?

Re: Python 3 on Google App Engine flexible environment now in beta

#44
post #40

Earlier quoted context omitted.

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'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,…

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.

Re: Python 3 on Google App Engine flexible environment now in beta

#45
post #20

Earlier quoted context omitted.

I wish there were a clearer delineation between developer downloads on PyPI and automated builds, since it seems there's been a bit of a cultural sea change over the past year or so in favor of Py3. I'd love to know which version humans are downloading.

Wouldn't Python 3 ALSO have installations doing automated builds though?

Yes but if automated pip installs numbers are way larger than manual installs you end up with projects supporting both with roughly 50-50 numbers.

I agree with the parent post: now is the time. Open source projects should to stop supporting py2 in their new major release and cleanup their codebase from the hacks made to support both languages.

Re: Python 3 on Google App Engine flexible environment now in beta

#46
post #18

I recently signed up for a trial and tried to use Google Cloud Platform. Oh my god the UI was amongst the worst I have ever experienced on the web. Super slow and hard to navigate. Stupid "tutorial". I tried for a good two hours, tried to accept it but finally gave up on it. Google, cut down on your Angular and material design kool aid and try harder next time.

Have you compared it to AWS?

Yes I have used AWS a lot and been happy with the UI, it gets the job done.

Google Cloud Platform UI (and speed) was just actively hostile towards me.

For example I went to the App Engine section to create a simple flask app. It keeps forcing you through a stupid tutorial trying to guide you around the site. Believe me being a developer myself I'm no stranger to web and its interfaces and can quickly navigate my way around this stuff but this had me hitting my head on the desk.

Re: Python 3 on Google App Engine flexible environment now in beta

#47
post #25
post #2

I'm really glad this big fat blemish is now finally going away. Anybody has a reasonable theory for why this took so long, despite users asking for it for years?

Especially amusing was that Guido was working on the GAE team for a while, and even that wasn't enough to get them to support Python3.

I wouldn't say amusing, though it is interesting, and taking note of Go and Dart, it may reflect what role Google thinks Python plays.

Re: Python 3 on Google App Engine flexible environment now in beta

#48

Really cool. Would be interesting if App Engine becomes a spot for larger framework driven web apps like Django, or if/when ruby is supported, ROR. It could be a very efficient way of doing so because you could have a single instance running with a gazillion gunicorn/unicorn worker processes to distribute the load across processes.

Note that Django has worked on App Engine standard for many years now and in fact the App Engine SDK still distributes a Django build.

More info on the different Django+AppEngine options here: https://cloud.google.com/python/django/ https://code.djangoproject.com/wiki/AppEngine

Disclosure: I'm an engineer at Google.

Re: Python 3 on Google App Engine flexible environment now in beta

#49
post #45
post #20

Earlier quoted context omitted.

Wouldn't Python 3 ALSO have installations doing automated builds though?

Yes but if automated pip installs numbers are way larger than manual installs you end up with projects supporting both with roughly 50-50 numbers. I agree with the parent post: now is the time. Open source projects should to stop supporting py2 in their new major release and cleanup their codebase from the hacks made to support both languages.

>I agree with the parent post: now is the time. Open source projects should to stop supporting py2 in their new major release and cleanup their codebase from the hacks made to support both languages.

The danger with this for Python is that it can give the impetus (is that the word?) and motivation for people with py2 legacy projects (which is the majority of people) to say "fuck this" and go try another language that doesn't pull this shit on them. Go, JS with Node, Ruby, whatever...

If they're not gonna get compatibility anyway, they might jump ship altogether. At least for green-field projects...

Post reply on HN