This post requires some knowledge of Docker and setting up containers according to best practices. We recommend reading: 5 Tips to Getting Started with Docker.
We’ve all been there. You’re just settling in for the night, ready to relax after a long day of server fires you’ve had to put out.. and you get a call. Another server has failed. This begs the question: is it time to get rid of your physical servers?
Fargate is AWS’ serverless super-hosting platform. It is the next generation of what AWS originally released as ECS, or Elastic Container Service. The biggest difference is that originally ECS required you to manage EC2 instances, like servers, so it was not truly serverless. With Fargate, there is no need to patch, scale, maintain, or even manage a server. You simply create a release, give it plenty of resources, and get billed by the hour the container runs.
Fargate is an AWS specific service, but Google Cloud and Azure have similar offerings.
At Six Feet Up, we are utilizing containers to speed our development and deployment process. If you are deploying containers, you are most likely still maintaining the infrastructure below. Fargate is a possible option now to avoid the headache of maintaining our own servers. Should you consider going completely serverless for your containers?
If you’re running more than just a basic app or a simple static website, Fargate might be a good solution for all of the application bits you deploy. As an example, we spent no time setting up Fargate to run a Plone application that had been dockerized to do document indexing, image scaling and conversion. Years ago, we would have spent 4+ hours setting up a physical server and getting all the dependencies together to finally run Plone.
With the help of EC2 in virtual machines, images and Salt, we’ve been able to automate the majority of this process and gotten the initial deployment time down to minutes instead of hours. But you are still on the hook to manage hypervisors and the VMs that are running the containers in your infrastructure. Fargate is the final puzzle piece that allows us to skip fiddling with server configurations and hypervisors. We’ve got our Docker file with all the necessary resources ready to go so we can spin up a fully functional Plone site in seconds rather than hours.
Plus, if you realize later on that you need additional resources, databases or load balancers, you can always deploy those in containers or use the other cloud based versions of these resources. The simplicity of Fargate makes it possible to run a simple instance or even cluster it into multiple instances that can scale to handle a bunch of load.
True serverless computing has to have some kind of drawback, right? Truth be told, Fargate’s UI can be a little tricky, so take your time working through your first cluster. Read. Those. Docs. If you really want to leverage the power of Fargate, make sure to check out automated ways to deploy with Terraform or CloudFormation. This will saves you tons of headache and make your deployments reproducible.
Setting everything up in Fargate may not be quite as straightforward as you might hope, but once you gain an understanding of the terms, you’ll be able to run containers like there’s no tomorrow.
All of this “serverless”-ness does come at a premium. The hourly costs of running your containers on ECS are going to be higher with Fargate than if you were to have just deployed EC2 instances and deployed your containers to those VMs. Luckily, there is a benefit to doing this and you have to weight the cost benefit to deploying fully serverless.
The AWS ECS service does offer the ability for mixed deployments in the clusters so you can leverage Fargate for portions of the application that make sense and deploy to EC2 instances for portions of the application that might be cost prohibitive in Fargate.
Start by getting yourself familiarized with Docker. It is also worth checking out container registries, like AWS’ ECR or Docker Hub. Why? Container registries give you security checks that will look at your container/image and the dependencies that are installed into it, and see if there are any open CVEs or security issues hiding within.
Security, automation, and consistent deployment - what more can you ask for?
Additional reading/examples:
Do you have questions? We’re happy to help. Just ping us.
Six Feet Up, Inc.
11208 Windermere Blvd.
Fishers, IN 46037 - USA
Phone: +1 (317) 861-5948
Email: info@sixfeetup.com
