31–40 of 70 posts
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…
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…
So far I've been billed $0.00. The free tier is quite generous, and probably plenty for most low traffic endeavors.
Earlier quoted context omitted.
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!
> 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.
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.
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…
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.
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/stand…
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…
My main complaint about the marketing landing page at https://cloud.google.com/appengine/ is that it doesn't contain any immediate information about the different environments. It does have a link to "Choosing the right Environment" but it's _waaay_ down below the fold. In general I wish Google Cloud product pages had their big "View Documentation" buttons up at the top next to the free trial button, instead of way down below the pricing section.
In addition, neither the "Choosing the right Environment" nor the "App Engine Standard Environment" docs linked at the bottom of the product page contain detailed information about the second-generation standard environment, which is frustrating. I do appreciate that the language-specific pages in the main docs link contain a short comparison that includes the beta environments, at least.
That said, the primary document comparing the environments (https://cloud.google.com/appengine/docs/the-appengine-enviro...) seems very out of date. For example, it mentions you should use the flexible environment if your app:
> Depends on other software, including operating system packages such as imagemagick, ffmpeg, libgit2, or others through apt-get.
However, the Node standard environment contains these three packages and more (https://cloud.google.com/appengine/docs/standard/nodejs/refe...).
There might be other nit-picks to be said, but really, my main criticism of the documentation is that trying to understand the split between "standard/flexible/second-generation standard" environments at first glance is tricky. I'm sure y'all have plans for this going forward as these environments come out of beta, so I'll hold off on whining too much more. Thanks for asking for further feedback, and for clarifying that the new PHP runtime is a second generation one.
Earlier quoted context omitted.
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!
> 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.
> 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.
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/stand…
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…
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, in Python Standard (old standard), it's extremely confusing to work out which gcloud libraries are bundled, and which need to be vendored and packaged into the app (yes I know there is a page that tries to explain. It's unclear).
Thank you for working on the documentation. It is the number one area that GCP needs to invest in. All the technology is miles ahead of AWS in the core areas. The docs however, are very very far behind.
Happy to elaborate more if there's any specifics you need.
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/stand…
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…
I suspect yes, but the last time I checked the Cloud IAP docs (for GAE standard's recent Python 3.7 launch) they didn't yet address the unique situation of second-generation App Engine standard environment runtimes.