
Beta release of PHP 7.2 in the Google App Engine standard environment - sl0wik
https://cloud.google.com/appengine/docs/standard/php7/
======
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

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

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

------
avolcano
The state of App Engine environments seems super confusing, but I _think_ this
uses the "second generation standard environment" like the Python 3.7 and Node
8 beta environments, which means that unlike App Engine of Yore, you have
access to the full package ecosystem and full network access. I'm not actually
100% sure on this because it's not listed on the runtime page
([https://cloud.google.com/appengine/docs/standard/appengine-g...](https://cloud.google.com/appengine/docs/standard/appengine-
generation)), but the docs show that you can use composer, unlike the PHP 5.5
runtime.

The documentation for all these second generation runtimes is shockingly bad.
I consider Google to be _generally_ pretty good at documentation, but this is
one of those cases where their propensity for confusing naming and
classification of their products makes it hard as hell to figure out what is
going on. It doesn't help that the top-level "product overview" page is
useless marketing junk (microservices! serverless!) instead of a practical
description, which is buried several links deep.

Having never used App Engine but occasionally wandering into its docs when a
new product gets announced like this, am I right in assuming that App Engine's
"second generation standard environment" is more or less equivalent to the
feature set you'd get from Heroku? The flexible environment also continues to
confuse me - it talks about being a managed Docker container, but it doesn't
seem like you actually get access to anything like a Dockerfile and that's
more of an implementation detail on their end.

~~~
kylecordes
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 temporarily - there is a lot of genius in
the original GAE.

~~~
floatboth
genius… or vendor lock-in?

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

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

------
sl0wik
For those not familiar with benefits, it's mainly about scaling from zero to
heavy traffic fast. If for example, you are running CRM behind call center
with crazy traffic during TV ads, and no traffic on weekend your
infrastructure can scale from 0 to multiple instances instantly.

------
kyrra
This is on the heels of the Python 3.7 AppEngine release from 2 weeks ago[0].
gVisor[1] (user-space kernel) seems to be ready for prime time, which is
allowing rolling out new AppEngine runtimes waaay faster.

[0]
[https://news.ycombinator.com/item?id=17717045](https://news.ycombinator.com/item?id=17717045)

[1] [https://github.com/google/gvisor](https://github.com/google/gvisor)

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

~~~
cloud-is-future
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.

~~~
thesandlord
Gen1 Standard used proprietary GAE APIs that locked you in.

Gen2 Standard (PHP7, Node8, Java8, Python3, etc) uses the standard GCP APIs
that you can call from anywhere, including other clouds. It should be
relatively straightforward to move from Gen2 Standard to Flex and vice versa.

(I work for GCP)

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

~~~
mattlondon
AppEngine is a "Platform as a Service" although they are re-phrasing it as
"serverless" these days. It has benefits like you dont have to worry about the
"roll your own" side of things - you just deploy your code and it runs (Google
takes care of the servers - patches, security etc).

The "killer" feature of AppEngine is the scalability - i.e. your small-scale
virtual or shared servers are ok for small usage, but what happens when you
have more traffic than that VPS can handle? Perhaps call the hosting provider
and ask for more CPU/Mem/Bandwidth, or maybe move to a new bigger server
elsewhere. But that takes time, and what if it was just a spike and now your
traffic is back to normal but you've got a beast of a server running the site.
You could be wasting money even with the small VPS sitting idle for most of
the day if you have very infrequent traffic.

With AppEngine it just scales automatically to handle the load, from zero QPS
to many thousands QPS and back down to zero again without any effort from the
developer apart from the initial config (... of course you can limit that
scaling too if you want to control cost).

There are also a bunch of other nice-to-have features around traffic splitting
(i.e. A/B testing), some nice task-handling tools (e.g. cron-style stuff, task
queues), centralised logging, and the easy plug-ins to the other Google Cloud
stuff.

Deployments themselves are not especially "quick" and you have to do a few
things "the appengine way", but the trade-off is you have nothing to manage on
the server _at all_.

I've used AppEngine a lot over the past few years (mainly Java and Go) and its
pretty decent I've found, although I do use a lot of the other Google Cloud
services (e.g. their database stuff) so it makes sense. App Engine has been
pretty rock solid in my experience.

~~~
skybrian
I'll add that the "free tier" makes it a great place to host hobby apps that
get little traffic without paying a monthly fee. They are very stable; I've
only had to upgrade every five years or so.

------
arttii
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 with a lot of hidden limitations for a
newcomer, but at the same time the developer story for Lambda is not that
great at all.

~~~
LolNoGenerics
Not sure why you compare GAE to lambda?

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

~~~
elyobo
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/](https://serverless.com/)

------
vgy7ujm
Now if they only would support Perl...

~~~
zerr
6

------
merb
now .net core in standard environment!

------
bborud
I feel slightly queasy :-)

~~~
sandrob57
You should see a doctor if it doesn't go away :-)

