Migrating to AWS ECS Fargate in production

Following my talk at the AWS Summit Tel-Aviv 2018, I’m sharing our end to end journey of migrating our production environment to ECS Fargate.

Why we migrated to Fargate

We believe in focusing on our business and customers. As such, we prefer using products-as-a-service solutions rather than maintaining our own infrastructure. This is why migrating to Fargate made a lot of sense for us.

Focusing on our business and customers means delivering features fast and, by migrating to Fargate, we no longer have to deal with the overhead of managing EC2 instances.

Above – datree’s dev stack

Some compelling reasons for migrating include:

No more EC2 instance management

We have no interest in managing AMI’s and configuring auto-scaling-groups to increase and decrease capacity.

Operating System Management

All of our code is packaged using Docker containers, so we are responsible for what runs within our containers. We know the value of handling tasks such as Linux Patching, Docker service updates and ECS Agent updates.

Scaling

We no longer deal with scaling EC2 fleets or taking care of bin packing our instance to run cost-effectively.

Compliance & Security

As part of our product at datree, we access our customers’ code base to provide insights. Compliance and security are our top priorities. As of march 2018, Fargate is certified as SOC 2, HIPAA, PCI-DSS which provides out-of-the-box security for us.

Post migration, datree’s platform looks like this:

From EC2 Fleet to ECS Fargate

We now only focus on the Docker containers layer.

Benefits of migration

Additional benefits of ECS:

• Out-of-the-box log management and integration using CloudWatch logs
• Auto scaling and task distribution
• Cost savings – pay for what you use – not what you (over) provision

How we migrated

We migrated microservice by microservice from our previous ECS EC2 cluster. The migration process itself is very straightforward:

1. Switch network mode to ‘awsvpc’
2. Switch ‘Compatibility type’ to Fargate
3. Remove Soft/Hard limits
4. Set your CPU and MEM requirements

A hybrid model is also supported – so you can run a mixed cluster with Fargate and classic EC2.

Migration challenges

Longer deployment times (up to 10m)

When we migrated to Fargate, we noticed that our deployments were now taking longer – up to 10 minutes.

Our deployment cycle is fully automated and we have a full CI/CD process set up, so the added deployment time has no impact. Once a developer commits code to GitHub, a Travis build job is triggered, which builds a Docker container and pushes it into ECR. Then we use a simple bash script called ecs-deploy to create a new task-definition and update the service with it.

Scheduled tasks are not supported on Fargate

Early on we thought this might become an issue, as we had several scheduled tasks on our previous EC2 cluster. The fact that Fargate does not support scheduled tasks would force us to have an EC2 cluster to support them.
We found a very simple solution. We used AWS Lambda Scheduled Events (powered by Amazon CloudWatch Events) which can trigger an ECS task – which means moving the scheduler from ECS onto Lambda. Here is an example.

Your turn. Have you considered migrating to Fargate? Why or why not?

‍