Cloud Functions: Go 1.11 is now a supported language • Hacker News Board

Re: Cloud Functions: Go 1.11 is now a supported language

#71

Post by stcredzero » Thu, Jan 17, 2019, 12:48 AM UTC

st3fan wrote: post #55

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…

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.

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.)

Re: Cloud Functions: Go 1.11 is now a supported language

#72

Post by nikki93 » Thu, Jan 17, 2019, 12:49 AM UTC

st3fan wrote: post #70

benatkin wrote: post #63

Earlier quoted context omitted.

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.

I don't really understand what you are saying here .. It should not be difficult to run `go build` locally and then tell a tool to upload `foobar` instead of `main.go`. 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 s…

can't your security params be read out of the binary in any case? i'm not sure how binaries offer more security.

Re: Cloud Functions: Go 1.11 is now a supported language

#73

Post by benatkin » Thu, Jan 17, 2019, 1:22 AM UTC

vira28 wrote: post #69

benatkin wrote: post #63

Earlier quoted context omitted.

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.

If i understand correctly the binary is created from the source code right. Am i missing anything?

On AWS Lambda, which has had Go support for almost a year now, you upload the binary, which you create from the source code on your own system, using the go compiler. On Google Cloud Functions, you upload the source code and Google's servers build it.

Re: Cloud Functions: Go 1.11 is now a supported language

#74

Post by omeid2 » Thu, Jan 17, 2019, 1:25 AM UTC

benatkin wrote: post #63

st3fan wrote: post #55

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.

Your code review and deployment pipeline should be all automated from day zero. Setting up a CI pays off in the first couple of days in terms of time investment and massive returns on longer term mostly for avoiding human error and confusions that ensues.

Re: Cloud Functions: Go 1.11 is now a supported language

#75

Post by com2kid » Thu, Jan 17, 2019, 1:35 AM UTC

manigandham wrote: post #59

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?

If you need to setup some stand alone functions, this is a great way to do it. I run quite a few utility functions like this, they are simple to write and deploy.

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.

Re: Cloud Functions: Go 1.11 is now a supported language

#76

Post by benatkin » Thu, Jan 17, 2019, 1:52 AM UTC

omeid2 wrote: post #74

benatkin wrote: post #63

Earlier quoted context omitted.

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.

Your code review and deployment pipeline should be all automated from day zero. Setting up a CI pays off in the first couple of days in terms of time investment and massive returns on longer term mostly for avoiding human error and confusions that ensues.

I didn't say that you don't need CI. I use CI regularly, and I think it's best for CI to be for testing, and to minimize the build artifacts except those used for test results.

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.

Re: Cloud Functions: Go 1.11 is now a supported language

#77

Post by weberc2 » Thu, Jan 17, 2019, 2:07 AM UTC

benatkin wrote: post #76

omeid2 wrote: post #74

Earlier quoted context omitted.

Your code review and deployment pipeline should be all automated from day zero. Setting up a CI pays off in the first couple of days in terms of time investment and massive returns on longer term mostly for avoiding human error and confusions that ensues.

I didn't say that you don't need CI. I use CI regularly, and I think it's best for CI to be for testing, and to minimize the build artifacts except those used for test results. 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.

The parent’s point was that contributors shouldn’t have permissions to upload binaries; they only commit source code and your CI infrastructure compiles, releases, and deploys it.

Re: Cloud Functions: Go 1.11 is now a supported language

#78

Post by weberc2 » Thu, Jan 17, 2019, 2:10 AM UTC

nikki93 wrote: post #72

st3fan wrote: post #70

Earlier quoted context omitted.

I don't really understand what you are saying here .. It should not be difficult to run `go build` locally and then tell a tool to upload `foobar` instead of `main.go`. 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 s…

can't your security params be read out of the binary in any case? i'm not sure how binaries offer more security.

His post is super unclear but I think he is concerned about someone getting their hands on his source code. In general, a compiled Go binary is not trivial to reverse engineer, so there’s some security through obscurity there.

Re: Cloud Functions: Go 1.11 is now a supported language

#79

Post by skywhopper » Thu, Jan 17, 2019, 2:43 AM UTC

st3fan wrote: post #55

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…

I was wondering about this, given the examples. AWS's Golang support for Lambda involves including their library and passing your function to a Lambda initializer function. Which I'm sure is all that's happening with this, but it's weird to hand off the Go source to Google. I wonder if they are multiplexing multiple functions in single binaries or using special Go toolchains. Or just don't want to lock into specific backends yet.

Re: Cloud Functions: Go 1.11 is now a supported language

#80

Post by skywhopper » Thu, Jan 17, 2019, 2:44 AM UTC

benatkin wrote: post #63

st3fan wrote: post #55

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.

The fact that it's easier to do things this way just shows how immature the toolchain surrounding serverless development is. It shouldn't be difficult to simulate the serverless environment on a workstation, and yet somehow that's a huge gap, even for Lambda.