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 a Linux x86_64 binary.
I've been thinking of using this approach for a golang MMO game SaaS which is really an aggregation of a bunch of FaaS lambdas tied to an account. What upload allows you to do, is to do a syntactic scan of all of the code, particularly the package imports and function calls. All of the above can be whitelisted, which adds security. Also, you can munge the function calls against a generated munged version of the available libraries, which also adds security. (In addition to using containers under the covers.)
What I'm describing is for implementing MMOs, though.
The toolchain is completely unmodified.
Disclaimer: I work at GCP and worked on this product.
AWS announced 'native' Golang support last year - since then there hasn't been a need to use a Python or node 'shim' to bootstrap the golang executable like this. You just upload your compiled binary to S3 and provide the path to AWS lambda
Both tools are necessary for fast engineering, but in different contexts.
A lot of developers have this preference for client side code. Since the early days heroku has been building the client side bundles for rails.
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)
* We've been running a private early access preview/alpha since last August.
* This was our first compiled language on Cloud Functions, which came with its own set of challenges.
* It took us a while to find the right approach for supporting dependencies (both Go Modules and vendoring are supported). Unlike other providers, when you deploy your source code, Cloud Functions will automatically install dependencies listed in your go.mod file.
* Our testers gave us a ton of feedback that helped us polish the developer experience -- we identified and fixed many rough edges related to error messages during deployment/build and errors at runtime. Serverless products can be a bit opaque (since you can't just ssh into a machine), so getting this right is important.
I'd like to say that there was one big, interesting challenge that we had to tackle. But the reality is that we worked through many small details that only became apparent during testing. We wanted to address these so that we could offer a high quality experience for our public beta launch. We owe our alpha testers major credit for helping us find and solve issues.
Speaking of testers -- if you have feedback on the runtime, we'd love to hear from you in our Cloud Functions Beta Tester group .
Why wouldn't the binary be the deployed unit in this case?
We're working on arbitrary binary deployments, you can sign up for that here:
Disclaimer: I work on GCP.
For what it's worth, if you have an onUpdate trigger on a Firestore database, the event you receive has the before & after state of the change, which would include field-level changes: https://firebase.google.com/docs/functions/firestore-events#...
Is there a specific use-case that this doesn't handle for you?
Note: Work at GCP, not on Functions.
My use-case is simple. Want to get my CF triggered if the value of a particular field in a doc changes. Thanks.
As for making that an actual product, we're working on that, too. Sign up for the alpha here:
If you didn't mean Go, specifically, then the alpha I linked above might be up your alley.
For long-term support of various languages, see the GCP deprecation policy: https://cloud.google.com/terms/deprecation
Especially this sentence: "excluding [...] support for a programming language version that is no longer publicly supported by, or receiving security updates from, the organization maintaining that programming language"
So, that means we're committed to supporting the two most recent major version releases of Go, as per the Go release policy: https://github.com/golang/go/wiki/Go-Release-Cycle#release-m...
Disclaimer: I work on GCP and used to work on Go language releases.
If you just want to execute your function, create another package main and start an HTTP server, as you'd normally do.
There are some examples on this page:
We're thinking about ways to improve the local development/testing story, and are keen to hear any ideas/feedback.
Disclaimer: I work at Google, and worked on this product.
I work at GCP and on this project.
Would like to see some more runtimes/languages. I'm hoping AWS' recent layers implementation has made this more of a focus at Google. I'm curious how the implementation of Go has affected the ease of integrating other languages.
In some ways, it helps. You start to see similar issues arise and know what to look out for when you're launching a new runtime. In other ways, every language has its peculiarities and its own set of design considerations.
Launching/polishing a completely new language still takes a decent amount of work. Launching a new version of an existing language tends to be much quicker.
Maybe even just something for compiled languages like Go, Crystal, etc that will just run the binary?
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.
Does this mean we actually run the container ourselves on our GKE cluster or in a VM? Or do you mean a "container" runtime for Cloud Functions? Both would be interesting, but we'd prefer the latter since there would be less to manage. I'd be interested to see the performance of it.
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.
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.
There's already a publish step, so it can be automatic.
If all I want is an HTTP endpoint somewhere, I'm actually not sure why I'd want a serverless container when a stand alone .js file does the trick.
So, if for your particular application, Go has a faster startup/cold start time than Python or Node, then yes, it'll be faster, overall.
Very difficult to speak about performance in general terms, though.
I will say that there is no kind of wrapper library or wrapper runtime like some other serverless platforms might depend on.
This post is specifically about Google Cloud Functions, not Go 1.11 in general (which is over 6 months old).
edit: thanks, mods!
And me thinking the days of C compilers with 10 character limit for identifiers on the symbol table was long gone.
You’re still free to name the entry function whatever you prefer to match the styles and engineering practices of your organization :)
Disclaimer: I work at Google, but not on GCF or Go.
Thanks for the heads up.
The second paragraph there is more in line with best practice...
"The basic rule: the further from its declaration that a name is used, the more descriptive the name must be. For a method receiver, one or two letters is sufficient. Common variables such as loop indices and readers can be a single letter (i, r). More unusual things and global variables need more descriptive names."
In the case of a Cloud Function, a short name like "F" is probably fine. While it needs to be exported to get deployed properly, it isn't a library function, is very unlikely to be imported by other packages, so it's really more like "func main" than anything.
Most people will have a single Cloud Function in a package, and I don't think you'd reasonably have f/f.go with a function named "F".