[sayhello]

This is exciting because the second generation standard environment allows Google App Engine to provide a more "idiomatic" experience.

Using gVisor, instead of NaCL, as the sandboxing technology, shipping new runtimes becomes a much more tractable task with less differences from the "plain" runtime. In fact, gVisor allows us to use the runtime unmodified.

This in turn, decreases the "lock-in". There are still decisions we need to make depending on the runtime, e.g. which package manager to use if there isn't a community default.

Hopefully, the narrative for "Serverless" moves beyond lambda and functions. Sometimes (!) we want apps, databases, caches and more to be "Serverless" :-)

Disclaimer: I work at Google, on the App Engine Runtimes team. I helped ship this

[wasd]

Thank you for all your hard work! I'm so excited about thew new app engine. Pleaaase bring Ruby next :).

[sayhello]

More runtimes coming out soon. Stay tuned :-)

[_wmd]

Am I correct in understanding the new environment is built on essentially a ptrace sandbox? How does that impact performance? Is it still single threaded? If you're moved beyond single threads, how does the it cope with security problems endemic to userland sandboxing? (TOCTTOU issues as the 'hypervisor' verifies arguments, etc)

Are you willing to compare your approach to for example Lambda's approach, where the user gets an actual real Linux VM. with zero differences (Work that, incidentally was in part contributed to Linux by Google!), as opposed to a Linux emulator?

[velominati]

Hi. I'm the PM at Google Cloud on the Second Generation runtimes.

This is based on gVisor (https://github.com/google/gvisor), but it does not use the ptrace sandboxing that is in the mainline open source project. Our First Generation runtimes (aka nacl) were based on ptrace. In our informal testing we have observed the Second Generation runtimes to be about 20% faster than the First Generation. I don't have benchmarks on how it compares to a raw VM.

These new runtimes are capable of multithreading, so long as the language is capable of it. And you will need to use an instance larger than the default (F1 / B1) to have access to more than one thread.

[bpicolo]

Two have access to more than one hardware thread or more than one OS thread?

[iangudger]

I work on gVisor. gVisor supports concurrent multi-treading, but should not be vulnerable to TOCTTOU, even in ptrace mode. gVisor handles system calls itself, it does not simply verify the args for app system calls and then pass them on to the host. That said, if you find any security issues, please let us know. There is a security email address in the github issue template.

App Engine Flex is a version of App Engine that uses VMs with Linux. You can find a comparison between the standard and flexible environments here:

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

[lima]

gVisor can use KVM for isolation instead of ptrace, and I would guess that Google is using it.

[sayhello]

Correct. We do not use ptrace in production.

[_wmd]

Thanks for clarifying.. it sounds thoroughly tragic, and the kind of endemic overengineering that made so many people (myself included) run screaming from the original App Engine over the years. I guess GCP really turned a page in Google culture and learned to finally listen to customers

AWS> we put your code in a container, like everyone else puts your code in a container. We bikeshedded the Linux distro a bit, so you might need to recompile

Customer> OK. Fine

GCP> our web scale open source userland kernel hypervisor written in Go hosts your code in a Linux-but-not-quite-Linux microservice

Customer> Why does <X> system call return a strange error code?

GCP> You're too dumb to understand. Trust us

Customer> oh, I think I understand well enough. Calls back Azure sales rep

[zinclozenge]

Random question, is it possible to have a python2 default service and a python3 service in the same app engine project?

[chrisbroadfoot]

Yes.

[sonaltr]

What about search and cache?

it's still Python 2.7 only :(

[mehrdada]

dis·claim·er, noun, a statement that denies something, especially responsibility. [1]

Did you mean "disclosure"?

[1]: https://www.google.com/search?q=define%3ADisclaimer

[sayhello]

I suppose colloquially on this forum in the context of comments, the word does deny something: usually of the possibility of bias.

Disclosure would work just as well, and is in fact more accurate!

[mehrdada]

> the word does deny something: usually of the possibility of bias.

That's precisely why I objected to its use in the context it was used here (and other places where it is colloquially used incorrectly): by announcing you worked on something, you reinforce the possibility of bias in the post while taking partial responsibility for the work--it does not disclaim or subtract bias or responsibility.

[sayhello]

I made a logical error, I meant to say:

> the word does deny something: possibly objectivity.

i.e. there is a possibility of bias.

That said, I've made my peace about the "proper" use of language, or rather, the lack thereof, and now espouse it.

Like, literally.

The meanings of words and idioms shift over time. As long as we're understood well enough, that's fine by me.

[jgtrosh]

Instead, could they not be dis-claiming their objectivity?

[hencq]

Not sure why you're getting down voted. Perhaps because people find the tone too snarky. You're right though. It's a mistake I see all the time here (and it secretly bugs me haha). Disclaimer in this case would mean: "I say this, but beware I'm not involved in this so I'm probably wrong". Which is exactly the opposite of what's intended here.