briancaffey VS cdk-django

Thanks for the feedback. Please have a look at the raw markdown file here on GitHub: https://github.com/briancaffey/briancaffey.github.io/blob/master/content/2023/01/07/i-deployed-the-same-containerized-serverless-django-app-with-aws-cdk-terraform-and-pulumi.md

Article on GitHub (markdown): https://github.com/briancaffey/briancaffey.github.io/blob/master/content/2022/03/27/ad-hoc-developer-environments-for-django-with-aws-ecs-terraform-and-github-actions.md

Here's a link to the Markdown source file for this article on GitHub: https://github.com/briancaffey/briancaffey.github.io/blob/ma...

cdk-django

CDK Construct Library: github.com/briancaffey/cdk-django

- Another aspect of my approach that I prefer over the other one is using a high-level construct that you publish and then consume in your project. This requires that you write a construct in TypeScript and then publish it to npm or PyPI. I'm working on a construct library for deploying Django apps with CDK called djagno-cdk, and one of the constructs in it uses ECS Fargate: https://github.com/briancaffey/django-cdk/blob/main/src/django-ecs.ts. Ideally you don't have everything in a single construct though, so I like how Mariano is doing that in his project. My Terraform project does a better job at separating layers of the application, so I need to apply that same principle to django-cdk when I get around to working on that project again.

Sure. My IaC journey actually started out with CloudFormation, and I learned a lot from this reference project: aws-samples/ecs-refarch-cloudformation. Then I picked up CDK when that became available and migrated a project from CloudFormation to CDK. It sounded like a nicer way to handle stacks in a familiar language with lots great one-liners and utility functions and constructs, and it definitely is. I have a similar project written in CDK that is an application/framework-first (Django) approach to learning and doing IaC that you can find here: https://github.com/briancaffey/django-cdk. This implements both ECS and EKS, but my attempts at learning EKS sort of fizzled out for now as I don't have the need to use it, and for the task at hand (running a monolithic Django application on AWS) I think ECS makes a LOT more sense.

I have an example of doing this here, and I posted about this earlier on this sub https://www.reddit.com/r/django/comments/rj7sj2/deploying_django_applications_to_a_singlenode/

I'm not sure what you mean by "architecture", and I'm not sure what is wrong with trying to save money while learning how to do IaC and CI/CD. My thinking is that I can use some of what I learned here in a more robust setup of a Django app that uses ECS, I'm working on that here: https://github.com/briancaffey/django-cdk/blob/main/src/django-ecs.ts.

Here is on that I’m working on: https://github.com/briancaffey/django-cdk

Here's a link to the repo: https://github.com/briancaffey/django-cdk. This library currently offers high level constructs for EKS as well as ECS. I have previously used ECS for most of the containerized web apps I have worked with, so I'm hoping to use this as a way to compare the two orchestration tools for my use case and gather some best practices. This project includes a companion repo that is included as a git submodule that I have been to do live tests/deployments using my construct library.