I apologize in advance if this question is silly or being asked in the wrong forum. I was unable to find an answer after a few hours of Googling…so I'm hoping someone might know.
So I finally (!!) bought an M3 MacBook Air (updated from my 2019 Intel MacBook Pro) and used it to archive my Swift Lambda function. After uploading to AWS, it failed to run with test data…and I deeply suspected the reason was because the compilation target was for an Arm processor (as opposed to x86). Sure enough, when I changed the Lambda runtime to Arm in the AWS console, the Lambda function worked perfectly.
I am using the AWSLambdaPackager to create the archive…and I'm curious…since it is actually the thing managing the creation of the archive, compiling the code…is there a way to tell it that even though I'm on an M3 Mac that I want to target an x86 Lambda runtime? I "suspect" this would have to become a new option…something like this:
swift package --arch x86_64 --disable-sandbox plugin archive
Am I missing something? Does this capability already somehow exist?
--triple won't work as it won't point to the correct SDK, unlikely you would have a cross-compilation SDK installed in the first place.
If you would like to proceed with the cross-compilation approach, you need to produce a Swift SDK for the correct distribution and its version. We don't have Amazon Linux support in Swift SDK Generator, but I'm happy to review PRs adding it. Then you'd be able to build on macOS with something like swift build --experimental-swift-sdk x86_64_amazonlinux2.
Thanks all…this has been super helpful! I basically have mixed feelings here…
On the one hand, I'm relieved that I didn't miss something stunningly obvious and waste the group's time. I confess that I'm a bit green when it comes to fully understanding how the AWSLambdaPackager works…but I have an overall sense of it…and I may do a deep dive (and look into @Helge_Hess1's work) just as a learning experience…to better understand the how my local work gets to AWS.
Now on the other hand, I'm really surprised this hasn't come up before. I've been playing with AWS for Swift Lambda (which I think is amazingly cool) since the announcement way back in 2020. I have to think I can't be the first person to take a project begun on an Intel Mac and move it over to a Mac with Apple Silicon. Granted, probably most work is now done on Apple Silicon…I readily admit I'm the latecomer here. Simplest thing, I think, for me is just to embrace Arm in Lambda…it's cheaper for one thing…and perhaps better at running Swift anyway. There's no commercial ding for me…I'm just playing around with it all…so the move to Arm is easy enough. I just thought it…odd…that this hasn't been a "thing". I mean, what would you do if had to…for whatever reason…target x86 in Lambda via an M1, 2, 3 Mac?
"For sure" you are correct … but what I sorta had in mind is the idea that many folks made the transition from Intel to Apple Silicon between 2021 and 2023 … and if a "reasonable" number were working with Swift for AWS Lambda, I thought I'd see more folks ask about this cross-compile issue. When you setup for AWS Lambda, you have to explicitly tell Amazon what runtime you want (either in the AWS console or through the AWS CLI)…x86 is the default. It's making me think that fewer people must be using the AWS Lambda package than I thought … which I kind of feel is on folks like me for not being more involved and active within the community…building cool things with it…because I think it's a really cool thing. In my specific case, I can easily reconfigure for Arm … I just thought it would have dinged more people is all. Anywho, this is more philosophy than tech, so I won't dwell on it beyond this post.
Definitely not the first to come across this. When I first hit it, I referenced the deployment example in the repo and used the shell script with the noted modifications.
Later, I built a Github Action to handle the build process because that works better for my workflow.
@jagreenwood, if your post doesn't deserve a "like" heart, then I don't know what post would deserve one. Thank you! So yeah, your answer is right on point…and I'm a little sheepish here…I don't know how I missed the info you linked to…I certainly wouldn't have opened this topic had I read it. Effectively, I've taken the first suggestion offered (just to go Arm/Graviton). In addition, I think your GitHub action is extremely clever…even beyond the way it handles this M1 issue. I'm absolutely aware that the Swift for Server community is pretty small compared to other Swift communities…but I'm still amazed that, apparently, very, very few folks are likely using Swift in Lambda…but I am relieved to know I'm not the only one to hit this problem.
Hey @richwolf I wonder was is your use case to deploy to a x64 Lambda runtime ? Are you using binaries that are built for x64 ?
The Graviton (Arm) Lambda runtime has a much better price / performance ratio. It also consumes less power. So it's good for your credit card and good for the planet.
Many large AWS customers are running CICD pipelines to deploy to Lambda. They don't deploy from their laptop directly, which is more a thing for smaller teams and hobbyist projects.
When you use a CICD pipeline, you can build on x64 Mac in the cloud like including Amazon EC2 Mac and target the correct build machine to match your deployment architecture.
I personally deploy my Lambda functions using AWS SAM. My templates have the Architectures: -arm64 line by default. (I mean my default :-) )
Well, to be honest, I have no compelling use case…at least not personally…I was just wondering on behalf of (potentially) others…it's why hedged my words by saying "for whatever reason"…because I am hard pressed to think of a compelling use case, just as you suggest. Only reason I can figure (off the top of my head) is if you have a group of folks working in a mixed environment of Intel and Apple Silicon Macs…and they all need to upload to Lambda. Even if that were the case, it is going to be less of a thing going forward as all Macs will run on Apple Silicon. In my specific case, I'm quite happy to adopt Graviton 2…it appears to be cheaper and faster.
Main concern for me…and it kind of goes to the heart of the discussion that I was having with @Helge_Hess1…is that x86_64 is the default architecture for a Lambda container…and none of the "getting started" tutorials mention that you must explicitly choose arm64 for Lambda functions created on Apple Silicon Macs. There's also pretty much no online discussion of using Graviton 2 when building Lambda functions when using Apple Silicon Macs. The only conclusion I could draw from all that is that there aren't a lot of individuals tinkering with Swift for Lambda…because if there were, I can't see how this wouldn't have come up…because it's not like it's come up even a little bit…it hasn't come up really at all. My humble opinion is that there is maybe some room for the tinkerers…like me…who have a basic understanding of Swift for Lambda, and who have built some fun things with it, to contribute something back to the community…perhaps some updated tutorials that go a bit beyond the basics. I would be the first to admit that it's one thing to say, "This thing is really cool, you should use it," and another to say, "This thing is really cool, let me show you how you can make a cool thing with it."
Oh for sure that makes total sense! And if I had some commercial thing…and not just fun experiments…I'd pretty much have to go CI/CD. It'd be the correct thing to do. It's just that in Big Corp, Ltd., I'm sure one developer says to another, "Oh yeah, yeah…talked to our Amazon rep…and the suggestion is that we setup a pipeline to bring up an EC2 instance and compile to x86_64 and then we're good until we decide if it makes fiscal sense to adopt Graviton." But I am but a humble, one-person tinkerer.
and none of the "getting started" tutorials mention that you must explicitly choose arm64 for Lambda functions created on Apple Silicon Macs
You're correct. And I think it's related to the fact that many tutorials are from 2020 - 2021 when Apple Silicon mac were just being launched.
Most of these tutorials neither mention SimpleLambdaHandler or the packager plugin that simplifies the build process.
I humbly contributed recently with this tutorial. It has the mention
Note
The runtime architecture for Lambda (arm64 or x86_64) must match the one of the machine where you compiled the code. When compiling on an Intel-based Mac, use x86_64. When compiling on an Apple Silicon-based Mac select arm64.
But this tutorial is not visible enough, it is buried in the project's documentation and only hosted on the Swift Package Index.
I'm currently working with a student in the context of an internship to build a VSCode extension that will easily create, package, deploy, and test a Swift Lambda function. We are using templates to scaffold new projects, and these templates will automatically adjust the deployment descriptor to the architecture of the current machine). I hope this will help future developers to not even think about it and just write and deploy code that works ™️
Ah, again I feel a bit sheepish here…I actually did come across your tutorial before posting here…but somehow I missed the bit about Arm…the one where you explain which Lambda architecture has to be chosen, given the dev environment.
I may have this wrong, but I'm increasingly convinced that there is role for folks like me to sort of evangelize Swift on Lambda as users of Swift on Lambda…to give something back to this community. I've been meaning to write a series of Medium posts that sort of go beyond the "square number" example. I had in mind things like: how to interact with RDS using Vapor's MySQL client in a Lambda Swift function…how to implement a WebSockets backend…cool examples of how to use most of the Lamda Event types…unit testing…stuff like that. I have a few thousand words written, and a fair amount of example code…but progress has been slow. This forum topic has sort of re-energized me to get back to it. Dunno if it would make a difference (as I am the fartest thing from an expert)…but I'm beginning to believe that the way to get more folks interested in Swift for Lambda is to try to show how interesting things can be made with it.
Maybe that's a sign this is not visible enough. But I'm glad you found that tutorial :-)
but I'm increasingly convinced that there is role for folks like me to sort of evangelize Swift on Lambda as users of Swift on Lambda
Yes. we need more demo, more tutorials, esp, about advanced use cases and not simple "hello World", more talk at conferences, more post on social networks.
I'm happy to review your content before posting them and make some noise about them when public.
I mean, what would you do if had to…for whatever reason…target x86 in Lambda via an M1, 2, 3 Mac?
Anywho, this is more philosophy than tech, so I won't dwell on it beyond this post.