Ken Collins is an AWS Serverless Hero and Principal Engineer at Custom Ink where he focuses on growing their DevOps culture within the Ecommerce teams using AWS-first well-architected patterns.
Ken is a huge advocate for, and pioneer of, running Ruby in serverless environments (AWS Lambda in particular) and we had some questions for him about how Ruby fares there:
Why should Rubyists consider running Ruby apps serverlessly?
Don't worry, I’m not here to pitch you on microservices or convince you to smash your beloved Rails application into hundreds of little function calls. AWS Lambda is a wonderful deployment target that can host your entire application, similar to Heroku, with little to no internal changes.
Lambda is a commoditized compute platform of the future. Event-driven and deeply integrated within AWS, it allows your Rails architecture to be completely reimagined atop fully managed infrastructure resources like API Gateway, SQS, S3, CloudWatch, VPC NAT Gateways, IAM, and so much more. Using Lambda can help you or your engineering teams learn to "program the cloud”.
What's the performance like? Are "cold starts" a problem?
Surprisingly excellent! From small infrequently accessed apps to ones that service many millions of requests a day, Rails will do just fine on Lambda. We've found it can meet or beat EC2 while providing better auto scaling options with a little cost reduction too.
If you have discounted AWS Lambda because of “cold starts” - please reconsider. First, if cold starts were a problem, you can essentially turn them off with a new feature called 'provisioned concurrency.' But I doubt you will ever need to. Second, the majority of Lambda’s compute lifecycle will have your Rails application fully loaded and warm. An application's 2 to 4 second initialization statistically disappears for avg, p95, and even p99 metrics in high traffic scenarios. Lastly, some may remember that using a VPC with AWS Lambda incurred significant start up penalties. This has been solved since September 2019 and using a VPC now has no startup time cost.
In other performance news, AWS just announced that Lambda was working out while staying at home and social distancing. A function can now have up to 10 gigabytes of disk space, 10 gigabytes of memory, and up to 6 vCPUs as memory scales. Since Lambda shards horizontally, akin to one process, we have found that most applications only need 1,792 megabytes of memory equal to 1 vCPU.
What does Lamby do and why is it necessary?
Lamby is a simple Rack adapter. It converts Lambda invocation events from different AWS sources like API Gateway or Application Load Balancers and converts them into Rack events. It essentially turns one hash into another.
Though technically not fancy, what this unlocks is kind of mind boggling. By integrating AWS directly to Rails' HTTP layer, we have essentially removed the need for any web server. This includes everything from Apache or NGINX all the way down to Puma or Webrick. As you explore Rails on Lambda, this pattern of evaporating concerns, will be a common theme.
Ruby didn't become a first class language on AWS Lambda till late in 2018 which hurt its early adoption for serverless use cases. Do you think Ruby has a long term future on serverless platforms?
No matter what happens, Ruby will always be available for Lambda thanks to their new container support and open runtime interface which has been open sourced for Ruby. Currently AWS provides official runtime images for Ruby 2.5 and 2.7, but if your needs ever differ, we can now bring our own OCI (v1 and upward) compatible images to Lambda with the same runtime guarantees.
I believe in AWS. I believe they will provide an official Ruby 3 runtime shortly after its release. I am also very thankful they have supported me and my open source work like Lamby. So if you ask me... they are here for us.
