I’ve just noticed that there is enough info in the Go run-time support for AWS Lambda to show you how to support any language in Lambda. The source for the Go run-time is here: https://github.com/aws/aws-lambda-go
When you make a Go function for AWS Lambda it actual compiles down to an x64 Linux binary. You can run that binary from the command line on your local machine. When you run it, the run-time implements a little server. That server does the request/response stuff with the main Lambda control system that enforces security, starts lambdas, etc. So, by looking at the source in aws-lambda-go you can see exactly how to implement the server.
I haven’t tried this, but it looks to me like you can upload any random x86 Linux binary and claim it is a Go lambda function. This should allow lambdas to be written in C or any other language. Might be a way to get docker based lambdas working too.
For what I need Go is fine. Go is way, way faster than node.js for quick running functions. This is simply because Go is an x86 binary and Javascript gets JIT’d every time your call it. My node.js functions run 100-400ms. My Go functions are running in 0.3 to 2ms. They are about 40x faster. Do note that this speed impact is only important for quick running lambdas. If your lambda is going to run for 20s you probably won’t notice any difference since the JIT time will be spread out more.
These are my observations from playing with Go for about a week. Next week I will convert some larger lambdas over to Go and see how they perform.
Out of curiosity, what is your use case where Go ran so much quicker than Node? My work does a lot of text processing and we’re switching from Node to Go to help with speed. I have a feeling we might just eek out enough speed improvement to make a serverless architecture affordable.
We have very tiny functions that run in milliseconds. The functions themselves do very little other than chain together calls into other AWS services - like database looks ups, send IOT message, etc. The primary role of the functions is to ensure secure access to these other resources. Since Go is compiled, we eliminated JITing and other start up costs of Javascript. On the other hand, if your functions are running 10-30s this may not matter.
In your case I’d take advantage of the new C language support and write optimized code. You can also now upload pre-compiled libraries so maybe there is an off-the-shelf library that is fast?
As is always the case, make sure any calls to AWS services are paralleled. Waiting for 5ms for 10 service calls to respond in parallel is far cheaper than waiting 5ms ten times sequentially since lambda charges for wait time.
Ah that makes sense. In my work’s case, startup time would be irrelevant because it’s a continuous stream of data. The cloud functions would always stay warm. It’s just that once the function accepts the data to process, we would want it to finish ASAP. I should definitely look into writing cloud functions with Go or C. I have no problem using Node for occasionally triggered cloud functions that don’t do intense processing, but intense processing is definitely not its domain.
It is always good to work with Golang when distributed systems come into the picture.
Serverless computing offers a number of advantages over traditional cloud-based or server-centric infrastructure. For many developers, serverless architectures offer greater scalability, more flexibility, and quicker time to release, all at a reduced cost.
With serverless architectures, developers do not need to worry about purchasing, provisioning, and managing backend servers. However, serverless computing is not a magic bullet for all web application developers.
If you have created AWS Lambda function with Node.js then you have felt that the speed is relatively low compare to Golang because go can provide the blazing fast speed in execution.
