Beta release of PHP 7.2 in the Google App Engine standard environment • Hacker News Board

Re: Beta release of PHP 7.2 in the Google App Engine standard environment

#51

Post by lima » Tue, Aug 21, 2018, 7:59 PM UTC

_wmd wrote: post #45

sayhello wrote: post #16

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

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…

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

Re: Beta release of PHP 7.2 in the Google App Engine standard environment

#52

Post by sayhello » Tue, Aug 21, 2018, 8:18 PM UTC

lima wrote: post #51

_wmd wrote: post #45

Earlier quoted context omitted.

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…

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

Correct. We do not use ptrace in production.

Re: Beta release of PHP 7.2 in the Google App Engine standard environment

#53

Post by zinclozenge » Tue, Aug 21, 2018, 8:32 PM UTC

sayhello wrote: post #16

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

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

Re: Beta release of PHP 7.2 in the Google App Engine standard environment

#54

Post by wasd » Tue, Aug 21, 2018, 8:34 PM UTC

sayhello wrote: post #16

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

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

Re: Beta release of PHP 7.2 in the Google App Engine standard environment

#55

Post by _wmd » Tue, Aug 21, 2018, 8:34 PM UTC

lima wrote: post #51

_wmd wrote: post #45

Earlier quoted context omitted.

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…

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

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

Re: Beta release of PHP 7.2 in the Google App Engine standard environment

#56

Post by velominati » Tue, Aug 21, 2018, 8:42 PM UTC

_wmd wrote: post #45

sayhello wrote: post #16

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

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…

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.

Re: Beta release of PHP 7.2 in the Google App Engine standard environment

#57

Post by detaro » Tue, Aug 21, 2018, 9:04 PM UTC

myelin wrote: post #47

floatboth wrote: post #8

Earlier quoted context omitted.

genius… or vendor lock-in?

Member of the App Engine team here. In the context of the second-generation runtimes, this is one of the big reasons we're pushing people to use standard libraries and public cloud services rather than App Engine specific services accessed through syscall magic that doesn't work elsewhere. We want you to be able to run your app locally or on a non-Google server (or on Flex, GCE, GKE, etc).

You should really consider either very detailed porting guides or compatibility libraries, at least from what I hear those required changes will keep some projects on first-gen otherwise (and thus Python 2, and thus requests to dependencies to please keep Python 2 supported and ...)

Re: Beta release of PHP 7.2 in the Google App Engine standard environment

#58

Post by cloud-is-future » Tue, Aug 21, 2018, 9:17 PM UTC

andr wrote: post #38

What explains the vast price difference between App Engine standard and flexible environment? In the standard environment, $0.05/hr gives me a 128MB, 600MHz container. Flexible environment is priced at GCE pricing, giving me 3.75GB and 1 vCPU for the same price, before even applying committed use discounts. It seems hard to justify using the standard environment, even if scaling up/down is faster.

That is a very good question.

Another thing to note is that GAE standard api does not work in Flex or GCE (no portable api for datastore, memcache, runtime apis for versions and modules, etc.) So basically any code that you write in standard gae is locked in.

Another interesting note is that standard gae is covered in free tier but flex is not covered in free tier.

It seems like google is trying to lock you in with standard gae and then make you pay order of magnitude more for the infrastructure once your service gets some traction.

Re: Beta release of PHP 7.2 in the Google App Engine standard environment

#59

Post by chrisbroadfoot » Tue, Aug 21, 2018, 9:23 PM UTC

zinclozenge wrote: post #53

sayhello wrote: post #16

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

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

Yes.

Re: Beta release of PHP 7.2 in the Google App Engine standard environment

#60

Post by hencq » Tue, Aug 21, 2018, 9:30 PM UTC

mehrdada wrote: post #21

sayhello wrote: post #16

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

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

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.