The 12 Factor App

12 factor app is a methodology for building software as a service apps. This methodology can be applied to any app, written in any programming languages. Below are my understanding about 12-app factors:

1. Code base: Code is always tracked in a version control system (like git). Some key points:

  • If there are multiple code bases, it\’s not an app, it\’s a distributed system.
  • Multiple apps should not share the same code. Instead, they should create shareable libraries.

2. Dependencies: All dependencies must be declared in a dependency manifest. It simplifies the set-up process for developers. 12 factor app also does not rely on implicit system tools. It\’s to avoid any risk of getting a tool or a feature decommissioned in the future.

3. Config: Configuration files must be separate from code. Store these into environment files. Config files must not be checked into repository.

4. Backing services: Backing services are the services that app consumes over the network as part of its normal operation. For example, an app uses a MySQL Database, or Amazon S3, or messaging services. Each backing service is a resource.

5. Build, release, run: Strictly separate build and run stages. Build is a stage that bundles the needed files into an executable package. Release is a stage to take build and combine it with the deploy\’s current config. Run runs the app in the executable environment.

6. Processes: The app is executed in one or more processes. Twelve-step processes are stateless and share-nothing. Any data that needs to be persists, must be stored in a backing service, like a database. Sticky sessions are violations of 12-step process.

7. Port binding: Export services via port binding. One app can also become a backing service to another app.

8. Concurrency: Scale out via the process model. Processes are a first class citizen.

9. Disposability: This means, 12-step processes can be started and stopped at any time. Processes should thrive to minimize the startup time.

10. Dev/prod parity: Keep development, staging, and production as similar as possible.

11. Logs: Treat logs as event streams.

12. Admin processes: Run Admin processes as one-off processes. For example, in my Laravel code, I ran process to create database tables as a one time setup.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s