No More Dealing with Infrastructure (Kind of, for Developers)

Screen Shot 2017-12-01 at 3.45.39 PM.png

The most exciting announcement during AWS re:Invent for cloud computing infrastructure foundation was Fargate. There were a slew of new announcements and I don't want to de-emphasize the other ones too much, but this one was the most interesting to me.

First, a bit of background. There's lot of confusion on VMs, containers, and functions. Here are the differences:

The key thing is that the VMs allow a server to run as one big piece (OS + whatever apps are installed), containers allow applications (which includes providing microservices, but no OS, but the underlying system beneath the container layer provides the Linux interface) to run, and serverless is a place to run code (or functions). Each stage enables slicing a workload into smaller pieces.
Fargate is a system that enables you to run deploy your containers on AWS, and do so in a way that’s just as easy as getting VMs from EC2. This allows developers to ignore the setting up of infrastructure. 

Note that on AWS, you already have managed Kubernetes known as Amazon Elastic Container Service for Kubernetes (Amazon EKS). It is very much like managed Kubernetes (K8S) on other platforms such as Google Cloud, as Google was the original developer of Kubernetes and has been a leader in supporting it. Setting up Kubernetes clusters is a pain to do, and getting rid of that toil is a great thing to do. Fargate goes further than just managed K8S.

You can avoid dealing with managing the underlying container instances. The steps to run the containers are:
  1. Build a container image.
  2. Specify the low level requirements for CPU and RAM.
  3. Set up the networking and IAM policies.
  4. Run the containers and off you go.

With Fargate, the configuration options can be set up to meet the application and financial needs and you’re billed at a fine level of granularity.

The most important thing is that it is a step towards enabling developers to focus on the business logic and not setting up infrastructure or managing it.

There are a lot of silly discussions on whether or not containers are the new VMs (they are not – and that is a bad misperception). Or why it's called serverless if there are servers underneath (it is meant to state that it is a function that runs, not an application or an OS that implies a server, or a virtual server). It’s important to realize that one model does not supplant another. They are all useful in their own ways.  For some people, it's OK To run a VM, and others need containers. 

The important takeaway is that we are evolving the computing platform that enables us to 1) decompose workloads into their most basic components and 2) to evolve the underlying platform to take care of resource management.

This frees the developer from wasting time coding the management of resources and the operator from configuring it. In the future, all the code you ever write will be business logic. It’s a matter of choice – if you need a VM you can get that. But in the past, that was all we had. Now we can deploy apps or functions in addition to VMs.

The takeaway? Use the right deployment model that fits your workload. We now have many choices. If you’re event-driven, use serverless (such as AWS Lambda). If you want to define and deploy microservices, containers are a good way. If you have monolithic apps (or pieces of them), then VMs are a comfortable place to be.

Topics: Networking AWS re:Invent Cloud Services & Orchestration