Twelve-Factor App
Cloud Ready/Native applications
Section titled “Cloud Ready/Native applications”There is a big gap between old monolith applications running on dedicated VM’s storing everything on the local disk and serverless cloud applications. I hope for your sake it’s more like the latter rather than the former. The purpose is to research how cloud ready your system is and if those findings are blocking for migrating to kubernetes or not. To assess the cloud readiness of your application you can use the twelve-factor app methodology.
The Twelve Factors
Section titled “The Twelve Factors”The Twelve-Factor App methodology is a set of best practices for building modern, scalable, and maintainable software-as-a-service applications. The twelve factors are a set of guidelines that help developers build applications that are easy to deploy and scale in modern cloud environments.
In order to be able to deploy an application to the FLOW Platform, the application must adhere to the Twelve-Factor App methodology.
In this document we go over each of the factors and explain how they apply to the FLOW Platform and applications deployed on it.
I. Codebase
Section titled “I. Codebase”A single application is tracked in a codebase. A single codebase can be deployed many times, to different environments. We acknowledge that:
- Each application has its own codebase.
- For distributed systems, each system has its own codebase.
II. Dependencies
Section titled “II. Dependencies”- Dependencies are explicitly declared and isolated.
III. Config
Section titled “III. Config”Configuration and secrets are not stored in the codebase. It is something that is applied to the application at runtime for a particular environment (develop, test, acceptance, production).
- Configuration is stored in the environment.
- Configuration can be applied at runtime.
IV. Backing services
Section titled “IV. Backing services”Treat backing services as attached resources. Examples of backing services are databases, message queues, etc. Specify the connection details as a URL to backing services in the environment.
V. Build, release, run
Section titled “V. Build, release, run”Separate build, release and run stages. Build stage is a transform from codebase to executable bundle. Release stage combines the build with the config. Run stage runs the application in the execution environment.
VI. Processes
Section titled “VI. Processes”Applications are stateless and share nothing. Any data that needs to persist is stored in a backing service.
VII. Port binding
Section titled “VII. Port binding”Applications are self-contained and do not rely on runtime injection of a webserver. Applications export services via port binding.
VIII. Concurrency
Section titled “VIII. Concurrency”Scale out via the process model. Applications are designed to scale out horizontally.
IX. Disposability
Section titled “IX. Disposability”Applications are disposable. They can be started or stopped at a moment’s notice.
X. Dev/prod parity
Section titled “X. Dev/prod parity”Keep development, staging and production as similar as possible. Ideally, the only difference is the config.
XI. Logs
Section titled “XI. Logs”Applications should not concern themselves with routing or storage of their output stream. They should simply write to the standard output and error stream.
XII. Admin processes
Section titled “XII. Admin processes”Run admin/management tasks as one-off processes. Admin code must be shipped with the application code. Think of, for example, database migrations.