Are those things true, or as significant as they sound? (Not being able to directly port my source to another service sounds quite risky...)
That’s ancient history, particularly with these recent launches, as Google Cloud has become a real platform.
This is vanilla node. You need not use Datastore, and can happily talk to a managed MySQL or Postgres instance via Cloud SQL (albeit sadly still via public IP and/or a proxy for now). The same is true of the recent Java 8 support, and will be true of all the new runtimes going forward (as mentioned downthread, the Google I/O talk is the best reference here).
Google Cloud Functions is similar, fwiw. You can even package up arbitrary binaries and exec them (ffmpeg is a favorite, as is imagemagick’s convert).
Node is JS, of course (with a different standard library). Did you perhaps mean to compare Node to python or something?
The new runtime is 100% idiomatic without any special apis. We do offer certain native libraries pre compiled system libraries (to support headless chrome among other things) and certain ENV Variables for gcp API tokens.
You should be able to lift and shift a GAE Standard Node.js app to any other provider with minimal overhead.
I can't make direct promises regarding the runtime update cadence, but I can promise that I work closely with the people responsible for this and they care a lot about getting updates out in a timely fashion. The new runtime stack makes this easier to do than previous GAE Standard runtimes.
(Disclaimer: I work for GCP)
By contrast, I deployed an app on Digital Ocean and, though they have a solid product, I eventually shut the instance down to avoid paying the monthly fee on an app I rarely used.
And you should stop telling others what works best for them without knowing anything about what their projects and needs are.
I'm pretty happy with using flexible environment for nodejs. However, the fact that this supports scaling to zero, and has headless chrome built-in, I could see using this for a low-cost headless Chrome environment.
I've had several projects where I've wanted a node server separate from the main app server on which I could use headless Chrome for pdf generation. It's never easy to justify the cost of an extra instance for that purpose. But with a zero scale capability, this could presumably be cheaper and easier to justify.
Would you like to be an alpha tester? Here's the sign-up form: https://docs.google.com/forms/d/e/1FAIpQLSfLXViTUmtY6Ed_Gm9H...
From various comments over the years here and elsewhere, I’ve been led to the understanding that Python 3 was “coming soon” several times.
1. Why now?
2. Is it true this time?
3. Will Python 3 keep up to date with new releases, or 5 years from now will we be stuck on 3.6?
4. What is the future and roadmap of AppEngine?
The feeling in the community is that AppEngine is another Google Reader, and death may be imminent. Can you reassure us?
5. What is the future of Standard and Flex?
Should all new projects be started on Flex?
Is standard ever going to keep up with language releases?
It is perfect for "hobby" projects that have no revenue today. If a "revenue strategy" emerges, it isofcourseeasy to enable billing but there is no 12 month $300 trial.
Historically supporting a language on App Engine required modifying the languages libraries to work on proprietary parts of Google infrastructure. This entailed a decent bit of effort on our part, and also meant that some apps & code wouldn't execute correctly.
We now use technology based on gVisor (https://github.com/google/gvisor) in production for App Engine standard. This allows us to release new language runtimes unmodified. Node.js support is the first runtime based on this new stack.
We completely agree that we should be releasing support for new languages & major versions more frequently...
However, I do have one question.
My app server currently polls another external endpoint periodically and does something based on the results. If I move it to standard will this still work? I assume not since it can scale to zero.
(I work for GCP)
I haven't seen anything like this for outbound connections though.
But it has nowhere near the features of Firebase Auth.
GCP free tier provides a lot more in comparison (app engine hours, cloud storage, memcache, pub/sub, cron, egress, cloud functions and more), but you have to be willing to tolerate the vendor lock-in.
Be sure to perform the build step before deploying.
It's really unclear from this what the security best practice is for where to put the Cloud SQL password.
Do we just assume the password is public info and rely on IAM?
This discusses really clunky methods to use the legacy datastore or a bucket to store a password.
Seems odd when competitors (Heroku, Beanstalk) have a special system for keeping environment variables with the password in.
I was playing with the flex environment with an express app (nothing special: cloud sql, cloud storage, etc). It ended up costing like ~$80 when I forgot to shut down a zero traffic dev instance for a month. It starts two instances by default and even if I set manual scaling to 1, it still costs like $40 a month. (I ended up going with a $5 VPS instead)
Is standard environment any cheaper? Curious about some real numbers for development and when deployed at scale.
But damn those free AWS credits !!!
Edit: just saw that OS has the right dependencies for running headless Chrome / puppeteer. This is huge. Because GAE Standard was always quite sandboxed.
Edit: For those also interested, here is the relevant issue https://github.com/GoogleCloudPlatform/google-cloud-node/iss...
This is helpful to people starting new projects. Using the Standard environment would cost significantly less than the Flexible environment which is one of the reasons I avoided GAE before.
This is being able to deploy regular NodeJS servers with no special changes or modifications, and have them run an autoscaling sandbox that does a really good job of keeping the server alive (and charging you) only when absolutely necessary. Also scales up infinitely (up to your budget, anyway) in a pinch.
App Engine is great for full HTTPS servers, and is billed on an instance basis (it does scale to zero when unused)
GCF is great for responding to events in the cloud (Pub/Sub, Storage, webhook, Firebase database) and is billed on a per function execution basis.
The actual runtimes are quite similar, though GCF is still Node 6 based for now.
Does cloud fumctions support node 8 yet? Will make life easier
Is there anything in particular that you'd like to know? E.g. performance, ootb tooling, etc?