Re:Cloud Functions: Go 1.11 is now a supported language
by benatkin on Wednesday January 16, 2019 @05:08PM
(#18925955)
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.
[ Parent
| on HN ]
Re:Cloud Functions: Go 1.11 is now a supported language
by skywhopper on Wednesday January 16, 2019 @09:44PM
(#18927859)
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.
Re:Cloud Functions: Go 1.11 is now a supported language
by benatkin on Thursday January 17, 2019 @12:53AM
(#18928695)
Fair enough, but I don't think it's wrong to want a PaaS/FaaS that automagically compiles things. You'll be hard pressed to convince anyone who genuinely likes this approach to switch over to having their IDE, developer tools, or CI do it.
Re:Cloud Functions: Go 1.11 is now a supported language
by ricktdotorg on Thursday January 17, 2019 @03:03AM
(#18929160)
the Cloud Functions emulator works well, and helps https://cloud.google.com/functions/docs/emulator
Re:Cloud Functions: Go 1.11 is now a supported language
by rakoo on Thursday January 17, 2019 @09:47AM
(#18931087)
Then again, what's the point of controlling your own repository of binaries if their only goal in life is to be deployed somewhere else anyway ? It's much easier to just cut the middleman.
Re:Cloud Functions: Go 1.11 is now a supported language
by omeid2 on Wednesday January 16, 2019 @08:25PM
(#18927490)
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
by solatic on Thursday January 17, 2019 @10:27AM
(#18931435)
CI is a continuous integration tool. There are inherent latencies to committing, pushing, deploying to AWS, running tests. Mature development tooling, if it's not REPL-based, will at least allow a local debugger to step through the code compiled/run locally, without these remote latencies.
Both tools are necessary for fast engineering, but in different contexts.
Re:Cloud Functions: Go 1.11 is now a supported language
by benatkin on Wednesday January 16, 2019 @08:52PM
(#18927629)
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
by weberc2 on Wednesday January 16, 2019 @09:07PM
(#18927677)
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
by vira28 on Wednesday January 16, 2019 @06:59PM
(#18926928)
If i understand correctly the binary is created from the source code right. Am i missing anything?
Re:Cloud Functions: Go 1.11 is now a supported language
by benatkin on Wednesday January 16, 2019 @08:22PM
(#18927470)
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
by st3fan on Wednesday January 16, 2019 @07:27PM
(#18927167)
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 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)
Re:Cloud Functions: Go 1.11 is now a supported language
by nikki93 on Wednesday January 16, 2019 @07:49PM
(#18927306)
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
by weberc2 on Wednesday January 16, 2019 @09:10PM
(#18927694)
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
by saagarjha on Wednesday January 16, 2019 @11:57PM
(#18928495)
Not a whole lot, though. A determined reverse engineer will likely be able to grab something close to your source code without much difficulty, assuming you haven't applied any wacky obfuscation.