Turbocharging your technology strategy with ECS and Fargate

This article was originally published on The Scale Factory blog here.

Do you want to migrate to AWS and harness the power of the cloud in your business? Well, ECS with the Fargate launch type (I’ll shorten this to “ECS+Fargate”) is one of the foremost compute technologies you should consider when migrating.

ECS+Fargate can help your business reduce costs, go-to-market more quickly, and maintain high service uptime. Compared to alternative solutions, ECS+Fargate finds a great balance between complexity, configurability, and vendor lock-in that works out as a great fit for many SaaS businesses. In this article, I will explain ECS+Fargate, elaborate on the benefits to using it, and compare it against alternatives.

What is a container?

To understand Elastic Container Service (ECS) and Fargate let’s take one step back and first understand containers.

A container is a lightly isolated grouping of one or more applications and their dependencies. Containers are intended to enable applications to run consistency and reliability on different machines.

Containers in their current form were originally created as part of the Docker application. Since 2015, container technologies have been defined in open standards such as the Open Container Initiative (OCI) container image format. These standards are managed by the Linux Foundation, or the Cloud Native Computing Foundation (part of the Linux Foundation).

Why adopt containers?

Before containers, applications would often be installed directly on a server with no isolation, using traditional methods such as package managers. If you wanted a boundary between two components, you needed to pay the costs of running a whole server, or whole virtual machine, twice. Applications installed via traditional means can suffer from problems with reproducibility – the application might display different behaviour on different machines. A common example might be between a developer laptop and a production server, or even between production servers running slightly different operating system versions. Diverging behaviour is not ideal as it can lead to bugs that cannot be tested for in pre-production environments and also elongates the development process.

Container technologies let you build an artefact - a container image - that will function identically on a developer’ workstation, on an AWS service, or even in a different cloud if you ever needed to migrate.

Container image builds can be quick - usually only a few seconds - and the build process is specifically designed to cache previous steps. This all adds up to faster feedback to developers, which means the capacity to deliver more valid more often.

As containers are an industry standard, there is a wide ecosystem of tools that can integrate with them. For example, there are tools that can scan containers for security vulnerabilities.

Some other benefits of containers include:

• Fewer production bugs: the consistency of containers means you can run, and test, the exact same artefact in all environments.
• Increased developer productivity through faster feedback: dramatically lower the chances of changes being introduced that work on the local machine but fail in testing.
• Faster scaling: traditionally each instance of an application might be run on a separate virtual machine – usually taking some minutes to start. ECS tasks can start in seconds.

What is ECS+Fargate?

A container is a single instance of your application. What if we want more than one instance of the application? What if we want to use more than one machine to achieve high availability? How do we deploy the container on the machines? How do we expose containers to networks?

Container orchestrators were created to solve these problems and ECS is one such container orchestrator.

ECS can work with either EC2 – AWS’s virtual machine service – or Fargate launch type. Fargate enables you to run containers without worrying about the underlying virtual machines and bare metal – AWS manages that for you.

ECS+Fargate can deploy one or more container instances to a network, expose it to a load balancer (which in turn might expose it to the Internet or other networks), and scale the number of instances up and down to match load. You can integrate ECS with CI/CD pipelines for quick low risk deployments and rollback. You can work with external systems such as GitHub Actions and GitHub Deployments, or you can stay within AWS and use CodePipeline with CodeDeploy.

Why use ECS+Fargate?

Cost savings

As an elastic service, ECS can scale automatically against a metric of your choosing from one container to many. A single container could be running in the dead of night and scale to 1000s to meet peak-time demand. On paper, Fargate might seem to be slightly more expensive than EC2. However, in EC2 you will likely have to slightly overprovision nodes to enable seamless service scaling and managing virtual machines (VMs) is labour intensive. On Fargate, you only get charged for the containers you use and do not manage the underlying VM.

Compared to on-premise infrastructure, there is relatively little that requires management by an operations team. Operations teams can be leaner and more focussed on work that is closer to value centres.

Security

Earlier, I mentioned that containers are lightly isolated. ECS groups containers into tasks (usually just 1 container per task) and Fargate provides strong isolation between different tasks. It’s serverless and the isolation is all managed for you.

Managing virtual machines (or bare metal) can be expensive, time consuming, and can increase risk (especially if your business must comply with information security standards). Delegating these problems to your cloud provider enables your business to focus on value delivery.

Ease of exit

ECS+Fargate is a relatively simple method of running containers in the cloud, however, it’s also flexible enough to suit many SaaS providers on AWS. Alternative container orchestrators (such as Kubernetes) are great, however, they are typically much more complex. The total cost of ownership for ECS+Fargate alternatives can be much higher, sometimes for little/no increased business value.

Kubernetes is a great technology but we often find it is embraced too early on a company’s journey, incurring unnecessary additional costs. Luckily, it doesn’t have to be either ECS+Fargate or Kubernetes; once your application is containerized, it could be migrated to Kubernetes at a later date. Containerization is the main obstacle.

AWS Lambda is another top alternative to ECS+Fargate. Like Fargate, Lambda is serverless and very scalable. Lambda is a proprietary technology and can force an architecture that is very AWS-specific. Lambdas can also run containers with slight modification, however, functions currently must finish executing in 15 minutes or less. There is increased risk from vendor lock-in and it could be more expensive than ECS+Fargate for traffic patterns that don’t suit the AWS Lambda architecture.

Shifting capital expenditures to operating expenses

Before the advent of utility-scale cloud computing, businesses looking to create a computer-based product or service would have to invest a large amount of capital upfront in technology like servers and even data centres. The lead time on obtaining these technologies might also be months.

With ECS+Fargate, you only pay for what you use. Your infrastructure lead time is measured in seconds, and you can use up to 120GiB of RAM. It’s a limit, but it’s usually more than enough.

Service uptime and deployments

Most of the heavy lifting in creating effective monitoring and deployment for ECS+Fargate tasks has already been done by AWS; you just need to do high-level configuration of the tools they have already created.

You can configure deployments to rollback to an older working container automatically if the error rate increases; this empowers your team to innovate quickly, even shipping test code all the way into production, while keeping the impact of mistakes low.

Basic metrics for ECS+Fargate appear in AWS’s monitoring service CloudWatch automatically. Baseline CloudWatch is part of the AWS free tier, however, its free tier is limited and more advanced or granular features do incur cost. To tie monitoring more closely to business outcomes, you can add customer CloudWatch metrics. If there are problems, integration with CloudWatch Logs works out of the box. Your workload on ECS+Fargate can integrate with other AWS observability services such as X-Ray (for per-request tracing), or Amazon Managed Grafana.

You can automate away tedious manual (or semi-manual) deployments by integrating ECS+Fargate with CI/CD pipelines.

Development experience

Adopting containers often leads to happier developers. As containers can be built and start in seconds, developers can get very fast feedback about their changes. Reducing rework reduces stress on the team, and helps make delivery timelines more predictable.

Integration with other AWS services

After migrating to containers on ECS+Fargate, your workload can benefit from other cloud services to reduce costs, solve problems, and automate away repetitive tasks.

For example:

• AWS Backup can be used to create a central, cost-efficient, and automated back-up strategy.
• Security Hub can be used to ensure your company is meeting established security best practices such as the CIS Benchmarks.
• Version 2 of Amazon Inspector can automatically scan your container images and virtual machine instances, notifying you of any high risk vulnerabilities.
• You can automate or avoid many tasks associated with operating SQL databases, by using Amazon RDS.

Businesses by and large experience many of the same technology-related problems. AWS enables SaaS providers to solve many of these problems at a level of cost and efficiency that would not be possible in-house.

Need help?

Migrating to AWS, and considering using containers in the cloud? Talk to our team for a free initial chat about which approach will best fit your business.