The Twelve-Factor App Methodology for building a successful SaaS Applications

Software as a Service (SaaS) is a software licensing and delivery model. Here, the service provider hosts applications and makes them available to customers over the Internet. Salesforce.com is a well-known example of software as a service.

The twelve-factor app is a methodology 

• For building a Software as a Service
• Can be applied to an application which is implemented using any programming language
• Can be applied to an application which uses any combination of backing services (memory cache, database, queue etc)

What are the twelve factors?

I. Codebase

 A software which is implemented using the twelve-factor methodology should be tracked in a version control system such as  Github. There should be only one codebase for an application. But there may be various deployments of the app which use the same codebase across all deployments.

 There may be different versions be active in each deployment. For example, a developer has some commits which are not deployed yet to the staging environment and staging environment has some commits not deployed yet to the production environment. But they all share the same codebase. Thus making them identifiable as different deploys of the same app.

2. Dependencies

Most programming languages offer a packaging system to distribute support libraries. As an example of a packaging system, we can introduce RubyGems. It is a package manager for the Ruby programming language. It provides a standard format for distributing Ruby programs and libraries. RubyGems is designed to easily manage the installation and distributing them.

Java developer can use Maven, Gradle or Ivy as the dependency management tool. When using Maven as a dependency management tool it explicitly declares all the application Jar files within the application `pom.xml` file. Using Maven, the developer can pin specific versions of the dependencies to the application. It ensures consistency in the build. 

A twelve-factor application should not rely on the implicit existence of system-wide packages. It declares all dependencies via a dependency declaration manifest. It uses a dependency isolation tool during execution. And a Twelve-factor app also not relies on the implicit existence of any system tools.

3. Configuration

Every application has a configuration which varies between deployment environment. The following can be given as a configuration.

• Resource handles to  backing services (Database, Blockchain etc)
• Credentials to external services such as Salesforce
• Per deployment values (Ex -canonical hostname for the deployment)

When implementing the Application, some developers store configuration values as constants in the code. This is a violation according to the twelve-factor app methodology. Twelve-factor app methodology requires strict separation of configuration values from code. But we don’t need to separate internal application configuration values from code. 

An application which is implemented according to the twelve-factor app methodology stores configuration in environment variables. Environment variables are easy to change between deployment environment without changing any code.

4. Backing services

A backing service is any service which is consumed by application over the network as a part of its normal operation. So databases, caching systems, messaging/queueing systems and SMTP services can be given as backing services.

Deployment of the twelve-factor app should be able to swap out its backing service without any changes to the application code. So the application treats backing services as attached resources. The application should declare its backing services via an external configuration or even a source-controlled config server. 

This loose coupling has many advantages like attaching new backing service without restarting the application. if the application's backing service is misbehaving due to a hardware issue, the system administrator can detach the current backing service and the new backing service without any code changes.

5. Build, release, run

The twelve-factor app uses strict separation between the build, release, and run stages. A codebase is transformed into a deployment through these stages:

The build stage – In this stage, 

• Converts the source code into an executable bundle
• Fetches vendors dependencies and compiles binaries and assets

The release stage – In this stage

• Takes the build produced by the build stage and combines it with the deployment current configuration
• Contains both the build and the configuration and is ready to run in the execution environment

The run stage – In this stage

• Runs the application in the execution environment by launching some set of the application’s processes against a selected release.
• Never change code at run stage since there is no way to propagate those changes back to the build stage.

6. Processes

Twelve-factor application’s processes are stateless and share-nothing.  And any data that needs to persist must be stored in a stateful backing service, typically a database.

The twelve-factor application never assumes that anything cached on disk or in memory will be available on a future request or job. this factor advocates moving any long-running state into an external, logical backing service implemented by a cache or data store.

Source - https://12factor.net

I will discuss the other 6 factors in the next article. Thank You.