AWS Lambda support for container images is arguably the most significant development since the service was first announced. For the past month, fourTheorem has been evaluating Lambda Image Functions as part of the private beta. This is a game changer that will open the field to a large number of new applications including financial modelling, legacy systems migrations, data science and machine learning.
What do Lambda Image Functions enable?
- Existing container-based workloads can now be run in AWS Lambda (with some modifications).
- Lambda functions deployed using container images can be up to 10 GB in size, a 40x increase on the limit for Lambda functions packaged as ZIP, including all layers, of 250 MiB. Note that the 250MB limit still applies to functions packaged as ZIP.
- Container Image-based Lambdas allow developers to utilise the large and mature container tooling ecosystem that has grown since the introduction of Docker in 2013.
- It becomes easier to integrate containers into the other AWS and third-party services that Lambda supports.
- Developers can use the vast range of base images already available.
- Local development, testing and debugging becomes faster and more productive using the Docker CLI.
- Container image layers can be deployed and versioned in ways not possible with Lambda layers.
At fourTheorem, we are advocates of the serverless-first approach. We sometimes reach for Fargate and other container services when the Lambda limits make it difficult to run certain workloads there. This always comes with a downside. Even with a managed, “serverless” container system like Fargate, the deployment and maintenance responsibility of the infrastructure is undifferentiated heavy lifting.
In addition, none of these existing cloud container services have the managed, on-demand scaling characteristics of AWS Lambda. We have even spent time building and tweaking custom auto-scaling for Fargate to try and achieve the scaling performance required for on-demand enterprise financial modelling workloads. Lambda container image support does away with this overhead and bridges the gap that existed between existing container services and Lambda. Of course we cannot ignore the fact that the cost model for AWS Lambda differs from the other container services and is more expensive per unit of compute time. The increased cost will have to be evaluated for meaningful workloads and viewed in the context of value delivered, development time and maintenance cost.
What did we find?
We evaluated batch processing and machine learning jobs that represent typical enterprise workloads for our customers. We decided to focus on these rather than web applications that are already amenable to running in Lambda for the majority of cases.
We tested:
- New images based on the provided Lambda base images
- Existing, larger based images extended to include the necessary Lambda
- Runtime Interface Clients
- Local execution using the AWS Lambda Runtime Interface Emulator Integration with event sources like Kinesis and SQS
Since Lambda Image Functions use Elastic Container Repository (ECR), deployment is exactly the same for the code as it is for existing container images. The differences come with the requirement to use the Lambda Runtime Interface Clients in your image as well as in how you configure the function itself. Previously, functions could be specified inline (if small enough) or by referencing a ZIP archive on S3. Now, a function’s code can be a reference to the container image in ECR. From that point on, everything operates in the same way as a normal Lambda. Provisioned concurrency support is currently available but was not during the Beta so we did not test it out.
The most impressive workload we ran consisted of a 1.5 GB deep learning image containing many Python modules like PyTorch, Pandas and SciPy as well as trained model data. We loaded 120,000 lung CT images from the NIH Chest X-Ray set onto S3. See the references below for the relevant links. We added the Lambda Runtime Interface Client to the deep learning base image and added a small wrapper to load an image, perform a diagnostic prediction and push the result to DynamoDB.
With a modest memory size of 1024 MB, our test showed that we could compute predictions for the full result set of 120,000 images in well under three minutes. The Lambda function concurrency scales to 1000 ‘immediately’ (within about five seconds of invocation).
Setting aside the deployment and development benefits of image functions, these scaling characteristics for containers are what makes this feature most exciting. Reaching 1200 containers in Fargate with ECS takes about 45 minutes. The relative scaling performance of ECS and EKS were covered well in an article by Vlad Ionescu. Lambda upscaling and downscaling performance with containers leaves everything else in the dust.
This performance is not just about production workloads, of course. On-demand compute that scales so quickly has major benefits for efficiency during development, deployment and testing. When scaling is not instantaneous, the time to deploy builds up and costs time and money. It’s important to realise this when considering that Lambda will cost more per second compared to EC2, ECS and EKS.
Enterprise Benefits
Lambda’s Container Image support brings less-tangible but possibly greater benefits when it comes to larger enterprises with established container usage. In such organisations, Lambda usage is often restricted to less critical automation and operational tasks. Migrating core business workloads to Lambda was previously seen as a step too far, with the risk of abandoning the investment in platforms like Kubernetes. The option of deploying functions packaged as container images to Lambda should break down this barrier and allow a much wider range of enterprise workloads to run there. Development and operations teams will be able to leverage existing skills and tools, reducing the barrier to migration.
It will be fascinating to see if the this feature opens the floodgates for mass enterprise adoption of AWS Lambda. It certainly has that potential and, as Lambda continues to evolve, the technical and economic benefits of rapid development and scalability will become very difficult to ignore!
For a technical assessment of the new Lambda Image Function feature, see our technical deep dive!
References
- https://github.com/fourTheorem/lambda-image-cxr-detection
- Automated abnormality classification of chest radiographs using deep convolutional neural networks, Yu-Xing Tang, You-Bao Tang, Yifan Peng, Ke Yan and Mohammadhadi Bagheri, Bernadette A Redd, Catherine J Brandon, Zhiyong Lu, Mei Han, Jing Xiao, and Ronald M Summers, npj Digital Medicine, 2020
- Chestx-ray8: Hospital-scale chest x-ray database and benchmarks on weakly-supervised classification and localization of common thorax diseases, Xiaosong Wang, Yifan Peng, Le Lu, Zhiyong Lu, Mohammadhadi Bagheri, and Ronald M Summers, Proceedings of the IEEE conference on computer vision and pattern recognition, 2017
- New for AWS Lambda – Container Image Support – amazon.com – https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/
Get in touch with us to share your thoughts.
