The Impact of Migrating to Amazon’s ECS and Cloud-Front on Dev Teams’ Productivity
This blog lays out the steps the dev team at FastPay (gofastpay.com) undertook to modernize its AWS infrastructure by using Docker, Elastic Container Service (ECS), Cloud Formation, and Cloud Front to deploy its micro-services and front-end applications.
Motivation
Cloud technologies have evolved from merely spinning a virtual machine on the cloud to running applications within docker containers hosted on a managed infrastructure (serverless, ECS on EC2, ECS on Fargate, EKS, etc…). The current hosting technologies abstract the underlaying infrastructure and make managing the infrastructure a developer’s task more than it is a system administrator’s task. In such case, I argue that not having your dev team involved in this process is counter productive.
Not having your dev team involved in your cloud deployment process is counter productive.
In FastPay’s case, prior to migrating to using ECS and Cloud Front, we ran EC2 instances provisioned by OpsWorks, a process that also controlled the deployment of our applications. The dev team was not part of this process which hindered our abilities to experiment with new applications and release to production new applications or features. This became more of a bottleneck when we aquired AnchorOps in 2017 and we were tasked to merge the applications under the same AWS account.
Impact on the Dev Team Productivity
The impact of such migration has been enormous on the productivity of the dev team who now understands the end-to-end deployment process and is probably the most qualified to understand the different optimization and auto-scaling techniques available on AWS and hence able to modify the code or write its services accordingly. Here is a brief list of the benefits we reaped from such migration:
1 — Security: No EC2 instances to provision which reduces security risks.
2 — No downtime during deployment: For micro-services, the application load balancers handle redirecting the API calls to the running task(s) (a task is an instance of a service) and gracefully shutdowns older tasks (based on older code). This assumes that your code is backward and forward compatible with the DB changes (if any). The same applies for deploying front-end applications using Cloud Front.
3 — Auto-scaling and cost saving: One of the interesting feature of ECS is that you can decide the number of tasks you want to run for each service and provide auto-scaling triggers. ECS handles distributing the tasks on available EC2 instances and also spins more EC2 instances when needed.
4 — Provisioning new environment: With Cloud Formation, provisioning, stopping, and deleting new environment would take few minutes. Deleting an ECS cluster created using Cloud Formation deletes all dependent resources which keeps your AWS environment clean.
5 — Easier AWS Management: This makes it easy to share AWS knowledge among your dev team.
A — MicroServices Migration
1 — Docker First
i. Secret Manager and Cloud Watch
The first step was to alleviate the dependency of ours applications from the underlying EC2 instances they ran on and this started by migrating the passwords saved on our EC2 instances to AWS’s Secret Manager and redirecting applications’ logging to AWS’s Cloud Watch. The link below redirects to another blog post that shows how we migrated our micro-services to using AWS Secret Manager.
ii. ECR, Docker, and Docker-Compose
The second step was to dockerize our applications and store the docker images on Elastic Container Registry (ECR). Easier said than done, but understanding docker technology improved our productivity as a tech team in general. We started running our applications locally using docker before having in mind to host our applications as docker containers on the cloud.
The code below is a sample docker-compose script that runs 2 micro-services and enables communication between them by sharing the same network bridge.
iii. Deploy to EC2 instances using docker and docker-compose
The last step into transitioning to running our applications on docker containers was to run our apps on each of our EC2 instances using docker-compose. In this case, we were able to run our applications on non-production lower environments for few months as docker containers.
2 — Cloud Formation and Elastic Container Service (ECS)
Once we established that using docker for our micro-services was a viable choice, we started investing in learning Cloud Formation to automate provisioning our ECS environment. We leveraged the use of our already established security infrastructure (i.e. VPCs).
The figure below shows the topology of hosting 2 applications and their corresponding micro-services hosted on 2 ECS clusters on the same VPC (i.e. environment).
B- Front-End Apps Migration
Cloud Front and Web Application Firewall (WAF)
Migrating our front-end applications (written in React) was probably the easiest step. The advatanges of such migration were:
- Cloud Front provides easy to setup Web Application Firewall (WAF).
- Content Delivery Network (CDN).
- No downtime during deployment.
The process of migrating to Cloud Front involved storing the code on S3 and creating a one time Cloud Front distribution per application that points to the S3 bucket hosting the code. Subsequent application code changes only required updating the Cloud Front distribution to point to the new S3 bucket storing the updated source code.
Final Notes
The landscape of cloud computing has changed significantly over the past 10 years and because of that I argue that developers are better equipped to understand the new services offered by Cloud Solution Providers than non-developers. Hence, the tasks to manage Cloud Services should be divided between Security Operations (to setup the security layer — VPC, etc..) and your development team. Delegating deploying the applications to a member outside your core development team is counter productive.
