This message was deleted.

- I’m building libraries for each IaC tool (Terraform/CDK/Pulumi) and calling these libraries to deploy my sample application - I am deploying a Django + Vue sample microblogging application that I’m using for demonstration (ublog) - The sample app adheres to the 12Factor methodology - It uses a static frontend site, an API service, a worker service (celery) and a task scheduling service (celery beat) - It makes use of RDS Postgres, ElastiCache Redis and S3 for file storage (blog posts can have images) - I am using GitHub Actions to build pipelines for IaC deployments - The application update process is separate from the infrastructure updated process, and it also uses GitHub Actions - The application update process involves deploying new container images to an ECS cluster and using the AWS CLI to invoke

run-task

for database migrations and other tasks to be executed before starting a rolling update - The Infrastructure as Code (Terraform/Pulumi/CDK) code is broken out into separate logical units - A base unit (defines networking, persistent data services, IAM, etc.) - An app stack (defines ECS resources) - I will likely break these logical units into smaller, more focused units in the future once I get a strong handle on all three IaC and how to deploy them in a consistent way - Each IaC library supports two types of environments: production environments and ad hoc environments - Production environments make use of application autoscaling and dedicated RDS and ElastiCache resources and are suitable for use in production environments and a small number of production-like pre-production environments (such as stage, rc, qa for example) - Ad hoc environments use a shared VPC, load balancer and RDS instance and are meant to be made available to developers on-demand through a self-service internal developer platform (IDP)