re:Invent Revisited - AWS Fargate
The 2017 edition of re:Invent had some great announcements. In my previous post we looked at the 2017 announcement of AppSync which didn’t make a keynote. In this post we’re looking at AWS Fargate, announced in Andy Jassy’s keynote, then revisited in Werner’s never ending keynote the next day by Abby Fuller.
In the same keynote AWS’s managed Kubernetes service Amazon Elastic Kubernetes Service (EKS) was announced. AWS launching a managed Kubernetes service was always expected. It would have been a bigger announcement if they didn’t launch something in that space. For AWS launching a managed version of an open source project is an acknowledgement they have enough customers running that software themselves that would prefer AWS to run it for them.
There is a growing number of AWS customers that choose Fargate as their first destination when migrating to container based infrastructure. Vanguard got on the re:Invent stage in 2019 to talk about their AWS migration, with Fargate providing an easy migration target for their existing aPaaS. They skipped the Kubernetes learning curve, and lifted their entire aPaaS into Fargate. Far from alone, organisations as diverse as Samsung Electronics to Square have migrated significant infrastructure to Fargate.
I see Fargate as the next generation of EC2. EC2 abstracts away hypervisor management and removes management of underlying physical infrastructure from end users. Fargate abstracts away container orchestration management plane and removes management of underlying virtual machines.
With Fargate the major difference between the two is application encapsulation at container not virtual machine level, resulting in a lightweight portable artifact, with a trade off on constraints on operating system choice. Unfortunately that Windows NT 3.51 VM that should have died in a fire 15 years ago cannot live on in Fargate. The upshot of this is Fargate provides significant cost reductions over virtual machines, improved performance and agility, without the overhead of thinking about container orchestration.
AWS Fargate is not first to market. Microsoft Azure Container Instances (ACI) is similar and predates it. Predating both is Hyper.sh’s Secure Container Platform. Like Iron.io, a startup that pioneered Functions as a Service before AWS, Hyper.sh no longer exists. It’s engineering group quietly moved Ant Financial Group some time in 2019.
Early container implementations had the problem of not providing the same level of isolation as virtual machine hypervisors. This limited the adoption of containers in secure environments. Hyper.sh provided a solution to this by creating their own OCI compliant container runtime, runV, that would run on top of a lightweight hypervisor. This provided a lightweight VM with a container interface, but all the security and isolation of a virtual machine. In conjunction with Intel in 2017, Hyper.sh open sourced this approach through the Kata Containers project. Not surprisingly Ant Financial Group are a large user of Kata Containers.
At re:Invent 2018 AWS announced the Firecracker microVM. A lightweight hypervisor written in Rust, used by AWS Fargate and AWS Lambda. Under the hood AWS Fargate borrows a lot of the concepts from Kata Containers and the original Hyper.sh platform. An OCI compliant container runtime on top of a lightweight VM, albeit with a tech stack they’ve created.
In a full circle moment, Kata Containers now supports the Firecracker microVM, and Ant Financial Group, with the old Hyper.sh engineering team, are using it today.
I predict AWS Fargate is the future of container infrastructure. For the same reasons that EC2 displaced VMware’s vSphere as the VM platform of choice, Fargate will become the container platform of choice, displacing Kubernetes. It provides all the security of a VM, with the benefits of a container, with none of the management of an orchestration platform.