8 ms·

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

185 points by sl0wik 8y ago

detritus 8y ago
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.
- nolok 8y ago
  What specific problem are you're not sure how to solve the right way ? Compared to some other language a proper PHP env is relatively dumb to set up, have a build script in your system of choice to install fcgi PHP in the version you need and the extensions you expect and setup the relatively simple conf file in your browser of choice, and then have a composer file to setup the libraries you need, tada you're pretty much down (everything else is not very much PHP specific)
- mattlondon 8y ago
  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 8y ago
    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.
  - LolNoGenerics 8y ago
    Good run down what GAE offers. The point I'd like to add and emphasise on is zero downtime deploys.
  - detritus 8y ago
    Thank you very much for your response here, fellow LDNer - it's illuminated a domain I had completely overlooked for years!
- meritt 8y ago
  Laravel Forge [1] offers what you're after though I'm not entirely sure it's worth the added cost imo. [1] https://forge.laravel.com/features https://forge.laravel.com/features
  - wolco 8y ago
    Forge is a laravel only platform and doesn't scale automatically. It is more useful for maintaining a standard deployment process for your laravel application. It made setting up queues / redis / mongo a breeze when we onboarded new employees.
    - meritt 8y ago
      > Forge is a laravel only platform That's incorrect. The page says: "We don’t discriminate: Laravel, Symfony, WordPress, Statamic, Craft and any other PHP application can easily be installed on a Forge server." > doesn't scale automatically That's true but I the person to whom I was responding isn't looking for auto-scaling (nor am I presenting it as a GAE competitor). It sounds like he just wants a button to push that'll create a fully operational PHP app server.
      - wolco 8y ago
        If you wanted say wordpress cpanel hosting will provide a one click button, auto update plus allow you install most popular php software packages easily. Paying 10 or more dollars a month probably doesn't make a lot of sense unless you are installing laravel and for some reason can't do it yourself.. Or if you need to replicate the process. It is not really one button click either you need to find/create the right script(s) if you are doing anything complex and if you are not just have the developers get a copy of the app from github and clone a dev box on digitalocean.
- mediascreen 8y ago
  Non Google alternatives are for example AWS Elastic Beanstalk or Heroku.
- brightball 8y ago
  There's always Heroku too.
- deleted 8y ago
  [deleted]
- deleted 8y ago
  [deleted]
- detritus 8y ago
  Thank you for all your responses here - I am red-faced with shame to realise I'd for years completely ignored exactly what containers are and associated terms such as 'Heroku' or 'Kubernetes' I'd simply assumed they were curious alien creatures, completely irrelevant to me! After a long journey down various rabbit holes last night, where I at points got quite excited by the idea of leveraging Heroku with perhaps a soupçon of Cloudflare in the background or AWS' myriad of services, I ended up back where I've always been, and think I'll stick with what I know for my upcoming project. However, I think this'd be a great way to dabble in things I really don't have any famiiarity with (eg. Ruby), so I'll have a play yet. Thanks, all!
bborud 8y ago
I feel slightly queasy :-)
- sandrob57 8y ago
  You should see a doctor if it doesn't go away :-)
- cam3ham 8y ago
  This is awesome!
- wolco 8y ago
  Are you sure you found the right thread? Your comment seems more related to the panic attack thread.
kyrra 8y ago
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
avolcano 8y ago
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-generation https://cloud.google.com/appengine/docs/standard/appengine-g...), 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 8y ago
  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 8y ago
    genius… or vendor lock-in?
    - 8y ago
sl0wik 8y ago
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.
sayhello 8y ago
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
- mehrdada 8y ago
  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 https://www.google.com/search?q=define%3ADisclaimer
  - sayhello 8y ago
    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 8y ago
      > 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.
      - jgtrosh 8y ago
        Instead, could they not be dis-claiming their objectivity?
arttii 8y ago
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 8y ago
  Not sure why you compare GAE to lambda?
  - arttii 8y ago
    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 8y ago
      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/
- H1Supreme 8y ago
  I've used App Engine for side projects, and small personal projects that only I use. It's great. I've wrote mostly everything in Go, and a little Python. So far I've been billed $0.00. The free tier is quite generous, and probably plenty for most low traffic endeavors.
saksham7896 8y ago
Heard it on google cloud blog. Getting better each day
- saksham7896 8y ago
  https://colorsofblog.com https://colorsofblog.com
andr 8y ago
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.
- elyobo 8y ago
  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.
- cloud-is-future 8y ago
  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 8y ago
    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)
merb 8y ago
now .net core in standard environment!
vgy7ujm 8y ago
Now if they only would support Perl...
- zerr 8y ago
  6
guilingmaster 8y ago
check this out. https://pastebin.com/NGUVe7zi https://pastebin.com/NGUVe7zi

185 points by sl0wik 8y ago

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.

nolok 8y ago
What specific problem are you're not sure how to solve the right way ? Compared to some other language a proper PHP env is relatively dumb to set up, have a build script in your system of choice to install fcgi PHP in the version you need and the extensions you expect and setup the relatively simple conf file in your browser of choice, and then have a composer file to setup the libraries you need, tada you're pretty much down (everything else is not very much PHP specific)
mattlondon 8y ago
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 8y ago
  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.
- LolNoGenerics 8y ago
  Good run down what GAE offers. The point I'd like to add and emphasise on is zero downtime deploys.
- detritus 8y ago
  Thank you very much for your response here, fellow LDNer - it's illuminated a domain I had completely overlooked for years!
meritt 8y ago
Laravel Forge [1] offers what you're after though I'm not entirely sure it's worth the added cost imo. [1] https://forge.laravel.com/features https://forge.laravel.com/features
- wolco 8y ago
  Forge is a laravel only platform and doesn't scale automatically. It is more useful for maintaining a standard deployment process for your laravel application. It made setting up queues / redis / mongo a breeze when we onboarded new employees.
  - meritt 8y ago
    > Forge is a laravel only platform That's incorrect. The page says: "We don’t discriminate: Laravel, Symfony, WordPress, Statamic, Craft and any other PHP application can easily be installed on a Forge server." > doesn't scale automatically That's true but I the person to whom I was responding isn't looking for auto-scaling (nor am I presenting it as a GAE competitor). It sounds like he just wants a button to push that'll create a fully operational PHP app server.
    - wolco 8y ago
      If you wanted say wordpress cpanel hosting will provide a one click button, auto update plus allow you install most popular php software packages easily. Paying 10 or more dollars a month probably doesn't make a lot of sense unless you are installing laravel and for some reason can't do it yourself.. Or if you need to replicate the process. It is not really one button click either you need to find/create the right script(s) if you are doing anything complex and if you are not just have the developers get a copy of the app from github and clone a dev box on digitalocean.
mediascreen 8y ago
Non Google alternatives are for example AWS Elastic Beanstalk or Heroku.
brightball 8y ago
There's always Heroku too.
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
detritus 8y ago
Thank you for all your responses here - I am red-faced with shame to realise I'd for years completely ignored exactly what containers are and associated terms such as 'Heroku' or 'Kubernetes' I'd simply assumed they were curious alien creatures, completely irrelevant to me! After a long journey down various rabbit holes last night, where I at points got quite excited by the idea of leveraging Heroku with perhaps a soupçon of Cloudflare in the background or AWS' myriad of services, I ended up back where I've always been, and think I'll stick with what I know for my upcoming project. However, I think this'd be a great way to dabble in things I really don't have any famiiarity with (eg. Ruby), so I'll have a play yet. Thanks, all!

bborud 8y ago

I feel slightly queasy :-)

sandrob57 8y ago
You should see a doctor if it doesn't go away :-)
cam3ham 8y ago
This is awesome!
wolco 8y ago
Are you sure you found the right thread? Your comment seems more related to the panic attack thread.

kyrra 8y ago

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

avolcano 8y ago

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-generation https://cloud.google.com/appengine/docs/standard/appengine-g...), 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 8y ago
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 8y ago
  genius… or vendor lock-in?
  - 8y ago

sl0wik 8y ago

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.

sayhello 8y ago

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

mehrdada 8y ago
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 https://www.google.com/search?q=define%3ADisclaimer
- sayhello 8y ago
  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 8y ago
    > 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.
    - jgtrosh 8y ago
      Instead, could they not be dis-claiming their objectivity?

arttii 8y ago

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 8y ago
Not sure why you compare GAE to lambda?
- arttii 8y ago
  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 8y ago
    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/
H1Supreme 8y ago
I've used App Engine for side projects, and small personal projects that only I use. It's great. I've wrote mostly everything in Go, and a little Python. So far I've been billed $0.00. The free tier is quite generous, and probably plenty for most low traffic endeavors.

saksham7896 8y ago

Heard it on google cloud blog. Getting better each day

saksham7896 8y ago
https://colorsofblog.com https://colorsofblog.com

andr 8y ago

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.

elyobo 8y ago
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.
cloud-is-future 8y ago
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 8y ago
  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)

merb 8y ago

now .net core in standard environment!

vgy7ujm 8y ago

Now if they only would support Perl...

zerr 8y ago
6

guilingmaster 8y ago

check this out. https://pastebin.com/NGUVe7zi https://pastebin.com/NGUVe7zi