12-factor app is a methodology or set of principles for building the scalable and performant, independent, and most resilient enterprise applications. It establishes the general principles and guidelines for creating robust enterprise applications. 12-factor app principles got very popular as it aligns with Microservice principles.

The 12-Factor Principles

  • Codebase (One codebase tracked in revision control, many deploys)
  • Dependencies (Explicitly declare and isolate the dependencies)
  • Config (Store configurations in an environment)
  • Backing Services (treat backing resources as attached resources)
  • Build, release, and Run (Strictly separate build and run stages)
  • Processes (execute the app as one or more stateless processes)
  • Port Binding (Export services via port binding)
  • Concurrency (Scale out via the process model)
  • Disposability (maximize the robustness with fast startup and graceful shutdown)
  • Dev/prod parity (Keep development, staging, and production as similar as possible)
  • Logs (Treat logs as event streams)
  • Admin processes (Run admin/management tasks as one-off processes)

Codebase (One Codebase Tracked In Revision Control, Many Deploys)

12-factor app advocates that every application should have its own codebase (repos). Multiple codebases for multiple versions must be avoided. Please do note that having branches would be fine. I.e. For all the deployment environments there should be only one repo but not multiple.

Multiple apps sharing the same code are a violation of the twelve-factor. Here you should opt-in for shared libraries.

From the 12-factor app perspective app, deploy meaning the running instance of an app like production, staging, QA, etc. Additionally, every developer has a copy of the app running in their local development environment, each of which also qualifies as a deploy.

Different versions (the version is like a code change that is available in one environment but not in other) may be active in multiple deploys.

  • **Microservices: **In Microservices, every service should have its own codebase. Having an independent codebase helps you to easy CI/CD process for your applications.

Twelve-factor app advocates of not sharing the code between the application. If you need to share you need to build a library and make it as a dependency and manage through package repository like maven.

Dependencies (Explicitly Declare and Isolate the Dependencies)

It talks about managing the dependencies externally using dependency management tools instead of adding them to your codebase.

From the perspective of the java, you can think of Gradle as a dependency manager. You will mention all the dependencies in build.gradle file and your application will download all the mentioned dependencies from maven repository or various other repositories.

You also need to consider the dependencies from the operating system/ execution environment perspective as well.

Microservices: All the application packages will be managed through package managers like sbt, maven.

  • In non-containerized environments, you can go for configuration management tools like chef, ansible, etc. to install system-level dependencies.
  • For a containerized environment, you can go for dockerfile.

#microservice #12-factor app

12 Factor App Principles and Cloud-Native Microservices
1.50 GEEK