With Fargate, AWS wants to make containers more cloud native
At its re:Invent developer conference, AWS made so many announcements that even some of the company’s biggest launches only got a small amount of attention. While the company’s long-awaited Elastic Container Service for Kubernetes got quite a bit of press, the launch of the far more novel Fargate container service stayed under the radar.
When I talked to him earlier this week, AWS VP and Amazon CTO (and EDM enthusiast) Werner Vogels admitted as much. “I think some of the Fargate stuff got a bit lost in all the other announcements that there were,” he told me. “I think it is a major step forward in making containers more cloud native and we see quite a few of our customers jumping on board with Fargate.”
Fargate, if you haven’t followed along, is a technology for AWS’ Elastic Container Service (ECS) and Kubernetes Service (EKS) that abstracts all of the underlying infrastructure for running containers away. You pick your container orchestration engine and the service does the rest. There’s no need for managing individual servers or clusters. Instead, you simply tells ECS or EKS that you want to launch a container with Fargate, define the CPU and memory requirements of your application and let the service handle the rest.
To Vogels, who also published a longer blog post on Fargate today, the service is part of the company’s mission to help developers focus on their applications — and not the infrastructure. “I always compare it a bit to the early days of cloud,” said Vogels. “Before we had AWS, there were only virtual machines. And many companies build successful businesses around it. But when you run virtual machines, you still have to manage the hardware. […] One of the things that happened when we introduced EC2 [the core AWS cloud computing service] in the early days, was sort of that it decoupled things from the hardware. […] I think that tremendously improved developer productivity.”
But even with the early containers tools, if you wanted to run them directly on AWS or even in ECS, you still had to do a lot of work that had little to do with actually running the containers. “Basically, it’s the same story,” Vogels said. “VMs became the hardware for the containers. And a significant amount of work for developers went into that orchestration piece.”
What Amazon’s customers wanted, however, was being able to focus on running their containers — not what Vogels called the “hands-on hardware-type of management.” “That was so pre-cloud,” he added and in his blog post today, he also notes that “container orchestration has always seemed to me to be very not cloud native.”
In Vogels’ view, it seems, if you are still worried about infrastructure, you’re not really cloud native. He also noted that the original promise of AWS was that AWS would worry about running the infrastructure while developers got to focus on what mattered for their businesses. It’s services like Fargate and maybe also Lambda that take this overall philosophy the furthest.
Even with a container service like ECS or EKS, though, the clusters still don’t run completely automatically and you still end up provisioning capacity that you don’t need all the time. The promise of Fargate is that it will auto-scale for you and that you only pay for the capacity you actually need.
“Our customers, they just want to build software, they just want to build their applications. They don’t want to be bothered with how to exactly map this container down to that particular virtual machine — which is what they had to do,” Vogels said. “With Fargate, you select the type of CPUs you want to use for a particular task and it will autoscale this for you. Meaning that you actually only have to pay for the capacity you use.”
When it comes to abstracting away infrastructure, though, Fargate does this for containers, but it’s worth noting that a serverless product like AWS Lambda takes it even further. For Vogels, this is a continuum and driven by customer demand. While AWS is clearly placing big bets on containers, he is also quite realistic about the fact that many companies will continue to use containers for the foreseeable future. “VMs won’t go away,” he said.
With a serverless product like Lambda, you don’t even think about the infrastructure at all anymore, not even containers — you get to fully focus on the code and only pay for the execution of that code. And while Vogels sees the landscape of VMs, containers and serverless as a continuum, where customers move from one to the next, he also noted that AWS is seeing enterprises that are skipping over the container step and going all in on serverless right away.