Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3 on Google App Engine flexible environment now in beta

cloudplatform.googleblog.com

Post reply on HN
Print view View original

31–40 of 49 posts

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

#31

Post by kujenga »

vsrinivas wrote: post #17
lern_too_spel wrote: post #15

Earlier quoted context omitted.

Flexible environments are significantly worse if your application works on the original style of app engine.

Just wondering, why do you think so? (It wasn't obvious to me why, given a first read of the docs; the fact that applications run in VMs in Flex seems more like an implementation detail. Am I missing something?)

We use both and try to stick with standard runtimes wherever possible, resorting to flexible runtimes for things doing heavier processing and/or with lots of instances.

The standard runtimes are superior in a lot of ways, two big wins being lightning fast deployments (seconds vs. many minutes) and batteries included for all the app engine services. Logging in the flexible environment can also be a bit lacking. When you have something running in standard runtimes you basically don't have to think about many of the things that can normally go wrong on a server.

That said, many things about the flexible environment are rapidly improving, they've certainly come a long way since we first started playing with them around 6 months ago.

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

#32

Post by merb »

jonwayne wrote: post #9
rch wrote: post #4

> you can use the tools and databases you already know and love But not Postgres or Redis? Edit: OK, I'm seeing some references in the docs. Still seems limited to deployment on generic instances though.

You can use Postgres and Redis. :) I'm working on writing new tutorials for both of those, but in the meantime: You can host your own Postgres on Compute Engine [1] or use a hosted provider like ElephantSQL [2]. You can use whatever client library you want to connect to postgres in App Engine flexible. Same story for redis - you can host it on Compute Engine [3] or use something like redislabs. [1] https://cloud.goog…

that's not the same as fully managed postgresql (which only aws has (at the time)) elpahntsql is not really cheap compared to aws master-slave.

Just comparing the smallest instances, elephantsql:

- db.t2.micro 1 year 20 USD / month (250 USD upfront) - 24.82 USD monthly (that's a multi-slave with auto failover) compared (with 30gb (SSD) storage it's at 30 USD) to elephantsql only 2GB data on a shared database server 20 USD

- db.t2.small 1 year 41 USD / month (500 USD upfront) - 50 USD monthly (that's a multi-slave with auto failover) (with storage around ~60 USD) vs elephantsql Happy Hippo single dedicated database 99 USD 100gb data

you kidding right? I would need to pay twice the price.

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

#33

Post by alooPotato »

kujenga wrote: post #28
pokstad wrote: post #19

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 t…

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.

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

#34

Post by cyberpanther »

jo909 wrote: 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?

I think this is my main problem with Google services. It takes them forever to listen to people. And I don't think other cloud services listen any better but at least it seems they give you what you want faster. So they have a better mechanism to know what works and making a product of it.

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

#35

Post by waprin »

dabeeeenster wrote: post #30
waprin wrote: post #27

Earlier quoted context omitted.

App Engine Flexible runs on GCE instances, which all have internal IPs. So you can just firewall off external traffic but allow internal, which is the default anyway. Disclosure: Also GCP Developer Relations

OK great - thanks. Just to be clear, you'd still be opening up DB ports to all internal global GCE instances?

Global GCE instances within your project, yes. Not every GCE instance everywhere, that would not be very helpful :)

If you wanted to have some instances that couldn't talk to your database, easiest thing to do is probably throw them in a separate project or create a new subnet that you firewall off and create your non-App Engine instances in that subnet.

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

#36

Post by _quick_q »

advisedwang wrote: post #5
daveguy wrote: post #3

Earlier quoted context omitted.

I think you misread it. Unfortunately it looks like Python 3 is not going away. You did say big fat blemish, right?

I think the "lack of Python 3 support" is the blemish referred to, not Python 3 itself.

I think you may have missed the sarcasm in the parent post.

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

#37

Post by waprin »

alooPotato wrote: post #33
kujenga wrote: 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.

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.

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

#38

Post by brianwawok »

theptip wrote: post #25
jo909 wrote: 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 assume that was depressing.

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

#39

Post by brianwawok »

borplk wrote: 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?

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

#40

Post by kujenga »

alooPotato wrote: post #33
kujenga wrote: 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.

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.

Post reply on HN