Countless volumes have been written about the various benefits of serverless, a task made even easier by it being such a squishy, nebulous term that’s come to mean basically whatever the author wants it to mean. This has been a boon for AWS’s product teams, who’ve gone from creating services that are clearly serverless such as DynamoDB, Route 53, IAM, and others to instead slapping the “serverless” moniker on things that are clearly not very serverless at all, like OpenSearch and Aurora.
One service that is very clearly serverless is Lambda, AWS’s Function as a Service. It epitomizes the best of a moving target with respect to “what defines serverless.” It scales down to zero, you only pay for what you use, it’s massively event driven, and at least in theory AWS manages the care and feeding of the service so the only thing you have to worry about is your own business logic. Unfortunately, as of this writing AWS has apparently gone out for lunch and forgotten to return for several quarters to fulfill their part of the serverless bargain.
Serverless Abdication
AWS Lambda has various supported “runtimes,” which are language-specific function environments that include various versions of supported programming languages. The one I want to talk about today is the language runtime I spend the most time working with: Python.
Version 3.10 of the Python programming language was released to General Availability in October of 2021. Now in the closing hours of February of 2023 there have been ten further releases of the 3.10 major version; Python 3.10.10 is the current generally available branch of Python 3.10. Python 3.11 was released to general availability in October of 2022, with its current stable version (as of this writing; I’m not going to go back and maintain this every few weeks!) of 3.11.2 released in early February of 2023. Python 3.12 is the version that’s currently in development.
I bring this up not because I’ve passed the keyboard over to everyone’s favorite vampire, Sesame Street’s Count Von Count to indulge his love affair with counting programming language version numbers, but rather because the current state of the art of Lambda’s managed Python runtime is version 3.9 and has been since August of 2021. This has gone from “okay, it’s taking a bit of time” to folks having to actively do extra work to make up for AWS’s lack of velocity on keeping current with Python. A GitHub Issue asking for Python 3.10 support started off very politely / reasonably in December of 2021. It got slightly more heated in May of 2022 when Python 3.9 entered the “security only” portion of its lifecycle. In just over a month from when this publishes, Python 3.10 will enter the “security only” lifecycle phase, and is tracking to not have had an officially supported Lambda runtime at all during its moment in the sun.
What are you doing over there, AWS?
I’m not bringing this up because I’m looking to taunt AWS about things out of a misplaced sense of pettiness; if I wanted to play those games I’d simply point out that Amazon Linux 2022 is still in the Release Candidate stage and has been relabeled to “Amazon Linux 2023” in the hopes that nobody notices just how far behind schedule it is. That would be petty, because it’s ultimately AWS’s own distribution of Linux, and they can release it when they’re damned well ready to.
Lambda is different; it’s an “AWS manages the moving parts for you” service. That’s how it was presented, that’s the explicit contract AWS has made with us in the spirit of the Shared Responsibility Model. Python 3.11 is on average 25% faster than its predecessor, with a host of enhancements and changes to the language. I personally have had to refactor code to run on Python 3.9 so that I could turn something into a Lambda function.
There’s nothing particularly special about Python that would explain this delay; Google Cloud Functions and Azure Functions both support Python 3.10. A number of folks in the GitHub Issue have reported success along with instructions to build a custom runtime that supports modern Python versions as well. It’s clear that there’s no technical blocker preventing AWS from supporting the language, leading me to the conclusion that it’s instead either a lack of leadership, or a lack of will–which effectively reduces down to the same thing.
This is Important
The Go runtime is so old that it doesn’t support Graviton-based Lambdas, and the Ruby runtime is likewise fairly moribund. But AWS announced at re:Invent 2020 that Lambda had over 1 million customers, and the 2022 Datadog State of Serverless report indicates that Python is the single most widely used Lambda language, slightly edging out Node.js. This is a problem that impacts virtually every AWS customer.
Doing It Ourselves Is Not an Answer
We’ve been able to use custom runtimes ourselves for a while, and via the magic of Docker container images we can basically make Lambda run whatever the heck we want it to. Unfortunately, building our own Python runtimes at home isn’t sustainable as a customer; we’d all universally be signing up for a massive pile of work, as we’d be taking on the burden of keeping those runtimes patched and updated ourselves.
The LTS version of Ubuntu uses Python 3.10. AWS’s major competitors all support Python 3.10 at a minimum. It’s long past time for AWS to either ship the language runtime customers are (quite reasonably!) clamoring for, or else offer up better transparency than the “we’re working on it” stonewalling that we’ve gotten for over a year.
AWS Lambda’s value proposition was and remains that it removes undifferentiated heavy lifting for customers. Please lift this heavy, undifferentiated burden for us.
