3 ms·

Kind of - you can BYO binaries but the vast majority of the time you'll be BYO code instead. A Django project doesn't care what architecture it runs on so long

Kind of - you can BYO binaries but the vast majority of the time you'll be BYO code instead. A Django project doesn't care what architecture it runs on so long as Python is compiled for it, ditto with Node and RoR and all the other interpreted languages. Java should also be fine as long as the runtime works on the arch since it's only bytecode anyways. Really the only people who would need to care are the people deploying Rust and C binaries, but I'd guess those people are already used to compiling for different architectures anyways (you need to build for Amazon's Linux AMI to run a binary on Lambda, for example).

inopinatus 6y ago
I'm speaking from experience; since I'm actually using some of those I can tell you that assumption doesn't hold in the real world. It's a myth that programs written for interpreted/dynamic/scripting languages are automatically portable, because many nontrivial uses pull in FFI-based or otherwise compiled extensions, so a deployment package does include platform-specific code. I can't speak for Django but this is definitely the case for Rails: a Rails application that's been bundled with its dependencies for deployment in Lambda includes x86-64 binaries. I just checked one of our standard templates, and it has 18 gems using compiled extensions. I'm reasonably sure I'd find similar if I go look through our Node stuff, and in any case, it's a documented concern[1]. The point being, where they don't already have it, such AWS services will likely add platform/arch metadata to their deployment packaging, and users shouldn't assume a seamless transition when the option to switch becomes available. [1] https://aws.amazon.com/blogs/compute/nodejs-packages-in-lambda/ https://aws.amazon.com/blogs/compute/nodejs-packages-in-lamb...
- nexuist 6y ago
  Ah, this is a fair point. I hadn't considered this, but my build process does indeed include a compilation step done on Amazon Linux to pull in all the packages and build them with node-gyp. That then gets uploaded to Lambda. So you're correct that people will have to care if they don't already generate builds through CI; otherwise it should be relatively simple so long as none of the included packages drop down to assembly for some weird reason.

inopinatus 6y ago

I'm speaking from experience; since I'm actually using some of those I can tell you that assumption doesn't hold in the real world. It's a myth that programs written for interpreted/dynamic/scripting languages are automatically portable, because many nontrivial uses pull in FFI-based or otherwise compiled extensions, so a deployment package does include platform-specific code. I can't speak for Django but this is definitely the case for Rails: a Rails application that's been bundled with its dependencies for deployment in Lambda includes x86-64 binaries. I just checked one of our standard templates, and it has 18 gems using compiled extensions. I'm reasonably sure I'd find similar if I go look through our Node stuff, and in any case, it's a documented concern[1]. The point being, where they don't already have it, such AWS services will likely add platform/arch metadata to their deployment packaging, and users shouldn't assume a seamless transition when the option to switch becomes available. [1] https://aws.amazon.com/blogs/compute/nodejs-packages-in-lambda/ https://aws.amazon.com/blogs/compute/nodejs-packages-in-lamb...

nexuist 6y ago
Ah, this is a fair point. I hadn't considered this, but my build process does indeed include a compilation step done on Amazon Linux to pull in all the packages and build them with node-gyp. That then gets uploaded to Lambda. So you're correct that people will have to care if they don't already generate builds through CI; otherwise it should be relatively simple so long as none of the included packages drop down to assembly for some weird reason.