11–20 of 70 posts
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.
I feel slightly queasy :-)
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.
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
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…
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.
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
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…
You're right that you don't get access to the Dockerfile. Docker isn't a 100%-isolated environment for multitenant use-cases, so Google needs to control the stack themselves, using specific trusted versions of base-image layers and app layers. There's maybe extra "Docker-image compile time" security restrictions made on top of that as well.
However, it's not just an implementation detail—it has pretty visible effects.
1. A Flexible Environment app slug gets baked into a regular Docker image and placed into your Google Container Registry alongside container-images you've built yourself with GCR. (And your GCR registry, in turn, is backed by a Google Cloud Storage bucket in your own account—meaning that you're paying for storing the resulting images just like any other uploaded objects. You should prune old App Engine Flexible Environment image versions if you don't want to pay!)
2. You can do whatever you want with the filesystem of your container, because it is just a Docker container. You can mount volumes to the container in the container spec (app.yaml), just like if you were writing a k8s container spec. (In fact, sharing IPC sockets through a Docker volume-mount is how the Google Cloud SQL proxy works.) You can internally auto-update your container by downloading new Python/Node/etc. code into the container and getting the interpreter to re-exec(2) itself. Pretty much anything that can run in a "Python Docker container environment" can run in Google's "Python Flexible Environment", because they're pretty much the same (save for those container-build-time security restrictions.)
I feel slightly queasy :-)