Go in AWS lambda, why is it needed?

<p>Isn&#39;t one of the points of Go the ability to deploy a compiled binary file in almost any system? Shouldn&#39;t it be the easiest language to support? Why is it needed a Go runtime for a Go lambda to run?</p> <p>Maybe I&#39;m missing something very obvious here...</p> <hr/>**评论：**<br/><br/>justinisrael: <pre><p>It isn&#39;t really about making it easier to host your program. FaaS is a newer paradigm that breaks applications down into even smaller chunks than microservices. You can now scale a function as needed instead of your complete program. Also a lambda could be cheaper to scale and run since it can spin down from hot to warm to cold when not in use. You can combine the two concepts. Your main front end could be a binary running on a less powerful instance. But the heavy functions, when accessed, could scale out as needed with lambda. </p></pre>robrtsql: <pre><p>I don&#39;t think people have really understood your question.. you seem to be asking not why to use AWS Lambda, but why AWS doesn&#39;t already support Golang in Lambda, since it should be easy.</p> <p>Consider the following: maybe it&#39;s the fact that Go does <em>not</em> require an installed runtime that is making things so difficult. If you look at the 4 supported languages, they are all interpreted or compile down to some intermediate representation which is then run by the JVM / C# runtime. This makes it really easy for the user to provide their code--for Node.js and Python, they simply provide the source code, and for Java/C#, they provide the &#39;.jar&#39;s/whatever C# uses, which can be built on any operating system.</p> <p>How does it work with Golang? Does the user compile the code themselves? If so, do they need to target Linux when they compile, or do they have to go so far as to run Amazon Linux in a container in order to &#39;build&#39; their Go code in the correct environment / with the right dependencies? Or does AWS compile the Go code for you? How do you hook dependencies into your project?</p> <p>Additionally, AWS does a little more to &#39;support&#39; your Lambda functions than just running them--they include AWS SDK dependencies so you don&#39;t have to, so now the Go SDK needs to be available to your new Go Lambda functions.</p> <p>Writing Go for AWS Lambda is already possible if you call your Go code from the Python runtime (<a href="https://github.com/eawsy/aws-lambda-go-shim" rel="nofollow">https://github.com/eawsy/aws-lambda-go-shim</a>), so we know AWS hasn&#39;t left it out because they can&#39;t get it to work--it&#39;s just a matter of supporting it. I&#39;m not sure exactly what&#39;s standing in their way, though.</p> <p>Apparently it&#39;s on the roadmap--I think it was mentioned in passing at reinvent 2017.</p></pre>quacktango: <pre><p>I&#39;d personally rather spin up a cheap server and shove my binary on it, but if the place I was working for mandated lambda for everything for whatever crazy reason (I&#39;ve been in worse employer-imposed situations before!), I&#39;d sure as heck be grateful go was available!</p></pre>SeerUD: <pre><p>There are pros and cons to both approaches. If you need to spread some work out pretty quickly, or the scale changes quite dramatically at times and the workload is suitable for functions then they&#39;re great. It means you don&#39;t have to spin up a cheap server, you instead automatically spin up much cheaper functions, and when they&#39;re used they&#39;re gone.</p> <p>Where I work it&#39;s a combination of billing and being a bit more flexible.</p></pre>royge: <pre><p>IMHO It is basically about the auto scaling available is AWS Lambda as well as the costs in which you only pay when your service is running.</p></pre>fazalmajid: <pre><p>The most likely reason is they can’t preempt runaway code. Google AppEngine supports go, but it has many restrictions on the FaaS option.</p></pre>Zarkopafilis: <pre><p>AWS Lambda is not worth it compared to the other supported languages (compared to ex NodeJS). </p> <p>I&#39;m stating that because Go has virtually zero startup overhead compared to spinning up a JVM instance to make your function <code>hot</code>, or booting the whole nodejs -- in both time and resources (per request and on boot)</p> <p>It&#39;s more worth it to have it ran on some simple EC2 server, or if you really need the extra scalability, either elastic beanstalk or some kube cluster. </p></pre>