Live data from Hacker News

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

cloud.google.com

41–50 of 70 posts

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

#41
post #6

Excuse my complete and total ignorance here - but is this essentially a 'quick deploy' php instance? if so, what might a none-Google alternative be? I've only ever 'rolled my own', on small-scale virtual or shared servers, but I've got an upcoming project I could do with trying to install on something completely seperate - something like this might fit the bill. Or not! Thanks.

[deleted]

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

#42
post #39

Earlier quoted context omitted.

Disclosure: I work for Google on the App Engine team doing documentation. Firstly, a sincere thank you for reading and caring about our documentation. With regards to the page you referenced, would you please elaborate on what information would help you come to the appropriate conclusion about using a second generation runtime? Your feedback would be very useful to us in order to shape this page into something that p…

Hi, I couldn't agree more with the parent comment about the AppEngine docs. I built a fairly small app and it was utterly excruciating to sort out the nuances. There should be right up front, a crystal clear page detailing the three possible environments. - Legacy Standard (WITH A VERY CLEAR DEPRECATION NOTICE) - Legacy Flexible (WITH A VERY CLEAR DEPRECATION NOTICE) - Standard Second Generation GVisor For example, i…

> For example, in Python Standard (old standard), it's extremely confusing to work out which gcloud libraries are bundled, and which need to be vendored

I agree. I spent a lot of time trying to figure this out myself with various APIs, and in some instances, I gave up and looked for an alternative after I failed to figure out how to correctly vendor some Google Cloud libs (even following what documentation I did find, which made it look so simple).

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

#45

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

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

#46
post #22

I was wondering what people generally think on using AppEngine when compared to rolling the API gateway+Lambda for public side projects. Somehow there seems to be much more movement on Lambda front, but I can't seem to find a lot of opinions from people running their apps in app engine, which I am quite sure there are more than Lambda? Or am I mistaken? The standard environment seems to be quite feature rich, but wit…

Not sure why you compare GAE to lambda?

Well lambda+API gateway is somehow what AWS is pushing in the serverless, scalable and pay per use app model, so for me it seems quite logical to compare. Cloud functions can't really compete feature set and integration wise in my opinion.

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

#47

Earlier quoted context omitted.

For the moment, unfortunately it appears this second generation also lacks some of the great parts of the older platform. For example, with the shiny new GAE Standard Node Beta, you can't declaratively put your app behind authentication, you can't access the (extraordinarily useful) work queue feature from the older GAE, and probably more I have forgotten about for the moment. I hope that stuff is missing just tempor…

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

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

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

Standard scales down to zero instances, so for intermittent loads this can be very cost efficient.

I ran in to a couple of show stopper issues with the new nodejs standard env which were fine in flex (waiting on Google support on these, but very slow datastore queries and odd request queueing behaviour), so we're running flex at the moment, but for our particular use case standard would otherwise be cheaper.

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

#50
post #46

Earlier quoted context omitted.

Not sure why you compare GAE to lambda?

Well lambda+API gateway is somehow what AWS is pushing in the serverless, scalable and pay per use app model, so for me it seems quite logical to compare. Cloud functions can't really compete feature set and integration wise in my opinion.

AWS's offering is more mature, but has a concomitantly steep learning curve; using something like serverless[1] can reduce the exposure to that, but there's a lot of stuff to learn to get things working nicely with AWS.

[1] https://serverless.com/

Post reply on HN