12 Factor Methodology for your cloud native apps!

What is a 12 Factor App?

The 12 Factor App is a methodology that provides a set of best practices for building cloud-native applications that can be easily deployed and managed. It allows developers to build distributed applications that run in the cloud and are delivered as a service with high efficiency.

Β 

This approach was originally introduced in 2011 by Heroku co-founder Adam Wiggins. Since then, it has become a popular framework for building cloud-native applications. It can be applied to apps written in any programming language, and which use any combination of multiple backing services (database, queue, memory cache, etc).

Β 

It aims to mitigate the risks that come with operating at web-scale such as having an application crash suddenly following a network overload or not being able to provide good user experience when supporting a large number of users which can lead to the loss of clients to a competitor.

Why should I apply it?

As more businesses move their applications to the cloud, there is a growing need for developing applications that are easy to manage, deploy and scale.Β 

Traditional application development approaches are not well suited for the cloud, as they often rely on monolithic architectures, tightly coupled dependencies, and manual configuration management.Β 

The 12 Factor App methodology was designed to overcome these challenges and allow you to build apps that use declarative formats for setup automation, have a clean requirements for the underlying operating system, are suitable for deployment on modern cloud platforms, minimize divergence between development and production and can scale up without significant changes to tooling, architecture, or development practices.

As you can deduct from the title, this methodology consists of 12 principles that cover everything from codebase management to scaling applications that has not only stayed relevant but has also gained a lot of popularity in recent years. Let’s take a closer look at it!

What are the 12 principles?

1. Codebase
This factor states that there should be one codebase for each application, even when building cross-platform apps, and it should be tracked using version control. This makes it easy to manage changes to the code and ensure that everyone is working on the latest version.Β 

Illustration of the Principle number one of the 12 Factor Meghodology: Codebase

2. Codebase
This factor states that there should be one codebase for each application, even when building cross-platform apps, and it should be tracked using version control. This makes it easy to manage changes to the code and ensure that everyone is working on the latest version.Β 

3. Configuration
Configuration should be stored in the environment. This means that any configuration settings, such as database connection strings or API keys, should be stored as environment variables and never as constants in code. This makes it easy to manage different environments, such as development, staging, and production.

4. Backing Services
Backing services, such as databases or message queues, should be treated as attached resources. This means that they should be attached to the application as services, rather than being bundled into the application itself.

Illustration of the Principle number four of the 12 Factor Meghodology: Backing Services

5. Build – Release – Run
The build, release, run factor states that there should be a separation between building the application, releasing it to a production environment, and running it. This allows for easier management of the application throughout its lifecycle.

Illustration of the Principle number five of the 12 Factor Meghodology: Build, Release, Run

6. Processes
Applications should be run as stateless processes. This means that any state or session data should be stored outside of the application itself, allowing for easy scaling and management of the application.

Illustration of the Principle number six of the 12 Factor Meghodology: Processes

7. Port Binding
Applications should be self-contained and listen on a port. This means that the application should be responsible for binding to a port and not rely on external services or components to do so.

Illustration of the Principle number seven of the 12 Factor Meghodology: Port Binding

8. Concurrency
Applications should be designed to scale horizontally. This means that the application should be able to handle multiple concurrent requests by adding more instances of the application.

Β 

9. Disposability
Applications should be designed to be disposable. This means that they should be able to start up quickly, shut down cleanly, and not leave any artifacts behind.

Β 

10. Dev – Prod Parity
The development, staging, and production environments should be as similar as possible. This ensures that there are no surprises when the application is deployed to production.

Β 

11. Logs
Applications should log to stdout/stderr. This makes it easy to manage and aggregate logs across different applications and services when those are run in containers.

Illustration of the Principle number eleven of the 12 Factor Meghodology: Logs

12 Factor App and Kubernetes

Although the 12 Factors for designing applications originated before containerization became the norm, applying these Factors to your cloud-native applications will help to build a strong architecture for them to remain agile, scalable, and portable in the long run.

Nowadays when we think of building apps, we immediately think of Kubernetes, containers and cloud-native application frameworks and here too, we can apply this methodology that has proven to be timeless.Β 

Conclusion

The 12 Factor App methodology has become a popular framework for building modern applications, and it has been adopted by many companies, including Google, Microsoft, and Amazon.

Following these twelve principles, will allow you to build cloud-native applications that are easy to manage, scale, and deploy. This set of best practices is worth considering if you are building a cloud-native application that isΒ  intended to run at web-scale.Β 

As we mentioned before, building web-scale applications is no easy task and can get very overwhelming, which is why having such a tool can ease up the process and can ultimately lead to a better user experience and increased business agility.

Do you need help finding the best practices and strategies for your app architecture? Get in touch with us today!