3 ms·

Forgive the noob question, but why is it necessary to have a custom runtime when using a binary from a compiled language? It seems to me that golang support sho

Forgive the noob question, but why is it necessary to have a custom runtime when using a binary from a compiled language? It seems to me that golang support should just mean binary support, and then c++ and rust would be able to comply already, no?

munns 8y ago
You could do that, it's true, and folks did that with node.js to shim Go before Lambda had official Go support. But being able to just create/use/share a custom runtime inside of an organization will be easier for them overtime vs. the shim method. - Chris from Serverless@AWS.
seniorsassycat 8y ago
The go runtime can execute any binary, but the lamda is controlled via go rpc, which uses go's custom binary serialization. I couldn't find any implementations of gobs in any other language when the go runtime was announced. I hope this runtime API is a simplification of the go rpc api
archgoon 8y ago
As of yesterday, lambda only provided a way to specify a function handler. The input to that function, and the response value from that function, needs to be deserialized and serialized (and implicitly, construct a runtime in which the concept of a function exists). Previously, a runtime for each supported language handled deserializing the wire protocol into a runtime object, invoking the specified function, routing stdout and stderr to cloudwatch, serializing the function's return value, and transforming runtime exceptions into response exceptions. The lambda team is now letting you write that runtime, and presumably providing more documentation on the responsibilities of the runtime. Check out the example C++ and Rust runtimes to understand why each language needed to have it's own custom runtime. https://github.com/awslabs/aws-lambda-cpp https://github.com/awslabs/aws-lambda-cpp https://github.com/awslabs/aws-lambda-rust-runtime https://github.com/awslabs/aws-lambda-rust-runtime
kondro 8y ago
tl;dr; Cold starts/performance. The way Lambda manages to achieve the performance it does is because it bootstraps the application and then runs each new request through the loaded application. This means Lambda needs some way to communicate with an already running service. Initially, Lambda had language specific runtimes that took care of this (i.e. with Node they have their own bootstrapper that loads your top-level JS file and then calls the defined method each time it receives a new event). With the release of the Go runtime, they built a framework that gets compiled into your service that runs a simplified HTTP server that Lambda then submits events to. This latest generalised version eschews an embedded HTTP server for letting your app do something like a long-poll to a local event RPC source in the Lambda container. Basically, your app boots and attempts to pull a job off the queue, if there's a job, your Lambda runs, if there isn't, your Lambda service gets paused until there's something to send it.

munns 8y ago

You could do that, it's true, and folks did that with node.js to shim Go before Lambda had official Go support. But being able to just create/use/share a custom runtime inside of an organization will be easier for them overtime vs. the shim method. - Chris from Serverless@AWS.

seniorsassycat 8y ago

The go runtime can execute any binary, but the lamda is controlled via go rpc, which uses go's custom binary serialization. I couldn't find any implementations of gobs in any other language when the go runtime was announced. I hope this runtime API is a simplification of the go rpc api

archgoon 8y ago

As of yesterday, lambda only provided a way to specify a function handler. The input to that function, and the response value from that function, needs to be deserialized and serialized (and implicitly, construct a runtime in which the concept of a function exists). Previously, a runtime for each supported language handled deserializing the wire protocol into a runtime object, invoking the specified function, routing stdout and stderr to cloudwatch, serializing the function's return value, and transforming runtime exceptions into response exceptions. The lambda team is now letting you write that runtime, and presumably providing more documentation on the responsibilities of the runtime. Check out the example C++ and Rust runtimes to understand why each language needed to have it's own custom runtime. https://github.com/awslabs/aws-lambda-cpp https://github.com/awslabs/aws-lambda-cpp https://github.com/awslabs/aws-lambda-rust-runtime https://github.com/awslabs/aws-lambda-rust-runtime

kondro 8y ago

tl;dr; Cold starts/performance. The way Lambda manages to achieve the performance it does is because it bootstraps the application and then runs each new request through the loaded application. This means Lambda needs some way to communicate with an already running service. Initially, Lambda had language specific runtimes that took care of this (i.e. with Node they have their own bootstrapper that loads your top-level JS file and then calls the defined method each time it receives a new event). With the release of the Go runtime, they built a framework that gets compiled into your service that runs a simplified HTTP server that Lambda then submits events to. This latest generalised version eschews an embedded HTTP server for letting your app do something like a long-poll to a local event RPC source in the Lambda container. Basically, your app boots and attempts to pull a job off the queue, if there's a job, your Lambda runs, if there isn't, your Lambda service gets paused until there's something to send it.