[Lambda runtime] Tell us about your projects deployed on Lambda

sebsto · August 7, 2024, 7:24am

We just merged a file to list all the projects using the AWS Lambda Runtime.

If you're project is not confidential and you want to be listed there, submit your PR

swift-server/swift-aws-lambda-runtime/blob/main/projects.md

# Projects using Swift AWS Lambda Runtime library

Here you will find a list of code repositories that has in common the usage of the **Swift AWS Lambda Runtime** library.

Provide a link to your code repository and a short description about your example.

- [GlobantPlus](https://github.com/fitomad/TechTalk-AWS-Lamba-Swift/). An imaginary streaming services with a tvOS application that interacts with the AWS API Gateway, AWS SQS services and a set of Lambdas that cover different aspects. Repository's documentation available in Spanish🇪🇸 and English🇺🇸.

dima_kozhinov · August 7, 2024, 1:55pm

I stick to using the sub-par JavaScript in my Lambda functions. You just write several lines of code - right at the AWS website - which means virtually zero development and deployment, and if you manage to debug them so that your script does not crash in a seemingly safe and innocent line of code, then it just works. Using Swift looks too complicated in its current form.

0xTim · August 7, 2024, 5:25pm

My experience is the complete opposite of this

dima_kozhinov · August 7, 2024, 6:42pm

I can tell only about my personal experience.

Apart from ease-of-development-and-deployment and package size, there is also a question of performance.

The best performance on cold start is given by Rust (~30ms) and Go (~75ms) followed by Ruby (124ms), Python (~127ms), and Node.js (~128).

A second group contains Swift built with Amazon Linux 2 (~190ms/~219ms) and C# .Net Core (~224ms).

The last group contains Swift built with Ubuntu (~329ms/~338ms) and Java (~358ms).

The difference between Swift built with Amazon Linux 2 and Ubuntu is about 20 MB of package size which pays around ~140 ms on cold start.

The article is quite old though, and things may have improved since then.

taylorswift · August 10, 2024, 2:19pm

i’m surprised package size has such a large impact on lambda performance, this suggests to me that more effort should be focused on optimizing the server ecosystem (Crypto, AsyncAlgorithms, especially) to adopt a more modularized package architecture and drop Foundation dependencies where possible.

i’m also not sure why Ubuntu specifically would be so different from Amazon Linux in this benchmark.

johannesweiss · August 11, 2024, 8:05am

@rauhul / @kubamracek I think this also intersects with your work on Embedded Swift. What's the current state of {Full,Thin}LTO and hermetic builds? Is it feasible to get to a significantly smaller binary with that today? Especially if we use either no Foundation or swift-foundation and the Musl static binaries + some sort of LTO could yield a much smaller image for Lambda.

Back of the envelope calculations: it was suggested that +20 MB means +140ms which means 20 MB/0.14s*8bits/B = 1142 Mbits/s ~= 1 Gbps. Would've expected a bit more but at least the order of magnitude seems right.

rauhul · August 11, 2024, 5:53pm

Before we introduced the current Embedded swift compilation mode, I showcased embedded swift prototypes internally at Apple using full LTO + hermetic seal.

I was able to build a minimal "desktop" swift program for the stm32f746 mcu into a 300-500KB binary (with LTO) down from an original size of 5MB.

I added experimental support to SwiftPM for building with LTO so you can try it, but I can't guarantee it still works as I have not needed to maintain it for Embedded uses. If you would like to give it a shot the cli swift build option is --experimental-lto-mode={full, thin}.