The 1st The Twelve-Factor App on AWS & Django（What is The Twelve-Factor App?）

Introduction

Today’s systems are becoming a source of competitiveness for businesses. Therefore, we must not build once and then complete but must continuously improve them. New features must be implemented and released daily to meet the changing business environment and user needs. Otherwise, the business will rapidly lose competitiveness.

In today’s system development environment, it is essential to provide value to users quickly by using the latest technology and making it easy to improve the system continuously.

We believe that The Twelve-Factor App is an essential guideline for making systems easy to improve continuously.

This time, I want to write articles about creating apps and infrastructure using The Twelve-Factor App. You will develop the infrastructure and apps as follows below.

The Twelve-Factor App

The Twelve-Factor App is an app development methodology that Heroku engineers proposed in 2011 based on their experience of indirectly witnessing the development, operation, and scale of hundreds of thousands of applications.

The Twelve-Factor App aims as follows below.

• Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
• Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
• Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
• Minimize divergence between development and production, enabling continuous deployment for maximum agility;
• And can scale up without significant changes to tooling, architecture, or development practices.

The following describes what you will be doing this time after reviewing the 12 Factors of The Twelve-Factor App.

• I. Codebase
  • One codebase tracked in revision control, many deploys
    • Build and deploy the same container images to development and production environments.
• II. Dependencies
  • Explicitly declare and isolate dependencies
    • Since we will develop in Python and Nuxt, we use pipenv and npm to manage the app’s dependencies and install based on the dependencies in the Dockerfile.
• III. Config
  • Store config in the environment
    • You can inject configuration from the outside using ECS container definitions to separate the app from the configuration.
• IV. Backing services
  • Treat backing services as attached resources
    • Use RDS as the database. For example, you can access the database by RDS endpoints stored in the configuration, and the database can be freely attached and detached by switching endpoints.
• V. Build, release, run
  • Strictly separate build and run stages
    • Create a container image using CodeBuild and push it to AWS ECR.
    • Deploy the container image to ECS Fargate using CodeDeploy.
• VI. Processes
  • Execute the app as one or more stateless processes
    • Run a single stateless Python application process in a container and expose API endpoints.
    • Store All data in RDS, not locally.
• VII. Port binding
  • Export services via port binding
    • Bind Nginx to port 80 of the host, and Nginx will handle the static files and proxy the Django app container.
• VIII. Concurrency
  • Scale out via the process model
    • Specify the number of tasks in service and configure it to automatically restart failed tasks in ECS.
    • Specify the maximum number of tasks in service and configure it to monitor CPU metrics and autoscale.
• IX. Disposability
  • Maximize robustness with fast startup and graceful shutdown
    • Amazon ECS sends a signal called SIGTERM to the application process during scale-in and regular application exit operations.
    • The default 30 seconds (Fargate and application) is acceptable as a wait time for the signal, so do not change the setting.
• X. Dev/prod parity
  • Keep development, staging, and production as similar as possible
    • Build a CI/CD pipeline with CodePipeline to deploy the same container images to development and production environments.
    • Build the same infrastructure for each environment with Terraform.
• XI. Logs
  • Treat logs as event streams
    • Configure sending logs to Amazon CloudWatch Logs instead of logging to a local file.
• XII. Admin processes
  • Run admin/management tasks as one-off processes
    • Include DB migration in the deployment process.
    • Allow launching tasks for administration and maintenance.

Technology Stacks

Based on the above, we will use each of these areas as follows

• Infrastructure
  • AWS
• IaC
  • Terraform
• Frontend
  • Nuxt
• Backend
  • Python
  • Django

We want to develop the backend application in the following article (Part 2).