In this article, I will explain to you the Twelve-Factor App development guidelines, why it's not a passing fad, and how you can use it to literally (well, figuratively) embrace the future.
The Twelve-Factor app is a set of best practices for building modern web applications. There are twelve guidelines (hence the name) that are recommended to be followed by every developer to build scalable applications.
A Twelve-Factor App is described as:
- Automated from a development perspective;
- Portable across execution environments;
- Deployable in the cloud minimizing the need for servers and server administration;
- Enabled for continuous deployment with minimal divergence between development and production environments; and
- Scalable without significant change or effort.
I'll briefly cover each of the factors. However, for an in-depth explanation be sure to check out the official site of The Twelve-Factor App: https://12factor.net/
Essentially, there will always be only one code repository for a given app. This can be any version control system such as Git, Mercurial or Subversion. There will be many deployments of an app, however, the app can be run in different environments (local/production).
The config should always be stored in an Environment Variable. You want the config file to be separated away from the code as the config varies throughout deployment and the code does not.
Treat your backing services as attached resources. This means that you want to make your services easily interchangeable so that you can swap to a different third-party service provider without any changes to the app’s code.
The twelve-factor app uses strict separation between the build, release, and run stages. The build process is run when new code is deployed. Every release should always have a unique release ID, such as a timestamp of the release or an incrementing number. Then you are able to run the release in an execution environment.
DO NOT introduce state in the processes. Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.
The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port. Make sure that you export your services via port binding. The service should be visible to other services as they may be used.
By separating your app into smaller pieces you are able to scale the services. This reduces the workload as an individual VM can only grow so large (vertical scale), so it is important for the app to span across multiple processes on multiple physical machines.
Processes are disposable, so make sure that they can be started or stopped fast. By doing so this facilitates automatic scaling, rapid and ease of deployment.
Keep development, staging, and production as similar as possible so that anyone working on a project is able to pick it up and release it. Continuous deployment between development and production is imperative to limit failures and errors.
Treat logs as event streams. Logs are useful for checking up on your apps processes and backing services. You should never concern the routing or storage of its output stream with your app. Instead, think of these logs as having no fixed beginning or end but flows on a continuous stream as long as the app is running.
Run admin/management tasks as one-off processes for tasks like database migrations and executing one-time scripts in the environment.
Regardless of your framework and tech stack, you can implement Twelve-Factor App principles into your application! Some great resources that naturally complement the Twelve-Factor App's principles include:
- Dotenv for configuring environments (the link is for Node.js but different versions are available for different languages and frameworks)
- Docker for setting up containers and creating perfect development/deployment environments effortlessly;
- Kubernetes for managing and scaling containers for production-grade uses;
- AWS for hosting a deployed Twelve-Factor App; and
- So many more!
This above list is by no means exhaustive. I'll end this article encouraging you to do your own research and find more tools that you can incorporate into your stack. Like it or not, these Twelve-Factor App principles are becoming more and more common, so the best time to get started is now!