Netlify's Open Lambda Rust Runtime Distribution

[calavera]

👋 Hi all,

A few weeks ago, I started to cherry pick open PRs in my own fork. I decided to publish my fork in crates.io with a different name so people can use it without having to maintain their own forks forever. We're at a point where we've fixed some major compatibility bugs, and we're using it internally for some fun new projects.

You can find the fork in https://github.com/netlify/aws-lambda-rust-runtime

These are the PRs that we've cherry picked from this repository (besides fixing some other issues):

#242 by @rimutaka
#247 by @voteblake
#251 and #263 by @stanislav-tkach
#255 by @nmoutschen
#265 by @RyanJarv
#266 by @l3ku

These are the crates:

https://crates.io/crates/netlify_lambda_http
https://crates.io/crates/netlify_lambda
https://crates.io/crates/netlify_lambda_attributes

And these are the docs:

https://rs-lambda-runtime.netlify.engineering/netlify_lambda_http/
https://rs-lambda-runtime.netlify.engineering/netlify_lambda/
https://rs-lambda-runtime.netlify.engineering/netlify_lambda_attributes/

Feel free to use it, reach out to me if you have comments, or questions. If there is any issue in this repo that you think it's a big blocker for your use of the Rust Runtime on AWS Lambda, and you think I can help unblock it, feel free to ping me.

[rimutaka]

This is actually very sad that we came to this. Netlify should just join as maintainers. @davidbarsky, et all, if this project is no longer a priority for you, please, allow the community to take it forward.

[nmoutschen]

Hey @calavera & folks!

Thanks a lot for this and agree with @rimutaka that it's sad we came to this. I'm still a beginner in Rust, but I'm part of the serverless team at AWS and I'd like to see what we could do on that front.

I'll be on vacation starting tomorrow till the 11th of January, but if you could send me a DM on https://twitter.com/NMoutschen and I'll share my email address so we can have a chat about this.

[Veetaha]

In our company's case, we've been using a custom wrapper crate around the 0.1 of this runtime that allows for writing async lambdas and hides the deprecated failure crate dependency under the hood so far which is fragile.

I wish we could grant the maintainership/contributor rights for people who have time and wish to bring this upstream repo to the state of release to crates.io (i.e. netlify folks).

cc @davidbarsky

[miere]

Hi @nmoutschen

Thanks a lot for this and agree with @rimutaka that it's sad we came to this. I'm still a beginner in Rust, but I'm part of the serverless team at AWS and I'd like to see what we could do on that front.

As you might've noticed by @calavera original comment, we have many contributions being made and no feedback whatsoever being delivered from the AWS team. I agree with you that it's sad that we came to this, but I've seen this happening several times on different AWS-maintained opensource projects. Is my understanding, and I accept this, that AWS might've been busy with its internal projects and might have not enough resources to support its own open sources projects. But, if that's the case, the community should be empowered allowing us to propose changes and shorten the feedback loop required to develop a solution suited to our needs.

If you don't mind, I'd like to see:

• Clear guidelines on how can the community contribute, assess and have its contributions merged into the main branch.
• A minimum documentation describing the idea behind the current design. Other runtimes are simpler whereas Rust's wants to provide more than just an execution entry point (namely, lambda-http).
• A place where we can openly discuss its design (perhaps enable GitHub Discussion in this repository?). Certainly, opening issues didn't work.
• A community maintainer with merge permission. This would solve the major issue of having no maintainer to assess/approve our contributions.

I shouldn't have to mention this but Lambda is the backbone of AWS Serverless suite. I'm really convinced that Rust could be the main drive on serverless adoption at AWS - just as Microsoft is doing with TS/.Net-core or Google with Python/Go. This is especially true if you take a look into the current state of the Js/Python/Java-related AWS serverless community (languages that were spearheading serverless development years ago). With no quality Lambda support, it would be hard to convince enterprises to adopt a new paradigm in the first place.

[dspatoulas]

We have been using the Netlify fork to adopt the new lambda container images at my current org. It works great and we have engineers who would be happy to help contribute to the fork if this repository is no longer being actively maintained.

[rimutaka]

Looks like this repo got an active maintainer working through the backlog. Is Netify still ahead?

[bahildebrand]

@calavera , thanks for putting this list together. We've recently onboarded a few new maintainers, and we've spent the last couple of months spinning up and working through the backlog. We're now at a place where we're looking to get the 0.3 release out soon. If there are any changes that exist in your fork that you think are missing we'd welcome the pull requests. We appreciate all the work you put into to maintaining your fork, and would love to have that work present here.

@miere, @coltonweaver recently enabled discussions, so feel free to start a discussion there. I think your request for design is valid, but we're going to focus on getting the project in better shape, and getting a new release out. I'll open an issue for documenting the design.

I'm going to close this issue as we have resolved all issues, and merged all PRs mentioned in the initial request. If you feel there is more to be done/discuss here, please feel free to re-open the issue, or start a new discussion.