The 12 Factor App manifesto is a methodology for building software-as-a-service (SaaS) apps that are scalable, maintainable, and deployable on modern cloud platforms. Developed by engineers at Heroku, it's a set of best practices designed to enable applications to be built with portability and resiliency when deployed to the web.
Introduction to the 12 Factor App
In the early days of web development, applications were often built in a monolithic style, tightly coupled to their execution environment. This approach led to numerous issues, especially when apps needed to scale or move to different environments. The 12 Factor App methodology was created to address these challenges, emphasizing a declarative format for setup automation, clean contract with the operating system, and minimizing divergence between development and production.
The Twelve Factors
-
Codebase: One codebase tracked in version control, many deploys. This principle advocates for a single codebase for each service which can be deployed in any environment.
-
Dependencies: Explicitly declare and isolate dependencies. Applications should explicitly declare all dependencies, not relying on the implicit existence of system-wide packages.
-
Config: Store configuration in the environment. This factor pushes for the separation of config from code, as configurations vary substantially across deploys while code does not.
-
Backing Services: Treat backing services as attached resources. This means that a deploy of the app should be able to swap out a local MySQL database for a third-party service without changing the app’s code.
-
Build, Release, Run: Strictly separate build and run stages. This factor emphasizes the need for strictly separating the build stage (where the code is converted into an executable bundle), the release stage (where the executable is combined with the config), and the run stage (where the app is actually run).
-
Processes: Execute the app as one or more stateless processes. This principle states that the app should be executed in the stateless fashion, and any data that needs to persist should be stored in a stateful backing service, like a database.
-
Port Binding: Export services via port binding. Apps should be completely self-contained and should not rely on runtime injection of a webserver into the execution environment to create a web-facing service.
-
Concurrency: Scale out via the process model. This factor implies that apps should be able to scale horizontally by adding more concurrent processes.
-
Disposability: Maximize robustness with fast startup and graceful shutdown. This principle advocates for short startup times and graceful shutdowns to maximize robustness.
-
Dev/Prod Parity: Keep development, staging, and production as similar as possible. This factor aims to reduce the gaps between development and production to ensure continuous deployment for maximum agility.
-
Logs: Treat logs as event streams. Applications should not concern themselves with routing or storage of their output stream. Instead, each running process writes its event stream, unbuffered, to stdout.
-
Admin Processes: Run admin/management tasks as one-off processes. This principle states that management tasks should be run in an environment identical to the regular long-running processes of the app.
Conclusion
The 12 Factor App methodology provides a framework for building software that demonstrates key characteristics necessary for modern cloud platforms. It addresses issues of scalability, reliability, and portability, making it easier for development teams to build and manage applications effectively. As the world of web development evolves, the principles of the 12 Factor App continue to be a vital reference for building robust, scalable cloud-native applications.