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.
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:
We have no interest in managing AMI’s and configuring auto-scaling-groups to increase and decrease capacity.
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.
We no longer deal with scaling EC2 fleets or taking care of bin packing our instance to run cost-effectively.
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.
From EC2 Fleet to ECS Fargate
We now only focus on the Docker containers layer.
Additional benefits of ECS:
We migrated microservice by microservice from our previous ECS EC2 cluster. The migration process itself is very straightforward:
A hybrid model is also supported – so you can run a mixed cluster with Fargate and classic EC2.
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.
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?