<p>Just announced at re:Invent, Go becomes a first class citizen on Lambda.</p>
<hr/>**评论：**<br/><br/>emostafa: <pre><p>Do you guys find it weird that Google Cloud Functions doesn't support Go ? only nodejs at the moment.</p></pre>chuyskywalker: <pre><p>GCF is really behind on this front :(</p></pre>ryankearney: <pre><p>They don’t even support IPv6 on their EC2 competitor.</p></pre>014a: <pre><p>Google is startlingly far behind in every cloud product they offer, both in depth and breadth. I could make a list a mile long; GCPS doesn't support FIFO queues without involving Dataproc, Cloud Monitoring's strange reliance on the old StackDriver interface, Postgres still being beta in CloudSQL...</p>
<p>AWS isn't perfect, but they're incomprehensibly far ahead in the cloud game. Like, playing on a totally different planet while GCP is still learning rocketry 101.</p>
<p>But they will throw $200k at any startup that wants to use them.</p></pre>tech_tuna: <pre><p>Google's behind in the cloud period. Now that Amazon has EKS, good luck to Google and Microsoft on catching up.</p></pre>lonahex: <pre><p>Not really. Google is quite a diverse group engineering wise and we've seen many times how one group would not necessarily favor tech from another just because they are both from Google. GCF is just doing what makes sense from market perspective. Get the most common languages supported first and then move to other less common ones. </p></pre>smantziaris: <pre><p>azure did not support .net core either at the beginning but aws did... </p></pre>CannedCorn: <pre><p>Just call the go program from a JS wrapper.</p></pre>curiousGambler: <pre><p>could do the same thing to get Go on AWS Lambda now that you mention it...</p></pre>CannedCorn: <pre><p>And that’s exactly what apex does</p>
<p>You can run any language on lambda but the entry point has to be JS.</p></pre>jerf: <pre><blockquote>
<p>only nodejs at the moment.</p>
</blockquote>
<p>As much as I like statically-typed languages in general, one legit advantage that the dynamically-typed languages tend to have is that it really is easier to just load in a new chunk of text that is the new program code you want to run, with the new code every bit as much as integrated with the rest of the program as any other code is, since that's how <em>all</em> the code is loaded.</p>
<p>Go has a much harder time with that. Yes, I am aware that it can be done, I could with some weeks allocated write the system to do it myself on a local scale. But "with some weeks allocated" is rather more than "feed the text to <code>eval</code>", and that's still my estimate for something that work for me <em>locally</em>; I'm not sure what "cloud scale" would take, because the long tail of issues you encounter in that case gets pretty long.</p>
<p>So, honestly, the weird thing to me is that <em>Go</em> is supported at all, not that a dynamic language is supported first.</p>
<p>Personally, I'm going down a route where I will route my handlers dynamically to various bits of Go code, and not trying to jam my stuff into the Lambda model in the first place. If a particular instance of a Go program has /v1/rest_handler version 1.4, and I bring up version 1.5 in another process, it's no great skin off my nose that the original process keeps running to handle the rest of what it can serve in the meantime. I feel like Lambda et al are optimizing on some dimensions that will ultimately be seen to have been far less useful than it initially seemed, especially considering the cost that it imposes on the rest of your code, especially for the people who seem to be implementing whole systems in it. I expect to see some "serverless" frameworks to start gaining traction that in 3-4 years may well entirely supplant the hosted offerings.</p></pre>dlsspy: <pre><p>I think you're confusing several topics here. There's a big difference between a dynamically typed language and an interpreted language.</p>
<p>That you can (only) move code around in text form is not particularly interesting here. I regularly load code (as text) in haskell, your web browser loaded external compiled C code when you started using it, and everything that does anything with java is dynamically loading an intermediate form of code all the time. Python code is typically loaded from source form, but it doesn't need to be.</p>
<p>I'm not that familiar with AWS Lambda, but if they have any sort of ABI, then all languages are on equal footing. Go compiles to many targets and nacl. Something like Lambda would require heavy isolation (which processes provide naturally), so "run process on x64 that expects this input and provides that output" would be a pretty natural way to do things.</p>
<p>In any case, static vs. dynamic is not particularly interesting here. IME, dynamic types are mostly just useful for surprising yourself and your users with errors much later in the development process.</p></pre>jerf: <pre><blockquote>
<p>I regularly load code (as text) in haskell,</p>
</blockquote>
<p>Not in production you don't. GHCI is not performant enough for that. This is not a coincidence.</p>
<blockquote>
<p>your web browser loaded external compiled C code when you started using it</p>
</blockquote>
<p>From an effectively-static list of pre-existing C code modules. This is not comparable to how Lambda works.</p>
<blockquote>
<p>and everything that does anything with java is dynamically loading an intermediate form of code all the time</p>
</blockquote>
<p>Which is, unsurprisingly, "in between" in the complexity of loading it in real time between the fully-compiled languages and the dynamic languages.</p>
<blockquote>
<p>I'm not that familiar with AWS Lambda</p>
</blockquote>
<p>With all due respect, that is a problem for you in this argument, yes. You're pretty clearly operating on the mental model of servers with set functionality in them when they start, regardless of the underlying tech. This is the exact thing that "serverless" is trying to get away from.</p>
<p>(My contention is precisely that it ultimately isn't that hard to get a lot of the "serverless" features out of servers, with just a bit of tweaking and tuning and maybe some kubernetes-like support, and accepting that it's not necessarily that big a deal in the vast majority of cases to start up a server that may have some extra code in it for some particular use case. While lambda is always improving and getting better, I'm deeply unconvinced it was worth throwing away <em>all the other infrastructure we already have for servers</em> for what I find to be rather dubious benefits that I expect frameworks to start popping up to service better and cheaper.)</p></pre>lonahex: <pre><p>Totally awesome! Go is such a great fit for Lambda!</p></pre>jmking: <pre><p>Is it? Go being a compiled language seems like a weird fit for Lambda - the compile step is surely going to hurt performance.</p></pre>mustafaakin: <pre><p>I really hope it is binary only, not depending on source code</p></pre>IrishLadd: <pre><p>At my last job we ran a Go binary in Lambda via NodeJS. Node would handle the request and execute the Go binary (Hugo). Pretty easy since go runs anywhere.</p>
<p>I'm assuming this will let you just run the go code directly. Though I'm sure it will compile it on upload rather than in each request.</p></pre>XANi_: <pre><p>Not if amazon wants to earn more money ;)</p></pre>ryeguy: <pre><p>This would be interesting, because if it's just a binary that means you could in theory use it with any language that can compile to one. There might be some protocol reverse engineering or something, but it could work.</p></pre>devsquid: <pre><p>ROFL... There's no way they'll compile the go app each time an API is called. </p></pre>circuitously: <pre><p>It supports Java currently</p></pre>Manbeardo: <pre><p>Fun thought: since lambdas work best as microservices with very little code, compiling a typical go lambda will probably take less time than launching a JVM on the same instance.</p></pre>lonahex: <pre><ol>
<li><p>Lambda does not run a fresh container/instance on every invocation. It keeps the program running for some time and re-uses the same instance on new requests. Then kills off the instance if it doesn't get requests for some time. AWS has not disclosed these numbers yet.</p></li>
<li><p>Even if they did boot up a new instance on every call, why would they compile from source every single time? That needs to happen only on new deployments/code-changes and then they can just invoke pre-built binary every time they need to run the function.</p></li>
</ol></pre>andrewmwatson: <pre><p>I'm sure you'll cross compile the go binary for linux and deploy it as a zip file like you do now with the JS shim in place... or maybe not! Go compilation is incredibly fast and only has to be done when the function is updated, not when it is run.</p></pre>media_guru: <pre><p>FINALLY!</p></pre>dgryski: <pre><p>Here's a tweet: <a href="https://twitter.com/AWSreInvent/status/936301451566972930">https://twitter.com/AWSreInvent/status/936301451566972930</a></p></pre>Walkedairplane: <pre><p>This and Kubernetes are the big announcements I was hoping for this year. Heck yeah</p></pre>TheSwissArmy: <pre><p>Combine this with Far Gate and we have a stellar solution
<a href="https://aws.amazon.com/blogs/aws/aws-fargate/" rel="nofollow">https://aws.amazon.com/blogs/aws/aws-fargate/</a></p></pre>tech_tuna: <pre><p>Not only that. . . now there's a runtime continuum in AWS. Want to run a function, Lambda. Want to scale up a basic or simple service in Docker, run Fargate. Need more flexibility and power, run ECS. What's that you need to run hybrid/bare metal or don't want vendor lock-in? Run EKS. Hey, containers just don't cut it for my use case. . . nbd, EC2 is still there and still improving. </p>
<p>Never mind how much better all the built-in services are becoming. . .</p>
<p>AWS is killing it in the cloud. I'm a huge fan and occasional critic - there are rough spots and inconsistencies here and there, but it's also getting a bit scary. Amazon is everywhere.</p></pre>rpk788: <pre><p>what was the Kubernetes announcement? i think i missed that.</p></pre>Your_CS_TA: <pre><p>EKS: <a href="https://aws.amazon.com/eks/">https://aws.amazon.com/eks/</a> -- Amazon Elastic Container Service for Kubernetes</p></pre>IndomitableCentrist: <pre><p>AWS announces Elastic Kubernetes Service (EKS) which is essentially container orchestration managed by AWS with k8s</p>
<p>It is priced similar to Azure Kontainer Service (AKS), free to spin up clusters, pay only for nodes running in the cluster</p></pre>redlandmover: <pre><p><a href="https://aws.amazon.com/eks/" rel="nofollow">https://aws.amazon.com/eks/</a></p></pre>mustafaakin: <pre><p>But not available yet on console</p></pre>Your_CS_TA: <pre><p>It was a bit obscured, but on the announcement slide this was labeled as a "pre-announce". It is not available yet :(</p>
<p>Still, this is like the best thing ever. I personally was not a fan of the programming selection we had (only two typed languages, and Java is a bit too heavyweight for me) and when I heard this was happening, I got super excited.</p>
<p>** Disclaimer: I work for Lambda, but this is my own opinion and not that of AWS.</p></pre>synthdrunk: <pre><p>Is there an announced date for general availability?</p></pre>Your_CS_TA: <pre><p>Sorry man, I personally do not know any publicly announced date :(</p></pre>circuitously: <pre><p>Just keep hitting refresh...</p></pre>terramorpha: <pre><p>sorry, i am a noob. But can anyone explain to me what is this lambda thing ?</p></pre>greyeye77: <pre><p>lambda is a function as a service on AWS.<br/>
you upload the code (usually zip) and it will be executed when its called, usually via a web hook(http) or AWS internal triggers. </p>
<p>so, instead of uploading code to your own VM (ec2), you just upload the code. The benefit is that you do not pay a cent when these functions arent running, but within limit (eg a single cycle cannot go over 5min, memory of 1.5G, etc) </p>
<p>AWS lambda supports node.js, java, .net, python. So previsouly if you wanted to run Go or any other language, you had to upload it inside the wrapper (eg node.js to execute go binary) </p>
<p>not only AWS but Azure and google compute is also doing serverless</p></pre>jjolla888: <pre><p>how about libraries? what if your code needs to import them ? where are they uploaded or made available ?</p></pre>Your_CS_TA: <pre><p>Today, the main mechanism we see when it comes to multiple file uploads (e.g. bringing in node modules, configs, etc.) is uploading a single zipped file (or jar in java's case) that has all of those necessities bundled in it.</p>
<p>Currently, the total aggregate upload size is capped at 250mb unzipped in total.</p></pre>greyeye77: <pre><p>for nodejs, you zip node_modules and source code, then upload</p></pre>lonahex: <pre><p>You vendor in the libs and push them as part of your deployment. Many tools automate this by bundling your virtual env or node_modules inside a zip file. Then you just upload that file. Only real limitation right now is that the file cannot exceed 50mb in size.</p></pre>ericzhill: <pre><p><a href="https://aws.amazon.com/lambda/" rel="nofollow">https://aws.amazon.com/lambda/</a></p></pre>royge: <pre><p>This made my day!!!!</p></pre>grantmoore3d: <pre><p><a href="https://venturebeat.com/2017/11/30/aws-lambda-gets-go-support-and-a-tool-for-sharing-serverless-apps/" rel="nofollow">https://venturebeat.com/2017/11/30/aws-lambda-gets-go-support-and-a-tool-for-sharing-serverless-apps/</a></p></pre>titpetric: <pre><p>Even as a second class citizen, Go with <a href="https://github.com/apex/apex" rel="nofollow">apex</a> isn't half bad, but I'll be happy to drop the shim.</p></pre>cartesian_bear: <pre><p>I used to really look forward to it, but now feel like this announcement is a bit lacklustre, given that <a href="https://github.com/eawsy/aws-lambda-go-shim" rel="nofollow">other solutions</a> (nearly as good as native) already exist, so this seems like an incremental improvement without other enhancements.</p>
<p>Disclaimer: we have moved on from Lambda for unrelated reasons. They really ought to fix things like</p>
<ol>
<li>no DB connection pooling due to processes not getting reused,</li>
<li>awkward configuration management,</li>
<li>or having to pay for a NAT gateway if you want a function to talk to VPC resources and the internet at the same time.</li>
</ol>
<p>But even then, given their Kubernetes announcement, I feel like we can just run our ex-Lambda stuff as Kubernetes jobs and use uniform tooling, so there is no reason for us to consider Lambda.</p></pre>scarhill: <pre><p>They announced <a href="https://aws.amazon.com/about-aws/whats-new/2017/11/set-concurrency-limits-on-individual-aws-lambda-functions/" rel="nofollow">concurrency limits for Lambda</a> too. So now you can have each function open and hold a single DB connection for its lifetime. Pooling of functions takes the place of the connection pool and you can limit the number of connections with the concurrency limit.</p>
<p>What do you find awkward about configuration management? <a href="http://docs.aws.amazon.com/lambda/latest/dg/env_variables.html" rel="nofollow">Environment variables</a> don't work for you?</p></pre>cartesian_bear: <pre><blockquote>
<p>So now you can have each function open and hold a single DB connection for its lifetime.</p>
</blockquote>
<p>That's not solving the problem, though. You are reopening and closing a connection each time, so you still have no connection pooling.</p>
<p>You already have to do that even now, regardless of concurrency limit. The original problem was that after execution, a Lambda process does not necessarily terminate, it may be frozen and still consume a DB connection, so unless you close it explicitly at the end of the request, so eventually you may run out of connections. There doesn't appear to be any rhyme or reason in a way the processes are created or destroyed.</p>
<blockquote>
<p>What do you find awkward about configuration management? Environment variables don't work for you?</p>
</blockquote>
<p>Environment variables are not enough for doing anything more complex than key-value pair map of basic values. I have a nested config (a map of string -> section, each section with its set of key-value pairs).</p></pre>uttles: <pre><p>If you have a web server that compiled everything into a single binary, could you just upload that binary? Or would that defeat the purpose of this since it would be running all the time (listening for requests?)</p></pre>scottjbarr: <pre><p>Not exactly, but it isn't difficult.</p>
<p>We have HTTP API's that we have now deployed as Lambda functions behind API Gateway. The projects are built so that we can run them as a "normal" HTTP server, or we can deploy it as a Lambda function. If the layers in your services are decoupled it isn't very hard.</p>
<p>I found this post helpful in working out how to get it up and running <a href="https://medium.com/capital-one-developers/building-a-serverless-rest-api-in-go-3ffcb549ef2" rel="nofollow">https://medium.com/capital-one-developers/building-a-serverless-rest-api-in-go-3ffcb549ef2</a></p>
<p>It will be really nice not to worry about the shim.</p></pre>uttles: <pre><p>Thanks, I will give that a read. Good info.</p></pre>TheSwissArmy: <pre><p>I had the same thought. The googs and msft are getting left in the dust. </p></pre>mellett68: <pre><p>Wheeeeeee</p></pre>
