Hello all!
Welcome to the next issue of the Tidy Cloud AWS newsletter! In this issue, I will cover a few things about running containers in AWS. and making that better, cheaper, faster, more productive.
Enjoy!
Faster container startup in Fargate
AWS introduced Seekable OCI, a technology that enables lazy loading of container image content, almost a year ago.
This technology reduces the load times of container images at startup. Depending on the container image setup, not all files and data in an image are used, or used right away. So by only loading the content that is actually used and needed, startup times can be reduced.
Recently, AWS posted a blog post that Seekable OCI is now supported in AWS Fargate - further down in the post it states that it is specifically for Fargate on AWS ECS, so perhaps Fargate with EKS is still out of luck?
The container images remain the same. New manifests were added that show file locations and sizes in the container image layers.. So any existing container image can be made into a “seekable OCI” and thus can lazy load in AWS ECS Fargate, assuming that the image is loaded from AWS ECR.
The blog post is quite good and presents both a command-line tool (soci) and a deployable lambda solution to make the images seekable. The post also compares start-up times for images that are seekable vs. non-seekable.
Both the results of the blog post and from some customer quotes point to an improvement in startup time by around 50%.
The steps to make image seekable seem straightforward, so should be a useful addition for container deployment in ECS Fargate.
Check also out the video on YouTube’s “Containers from the couch” channel that discusses the new Seekable OCI feature in AWS Fargate. It is about an hour long.
Better container images
Another lovely blog post from AWS is one with the title Building better container images. It goes through a couple of items on handling secrets, signing and securing images, and optimising image content. It is a nice piece with some useful tips, most of them which are not specific to AWS.
The blog post here also pointed to a command-line tool called Finch. It is a command-line tool for container-based development. You can consider it an alternative to the docker command-line interface, without the Docker Desktop user interface.
Finch is a wrapper around a few open-source tools in this space, including nerdctl. These are packaged together to make the installation simple. Finch is currently macOS only, but there are plans for Windows and Linux support in the future.
Fargate cost optimisation
Compute Optimizer is an AWS service that analyzes compute-oriented resources and recommends enhancements. Watch Cost optimization on AWS Fargate video on Containers from the couch YouTube channel to learn about using Compute Optimizer for AWS Fargate, on ECS. The Compute Optimizer considers optimisations for both performance and cost, with a preference for performance.
The Compute Optimizer service is free, you just have to enable it. It can be enabled at the organisation level through AWS Organizations as well.
ECS Blueprints
For some time now, AWS has provided a set of ECS Blueprints which are templates to make certain types of workloads in AWS ECS easier to set up. Initially they have been available for Terraform, but now they have also added blueprints for AWS Cloud Development Kit, as announced in a recent blog post. The code for the blueprints can be found in a GitHub repository https://github.com/aws-ia/ecs-blueprints, both for AWS CDK and for Terraform. The AWS CDK examples are written in Python.
It is a nice addition that AWS added AWS CDK examples here, and I think it is also good that there are examples in Python. There need to be more example code in languages that are not called TypeScript.
There is also an online workshop for the ECS Blueprints, which covers both Terraform and AWS CDK as well.
You can find the contents of this bulletin and older ones, and more at Cloudgnosis.org. You will also find other useful articles around AWS automation and infrastructure-as-software.
Until next time,
/Erik