61–70 of 107 posts
Isn't this all about to be replaced by serverless containers? With FaaS deployments just taking docker containers or building your code into one when you upload? Why the continued work on a one-off runtime and http response spec instead?
Isn't this all about to be replaced by serverless containers? With FaaS deployments just taking docker containers or building your code into one when you upload? Why the continued work on a one-off runtime and http response spec instead?
It's simpler to just write code, rather than have to try to set up a container.
There's already a publish step, so it can be automatic.
One thing that is not super clear from the blog post, and which may be a surpsise to some, is that Cloud Functions will require you to upload your source code. The compilation happens not on your end but on Google servers. This is probably not a surprise for folks who have been using Python or Node for cloud functions, but it is something to think about. Other FaaS providers don't have this requirement, and just take…
Earlier quoted context omitted.
Although I've never used Lambda Layers. Do you think a similar approach is something that could be implemented? Maybe even just something for compiled languages like Go, Crystal, etc that will just run the binary?
It's definitely something that we've discussed. Would you consider running a container that could be run like Cloud Functions? This container could run the binary that you create. It's not something that we support today but I'm curious whether this would meet your needs.
This is something Cloud Native Buildpacks (buildpacks.io) are intended to make easy. We hang out on buildpacks.slack.com, if you'd like to come pick our brains.
Isn't this all about to be replaced by serverless containers? With FaaS deployments just taking docker containers or building your code into one when you upload? Why the continued work on a one-off runtime and http response spec instead?
Maybe soon, maybe later, maybe never. But it makes sense for a company of Google's size to keep working on the current things they have. Otherwise you wind up with an Osborne Effect and/or frustrated customers.
Earlier quoted context omitted.
Does this effort take you closer to the (supposed) goal of running arbitrary X86/ARM Linux binaries as cloud functions, or is that a completely different direction?
At the sandboxing level, it's already possible (you can upload any binary and fork/exec it from one of the supported languages). That's made possible by gVisor, which is the underlying sandbox technology used in GAE and GCF. As for making that an actual product, we're working on that, too. Sign up for the alpha here: g.co/serverlesscontainers Disclaimer: I work on GCP.
Earlier quoted context omitted.
At the sandboxing level, it's already possible (you can upload any binary and fork/exec it from one of the supported languages). That's made possible by gVisor, which is the underlying sandbox technology used in GAE and GCF. As for making that an actual product, we're working on that, too. Sign up for the alpha here: g.co/serverlesscontainers Disclaimer: I work on GCP.
Do you know of any alphas running for App Engine? I'm interested in testing.
https://cloud.google.com/blog/products/application-developme...
If you didn't mean Go, specifically, then the alpha I linked above might be up your alley.
One thing that is not super clear from the blog post, and which may be a surpsise to some, is that Cloud Functions will require you to upload your source code. The compilation happens not on your end but on Google servers. This is probably not a surprise for folks who have been using Python or Node for cloud functions, but it is something to think about. Other FaaS providers don't have this requirement, and just take…
This is a much better solution, I think. Uploading your source code is often easier than uploading your binaries. If, for example, you have a new contributor you don't yet trust creating a cloud function in Go and you know enough Go to review the code, but it's not convenient for you to compile it yourself, you can just upload the code yourself. You can't easily review the binary.
One thing that is not super clear from the blog post, and which may be a surpsise to some, is that Cloud Functions will require you to upload your source code. The compilation happens not on your end but on Google servers. This is probably not a surprise for folks who have been using Python or Node for cloud functions, but it is something to think about. Other FaaS providers don't have this requirement, and just take…
This is a much better solution, I think. Uploading your source code is often easier than uploading your binaries. If, for example, you have a new contributor you don't yet trust creating a cloud function in Go and you know enough Go to review the code, but it's not convenient for you to compile it yourself, you can just upload the code yourself. You can't easily review the binary.
Uploading source code is a dealbreaker for me because I do not trust Google or myself. Google probably has language in their terms that they may do whatever they want with anything you upload to them.
I also do not trust myself to properly configure security parameters around this with the risk of leaking source code.
Binaries are a great strength of Go. Too bad this platform doesn't use them. I will take a peek at the new Container platform that they are building, but that sounds more heavyweight, which probably comes with a higher price. (I have not seen any actual pricing)