The Twelve-Factor App Methodology

The twelve-factor app is a methodology used to develop SaaS apps or web apps with the help of Microservices. It serves as a practice guide to building apps when pressed for time or cost to hire new developers for a project and make them scale up without significant changes to tools or architecture. It allows organizing projects effectively and managing scalable applications.

This methodology was first introduced by the developers at Heroku in 2012 who created hundreds of applications and developed this methodology based on their experience. The methodology incorporates 12 principles each applying to a subset of an app and guiding developers in finding the best way to manage apps as a whole.

The principles it suggests are not constrained to any particular programming language or database.

Principle 1. Codebase

There should be one codebase with different environments.

The guideline expressed in this first factor suggests the principle of not creating another  codebase, just for the sake of setup in different environments. For instance, there shouldn’t be two repositories (production and development) for one codebase. A distributed version control system can maintain and monitor the project source code. For developers, this makes accessibility easier.

Different environments represent different states. They all share the same codebase, whatever the state might be.

Principle 2. Dependencies

All dependencies should be declared, with no implicit reliance on system tools or libraries.

Including the dependencies into the codebase is a bad practice since it could create problems such as the underlying dependency of the platform. For instance, if the uploaded modules were from a Windows PC perspective, and the codebase was downloaded by a Mac OS developer, they would undoubtedly have problems running the project.

It’s better to use a package manager-depending on the technology stack – to download the dependencies on your respective system by reading a dependency declaration manifest containing the names and versions of the dependencies.

Principle 3. Config

Configurations are an important part of any application, especially when there is a need to support multiple environments or clients.

A configuration that varies between deployments should be stored in the environment. No one wants confidential information to be publicly available, such as database connection information or other sensitive data. The configuration is also largely dependent on the environment where it’s located.

There should be a strict separation between config and code. Code should remain the same irrespective of where the application is being deployed, but configurations can vary.

Principle 4. Backing Services

All backing services are treated as attached resources and attached and detached by the execution environment. Databases, external storage, message queues, etc. are external services and they can be considered as a resource. They may be accessed via some web-addresses/URLs or similar requests, then specified in the configuration. That way, the source of the service can be modified without affecting the core code of the app.

Principle 5. Build, Release, Run

A twelve-factor application requires a strict separation between Build, Release, and Run stages.

• First, the build phase. It is the assembly/compilation of the source code into an executable bundle while loading dependencies and creating assets. The build phase starts every time a new code needs to be deployed.
• Second, the stage of release. At this stage, the code produced during the build stage is combined with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment.
• Third, the run stage. This is the final stage, which runs the application in the execution environment. It should not be intervened by any other stage.

Software deployment through this lifecycle is quick, continuous, and without any manual intervention.

Principle 6. Processes

Applications should be deployed as one or more stateless processes with persisted data stored on a backing service, typically a database.

The key principle of this factor is that the process is stateless and shares absolutely nothing. While many web systems rely on “sticky sessions”, storing data in the session expecting that the next request will come from the same service contradicts this approach.

Principle 7. Port Binding

A twelve-factor app should be independent of additional applications. Every function should be its own process.

This factor refers to an application binding itself to a particular port and responding to all the requests from that port. The port is declared as an environment variable and provided during execution.

Applications built on the basis of principle do not depend on a web server. The application is self-contained and runs standalone. The web server is packaged as a library and bundled with the application.

Principle 8. Concurrency

Based on the requirements, each process in your application should be able to scale, restart, or clone itself. Doing this can enhance scalability.

Instead of making a single process even larger, developers can create multiple processes and then distribute the load of their applications among those processes. Using this approach, developers can build apps that can handle various workloads by assigning each workload to a process type. For instance, it is possible to delegate HTTP requests to a web process, and long background tasks to the worker process.

Principle 9. Disposability

A 12-factor app should be built on simple processes that start quickly, work quickly, and finish correctly. This helps developers to scale up processes while still allowing them to restart them if anything goes wrong.

Building disposability into your app means graceful shutdowns: it should clean up all utilized resources and shut down seamlessly. An app can be easily relaunched when designed in this way. Likewise, when processes terminate they should finish their current request, reject any incoming requests, and exit.

Principle 10. Dev-Prod Parity

The twelve-factor article proposes keeping the difference between development and production environment minimal. This reduces the likelihood of bugs turning up in a particular environment.

Developers should strive to use the same third-party services between development and production. To keep differences between development and production minimal, teams collaborating on a project should use the same operating systems, backing services, and dependencies. As a result, continuous deployment takes less time. This also encourages the idea of rapid app development (RAD).

The process of continuous deployment becomes hassle-free when developers reduce the number of differences between the development and production stages.

Principle 11. Logs

When troubleshooting production problems or understanding user behavior, logs become extremely important. Logs provide visibility into a running application’s behavior.

A 12-factor app should not concern itself with routing or storage of its output stream. Neither should it not attempt to write to or manage logfiles. All logfiles should be written to stdout, and the environment decides how to process this stream. This can be shipping to the console or saving and routing to a log indexing and analysis system.

Principle 12. Admin processes

This factor states that any admin processes should be run in an identical environment as the regular long-running processes of the app. In a local deploy, developers use a direct shell command inside the application checkout directory to perform one-time admin processes. To run such a process in a production deploy, developers can use ssh or another remote command execution mechanism provided by the deploy’s execution environment.

Twelve-Factor App Methodology Advantages

The Twelve-Factor App methodology can speed up efficiency. Besides, the time spent on learning and applying these guidelines can help companies save a great deal of money.

There are cases when it makes sense to diverge from some of the guidelines, such as Logs, but it is better to follow all Twelve-Factors guidelines as carefully as possible.

Looking for SaaS development services? If you have doubts or concerns regarding the Twelve-Factor App methodology it’s best to get expert advice. At SCAND, you can get a free consultation with our specialists. Describe your project, requirements, time, and budget constraints and our consultants will suggest the most advantageous option for you.