12 Factor App

Audience: Developers and Operations

What? It is a methodology for developing and implementing the Software-as-a-service (SAAS) application.

Why? For the following reason

  1. Raise awareness of systemic problems of application development.
  2. Provide a shared vocabulary to discuss those problems.
  3. Offer a set of board conceptual solutions with accompanying terminology.

How? Consider and implement following 12 factors in the project/product development

  1. Codebase: One codebase tracked in revision control, many deploys.
    • An application will always has to be tracked in revision control systems such as Git or Subversion.
    • One codebase maps to many deploys.
    • Many deploys - Aapp running on production, staging and developers local machine.
    • One-to-One corelation between the codebase and the app.
    • Multiple apps sharing the same code is voilation of 12 factor. Solution, factor shared code into library which can be included through the dependency management.
    • If there are multiple codebases, it is not an app, it is a distributed system. Each component in the system is an app and each can individually follow 12 factor.
  2. Dependencies: Explicitly declare and isolate dependencies.
    • Application should not rely on implicit existance of system-wide packages (Java JDK, Maven, Spring Packages)
    • Application has to declare all the dependencies completely and exactly in the dependency declaration file.
    • Two types of dependencies:
      • System dependencies such as Java JDK, Maven, Gradle
      • Application dependencies such as Spring Framework, HTTP Client etc.
    • Benefit: The new developer can checkout the application code and run it on developer machine. Language runtime and Dependecies manager as prerequisites.
    • App should not rely on the implict existance of the system tools such as ImageMagik. As these tools make not available on all the machines. If it is required include it in the application.
  3. Config: Store config in the environment.
    • Config can be anything that is different between environments. Such as database configuration, AWS configurations.
    • Config are stored in environment variables.
    • Environment variables are easy to change between the deploys without changing the code.
    • Grouping Not allowed Config are grouped into namespace (called environment) such as Production, staging, development. It is difficult to scale as application grows more enviroments has to be created such as dev-1.
  4. Backing Services: Treat backing services as attached resources.
  5. Build, Release, Run: Stricly seperate build and run stages
  6. Processes: Execute the app as one or more stateless processes
  7. Port Binding: Export services via port binding
  8. Concurrency: Scale out as a process model
  9. Disposibility: Maximize robustness with fast startup and graceful shutdown
  10. Dev/Prod Parity: Keep development, staging, and production as similar as possible
  11. Logs: Treat logs as event stream
  12. Admin Processes: Run admin/management tasks as one-off processes.

Definitions:
1. Codebase: A Codebase is a single repo (Centralized revision control system such as SubVersion) or any set of repos who share a root commit (Distributed revision control system such as Git).
2. Code Repository: A revision tracking database is called as code repository or coderepo in short or just repo.
3. Deploy: A running instance of an app.
4. Application: A list of files that contains instructions to the machine to perform operations.
5. Dependecy Isolation: Tool used to ensure no implicit dependencies leaks in from the surronding systems. Example, Java version has to explicitly declared in the dependency declaration file (Maven - pom.xml)

References

Published on 07 September 2022