Introduction
Having an application running behind a Load Balancer with Auto Scaling policies is already a good choice.
With the migration from Bare metal to AWS EC2 and the upgrade of our main database from PostgreSQL 9.2 to PostgreSQL 14, we were ready to the next challenge.
Current architecture
Why Migrate to ECS?
ECS brings many benefits. Better integration with other AWS services, simplified container management and improved scalability and resource optimization are some of them.
In our case, we were using Bamboo as our CI solution to deploy application changes to our AWS environments. Each build would take around 50 minutes to complete. Imagine you're a developer and we wanted to test a change in the Test environment. You'd have to wait for ~50 minutes to see if your change succeeded or not. No, there was no local development solution in place either.
Choose your weapons!
Infrastructure as Code
There are many IaC (Infrastructure as Code) solutions out there. We decided to go with Terraform, as it's easier to manage and to find engineers who have work experience with it.
💡 Tip: Using Terraform community modules such as terraform-aws-modules and cloudposse may help you speed up the creation of those resources.
Github Actions will connect to our AWS Accounts using an OIDC connection.
Terraform state file
Managing the state of your IaC can be tricky if you have other team members creating, updating and deleting resources at the same time as you are.
Terraform has a feature that allows you to manage the state of your infrastructure using an AWS S3 bucket and DynamoDB tables. This is a huge improvement for us given the fact we had resources in CloudFormation.
CI/CD
Terraform alone is of no help. You must have a good CI solution to deploy your infrastructure changes.
We've opted to go with Github Actions, as the business was already using Github for other repositories.
Conclusion
Our cluster has been handling the traffic really well.
Top comments (0)