5 ms·

Apparently Python rules the roost for Lambda: https://mobile.twitter.com/julian_wood/status/1442775542374277120/photo/1 https://mobile.twitter.com/julian_wood/s

Apparently Python rules the roost for Lambda: https://mobile.twitter.com/julian_wood/status/1442775542374277120/photo/1 https://mobile.twitter.com/julian_wood/status/14427755423742... But NodeJS is second!

zxcvbn4038 5y ago
Golang is the top dog for Lambda IMO. The AWS Lambda SDK for Golang includes the entire lambda runtime so you can deploy a single 20mb binary w/ an Alpine linux base (speaking of the ECR backed lambdas) and that’s it. With NodeJS you either have to use the AWS provided centos based images which weigh in at several hundred MB or do some multistage magic to build a minimal Alpine image including the lambda runtime and AWS SDK which altogether still weighs in almost a hundred MB.
- bonobocop 5y ago
  TBH, as the Dockerfile based Lambda layers have a 20GB file size limit, I'm not sure the size matters as much. It's certainly easier to figure out what's going on in a smaller container though! I've had to debug some nasty situation with layers in Python Lambdas before and it's not fun...
rewma 5y ago
Well, call me surprised. Personally I never bothered using Python runtimes in a production environment, mainly because NodeJS is widely described as pretty much the ideal lambda runtime, and as far as I know there is absolutely no compelling reason to pick Python over it. Also, for performance undoubtedly Golang is by far the optimal AWS Lambda runtime. Consequently, I see NodeJS in every single application ever as pretty much the default runtime, with a bit of Java (renowned for being by far the worst AWS Lambda runtime) primarily to leverage code reuse and of course Golang. If anyone reading this picked Python for your AWS Lambda runtime, do you mind telling why? I would love to hear your rationale as I'm sure I'm missing an important take.
- OJFord 5y ago
  Ours are all python, none node. In many cases they replaced existing (non-Lambda) python code, though others were green. Why rewrite the code, or switch to node for greenfield stuff? We'd need a compelling reason to adopt node, not to avoid it. I assume the answer's roughly the same for anyone - it's odd to me that you're talking about 'ideal Lambda runtime', I'd be surprised if many people care. You're going to choose your language by however you were going to choose your language otherwise, and then run it on Lambda. And python is more popular than node in general. If you really wanted every last gram of performance, you'd be running an optimised compiled binary anyway, not using any of the provided runtimes.
  - rewma 5y ago
    > Ours are all python, none node. In many cases they replaced existing (non-Lambda) python code, though others were green. Why rewrite the code, or switch to node for greenfield stuff? We'd need a compelling reason to adopt node, not to avoid it. That's a great point. I admit I followed the same exact rationale motivated by code reusie to go with Java runtimes in projects that consisted mainly of peeling responsibilities out of legacy Java services, and Java is notoriously by far the worst performing Lambda runtime. Granted, this was before lambda's pricing granularity was updated from 100ms down to 1ms. Nowadays, a JDK invocation easily costs 50x the cost of a NodeJS lambda invocation, not to mention the concurrency consequences. > I assume the answer's roughly the same for anyone - it's odd to me that you're talking about 'ideal Lambda runtime', I'd be surprised if many people care. Sure, there are other constrains and requirements, but in the context of AWS Lambdas, and taking into account the way they are priced and the fact that they run on a single vCPU and that they are mainly IO-bound, NodeJS is very hard to beat. If you're starting out a project, you're not totally ignorant regarding AWS Lambda's pricing, and you are free to pick whatever runtime you want, it is very hard to justify any rational choice other than NodeJS or, alternatively, Golang. > If you really wanted every last gram of performance, you'd be running an optimised compiled binary anyway Hence Golang. Meanwhile, NodeJS gets you about 90% where Golang takes you without taking a single step outside of the happy path.
    - 5y ago

zxcvbn4038 5y ago

Golang is the top dog for Lambda IMO. The AWS Lambda SDK for Golang includes the entire lambda runtime so you can deploy a single 20mb binary w/ an Alpine linux base (speaking of the ECR backed lambdas) and that’s it. With NodeJS you either have to use the AWS provided centos based images which weigh in at several hundred MB or do some multistage magic to build a minimal Alpine image including the lambda runtime and AWS SDK which altogether still weighs in almost a hundred MB.

bonobocop 5y ago
TBH, as the Dockerfile based Lambda layers have a 20GB file size limit, I'm not sure the size matters as much. It's certainly easier to figure out what's going on in a smaller container though! I've had to debug some nasty situation with layers in Python Lambdas before and it's not fun...

rewma 5y ago

Well, call me surprised. Personally I never bothered using Python runtimes in a production environment, mainly because NodeJS is widely described as pretty much the ideal lambda runtime, and as far as I know there is absolutely no compelling reason to pick Python over it. Also, for performance undoubtedly Golang is by far the optimal AWS Lambda runtime. Consequently, I see NodeJS in every single application ever as pretty much the default runtime, with a bit of Java (renowned for being by far the worst AWS Lambda runtime) primarily to leverage code reuse and of course Golang. If anyone reading this picked Python for your AWS Lambda runtime, do you mind telling why? I would love to hear your rationale as I'm sure I'm missing an important take.

OJFord 5y ago
Ours are all python, none node. In many cases they replaced existing (non-Lambda) python code, though others were green. Why rewrite the code, or switch to node for greenfield stuff? We'd need a compelling reason to adopt node, not to avoid it. I assume the answer's roughly the same for anyone - it's odd to me that you're talking about 'ideal Lambda runtime', I'd be surprised if many people care. You're going to choose your language by however you were going to choose your language otherwise, and then run it on Lambda. And python is more popular than node in general. If you really wanted every last gram of performance, you'd be running an optimised compiled binary anyway, not using any of the provided runtimes.
- rewma 5y ago
  > Ours are all python, none node. In many cases they replaced existing (non-Lambda) python code, though others were green. Why rewrite the code, or switch to node for greenfield stuff? We'd need a compelling reason to adopt node, not to avoid it. That's a great point. I admit I followed the same exact rationale motivated by code reusie to go with Java runtimes in projects that consisted mainly of peeling responsibilities out of legacy Java services, and Java is notoriously by far the worst performing Lambda runtime. Granted, this was before lambda's pricing granularity was updated from 100ms down to 1ms. Nowadays, a JDK invocation easily costs 50x the cost of a NodeJS lambda invocation, not to mention the concurrency consequences. > I assume the answer's roughly the same for anyone - it's odd to me that you're talking about 'ideal Lambda runtime', I'd be surprised if many people care. Sure, there are other constrains and requirements, but in the context of AWS Lambdas, and taking into account the way they are priced and the fact that they run on a single vCPU and that they are mainly IO-bound, NodeJS is very hard to beat. If you're starting out a project, you're not totally ignorant regarding AWS Lambda's pricing, and you are free to pick whatever runtime you want, it is very hard to justify any rational choice other than NodeJS or, alternatively, Golang. > If you really wanted every last gram of performance, you'd be running an optimised compiled binary anyway Hence Golang. Meanwhile, NodeJS gets you about 90% where Golang takes you without taking a single step outside of the happy path.
  - 5y ago