What is Twelve-Factor App Methodology In Web App Development?

What is the Twelve-Factor App Methodology? The Twelve-Factor App methodology, created by Adam Wiggins (co-founder of Heroku), is a set of best practices for building, distributing, and deploying the application in the cloud platform. It is called the twelve-factor app methodology because it has 12 diverse guidelines that help developers to build a simple yet scalable web app or SaaS application. These principles are the outcome of every experience and observation gained through the deployment of several Software-as-a-Service applications over the cloud. But why should you follow it, you may ask. Not following these guidelines may lead you to suffer from the same mistakes that other senior developers had while wasting your time in solving systematic issues. However, using this methodology, you might be able to take advantage of the tried experience that saves your time in the long-term.

So in this article, you get an overview of the twelve-factor app methodology and how it can be beneficial for your business or development process.

What is the Twelve-Factor App?

The twelve-factor app is a methodology used for developing software as a service (SaaS) that uses declarative formats for setup automation that minimize time & cost for new developers in the project, have a clean contract to offer maximum portability, suitable for deployment on modern cloud platforms, minimizes divergence between production and deployment, enables continuous deployment for better agility and scales up without the need to change architecture, tools, or development practices.

Not only that but, the twelve-factor app methodology is not constrained to any particular programming languages or database. It is flexible enough to be implemented on any application, regardless of the programming language, it is built upon and the backing services it is using. Designing an application using these factors in mind, helps in deploying more portable and resilient apps on the cloud.

So, what are these twelve factors? Let’s move ahead and find out.

The Twelve Factors In Web App or SaaS Development

Each factor in the twelve-factor app methodology has a unique and crucial role in its proposed architecture and practices.

1. Codebase

“One Codebase tracked in revision control, many deploys”

An application version must always be tracked in a version control system like GitHub, GitLab, Bitbucket, or Mercurial. It provides substantial benefits like code versioning and code tracking while easing the collaboration of a development team that is working on the same project. Every deployment of the project must have its code repo (the copy of the revision tracking database) that can be deployed in multiple environments. A codebase is a single repo or the set of repo's that share root commit.

Read: SOA vs. Microservices: What's the Difference?

The relation between the codebase and app is always one-to-one, i.e, if there are multiple codebases it will not be an app but a distributed system where each part of the system will be an app and these apps can easily comply with this methodology. If you share the code between applications it will be a violation of the twelve factors. There must be only one codebase per app but there can be multiple deploys on the app.

2. Dependencies

“Explicitly declare and isolate dependencies”

Most programming languages offer a package system for distributing support libraries. Libraries installed through a packaging system can be installed system-wide (site-packages) or scoped into the app directory (called bundling). However, a twelve-factor app never depends on the implied existence of site-packages. It declares all the dependencies through the dependency declaration. Apart from that, it ensures no implicit dependencies “perforation” from the surrounding system by executing via dependency isolation tool. Simply put, the application based on 12 factors must be self-contained to avoid any interaction with conflicting libraries present in the host machine.

Read: Best Secrets Management Tools For Application Security

3. Config

“Store Config in the environment”

Both the application and its configuration must be entirely independent. That means storing the config in the code should be avoided. The twelve factor app stores config in environment variables that are easy to change at the time of deploys. These env variables help in updating config values without disturbing the actual codebase while removing the need to re-deploy your application when changing certain config values. Not only that but storing config as variables also eliminate the chances of configs to be checked into the repository accidentally.

4. Backing Services

“Treat backing services as attached resources”

A backing service is nothing but the services on which your application depends for its functionality and access through the network. Some of those services include datastores, SMTP services, caching systems, and queuing/messaging systems. The code for a twelve factor app treats both local and third-party services as attached resources being accessed via locator credentials stored in config or URLs. It means that the app should be able to swap between local and third party services just by changing the resource handle without actually changing the code.

Read: Top 10 Programming Languages for Desktop Apps In 2021

5. Build, Release, Run

“Strictly separate build and run stages”

A codebase is transformed into a successful deployment via three stages: build stage (converts a code repo into an executable bundle or build), release stage (combines build with deploy’s present config for creating release), and the run stage (that runs the app in the execution environment). Previously it was impossible to change the code at runtime as there was no way to propagate changes to the build stage that’s why the twelve factor app methodology was introduced.

The Twelve Factor App strictly separates these build and run stages. The developer here begins with storing the app in source control and build out its dependencies. By separating the config information it also becomes efficient to combine it with the build for the release stage and make it ready for the run stage. An important thing to note here is that each release must have a unique ID (release timestamp and incrementing version number) as with every change a new release is created.

6. Processes

“Execute the app as one or more stateless processes”

The twelve factor app is executed in the run environment as one or more processes. It stores the data that is needed to exist in the stateful backing service like a database. The idea here is to make the process stateless that shares nothing. The memory space of the process can be used as a brief single transaction cache. To fulfil this principle, session state data is an ideal solution for a datastore that provides time-expiration.

7. Port Binding

(A port is a virtual network connection endpoint. They allow the system to easily communicate with other services over the internet. There are some network ports existing in your network firewall that have opening and closing ports on the network firewalls that controls device access over the network. As the application cannot connect to the outside network without further configuration, we bind ports to configure where and how a message will be sent and received)

“Export services via port binding”

Sometimes the web apps are executed inside a cloud container. However, being self-contained, the twelve-factor app does not depend on the runtime web server injections into the execution environment to create a web-interface. It is independent of the additional application. The web app based on the twelve-factor app methodology exports HTTP as a service through port binding and listens to the requests coming from that port.

8. Concurrency

“Scale-out via the process model”

The twelve factor app should be written, packaged, and deployed in such a way that different components of the application deploy and run as separate and independent processes. The app should also allow upscaling and downscaling of components independently.

9. Disposability

“Maximize robustness with fast startup and graceful shutdown”

An app based on the twelve factor app methodology should have processes that are disposable, i.e, start and stop at moment’s notice to facilitate higher scaling, rapid deployment, and robust deploys. But the concept behind this principle is that the disposability of the app should not disturb or affect the user and can be replaced by other components or start upright again. Indulging disposability into the app enables the application to clean up all utilized resources and shut down gracefully. It also ensures that the app comes back up swiftly.

10. Dev/Prod Parity

“Keep development, staging, and production as similar as possible”

According to the twelve factor app methodology, applications that are deployed to development and production must have parity (the state of being equivalent). The difference between both deployments should be as minimum as possible. If in case, there is a huge difference between dev and production, it can result in unintentional compatibility issues. Also, while building a twelve factor app backing services present between both prod and dev must be the same to avoid any significant downline.

11. Logs

“Treat logs as event streams”

Logs offer visibility in the app behaviour. In server-based environments, they reside under a log file that’s only an output format. However, a twelve factor app should not worry about its output stream's routing or storage, neither attempt to write or manage logfiles. Rather, every running process should write its event stream, unbuffered to stdout. In the production or staging deployments, every process stream will be monitored by the execution environment, collated with other streams and routed to the final destination for long-term archival. You can use some open-source log routers for this purpose as well.

12. Admin Processes

“Run admin/management tasks as one-off processes”

There are a number of one-off processes (admin processes that are long-running and should run in an identical environment as the regular long-run processes of the app) that are part of the application deployment such as executing one-off scripts and data migration.

The twelve-factor app suggests keeping such administrative processes as the component of the application codebase in the code repository. Although the Admin processes are distinct, you must continuously ship and run the app code in the same environment and against the config and base code of the app to avoid synchronization problems. The same dependency isolation method should be used on each process type to make it easy for off-script to run.

Any developer who is building or about to build an application that runs as a service must go through the twelve-factor app methodology. Although there are no such one-fits-all solutions when it comes to web application development, still the twelve-factor app provides the best possible practices and guidelines for the developers or ops engineers to deploy, develop, and manage their applications on cloud platforms. It is an exceptional blueprint that offers all the crucial steps of deploying a reliable Saas product. Those who want to build a SaaS product for their business should hire developers who are not only experienced in programming languages but can also deploy your apps on the cloud using the twelve-factor app methodology.