The Twelve-Factor App (Summary) —A New De-facto For SaaS ?

Note: This article is a summary of The Twelve-Factor App Documentation. If you want a comprehensive doc visit Twelve-Factor

In today’s digital world most of us are not inclined towards purchasing physical medias in favor of services that gives us access to a wide varieties of options at our fingertips. For example we don’t own physical copies of music or movies , but instead we opt for a service or stream and use them whenever we want for a small monthly service fee . Like Netflix for movies and Spotify for music.

Same applies for software. Software as a Service (SaaS) is becoming a de-facto for companies.

Software as a Product (SaaP) are expensive and requires extensive maintenance that involves update costs.

Who should read this?

Developers building app’s which runs as a service ,Ops engineers who deploy or manages such application and lastly for those who don’t have time to read full documentation.

What is The Twelve Factor App?

It is common to see software being delivered as a service: called web apps , or software-as-a-service. The twelve factor app is a methodology for building SaaS that incorporates:

1. Declarative format for setup automation
2. Clean contrast with the underlying operating system
3. Maximize portability between execution environments
4. Minimize divergence between development and production.
5. Continuous development for maximum agility
6. Scaling up without significant changes to tooling , architecture or development practice

The Twelve Factors

1. Codebase
2. Dependencies
3. Config
4. Backing Services
5. Build , Release , Run
6. Processes
7. Port Binding
8. Concurrency
9. Disposability
10. Dev/ prod parity
11. Logs
12. Admin Processes

Codebase (One codebase tracked in revision control, many deploys)

• In any software development it involves a sub system namely version control system. Such systems like Git, Mercurial or Subversion keeps track of revisions made. A copy of the revision tracking database is known as code repository.
• The Twelve-Factor app believes in maintaining one on one relationship between codebase and the app. In case there are multiple code base then it’s not an app — it’s a distributed system.
• Multiple app sharing the same code is a violation of twelve-factor.
• Single code base is responsible for many deploys of the app. Typically a production site or one or many staging sites.
• Code base is the same across all deploys but different version may be active in each deploy

Dependencies (Explicitly declare and isolate dependencies)

• Most of the programming languages provide a packaging system for distributing support libraries.
• Libraries installed through a packaging system can be installed system-wide or scoped into the directory containing the app (known as “vendoring” or “bundling”)
• A twelve-factor app never relies on implicit existence of system-wide packages.
• Use of dependency isolation tools during execution to ensure that no implicit dependencies “leak in “ from the surrounding system.
• For example, Bundler for Ruby offers the Gemfile manifest format for dependency declaration and bundle exec for dependency isolation.
• In Python there are two separate tools for these steps — Pip is used for declaration and Virtualenv for isolation.
• Even C has Autoconf for dependency declaration, and static linking can provide dependency isolation.
• Twelve-factor apps also do not rely on the implicit existence of any system tools

Config (Store config in the environment)

Note that this definition of “config” does not include internal application config

• An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc)
• Sometimes configs are as constants in the code. This is a violation of twelve-factor, which requires strict separation of config from code.
• The twelve-factor app stores config in environment variables (often shortened to env vars or env)
• In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars.
• Env vars are never grouped together as “environments”, but instead are independently managed for each deploy.

Backing Services (Treat backing services as attached resources)

• backing service is any service the app consumes over the network as part of its normal operation.
• Examples include datastores (such as MySQL or CouchDB), messaging/queueing systems (such as RabbitMQ or Beanstalkd)
• The code for a twelve-factor app makes no distinction between local and third party services.
• A deploy of the twelve-factor app should be able to swap out a local MySQL database with one managed by a third party (such as Amazon RDS) without any changes to the app’s code.
• Each distinct backing service is a resource
• The twelve-factor app treats these databases as attached resources, which indicates their loose coupling to the deploy they are attached to.
• Resources can be attached to and detached from deploys at will.

Build, Release, Run (Strictly separate build and run stages)

• A codebase is transformed into a (non-development) deploy through three stages
• The build stage is a transform which converts a code repo into an executable bundle known as a build.
• The release stage takes the build produced by the build stage and combines it with the deploy’s current config.
• The run stage runs the app in the execution environment, by launching some set of the app’s processes against a selected release.
• The twelve-factor app uses strict separation between the build, release, and run stages
• Every release should always have a unique release ID, such as a timestamp of the release or an incrementing number.
• run stage should be kept to as few moving parts as possible

Processes (Execute the app as one or more stateless processes)

• app is executed in the execution environment as one or more processes.
• Twelve-factor processes are stateless and share-nothing.
• Any data that needs to persist must be stored in a stateful backing service, typically a database.
• The twelve-factor app never assumes that anything cached in memory or on disk will be available on a future request or job
• with many processes of each type running, chances are high that a future request will be served by a different process
• Session state data is a good candidate for a datastore that offers time-expiration, such as Memcached or Redis.

Port Binding (Export services via port binding)

Note also that the port-binding approach means that one app can become the backing service for another app, by providing the URL to the backing app as a resource handle in the config for the consuming app.

• The twelve-factor app is completely self-contained
• does not rely on runtime injection of a webserver into the execution environment to create a web-facing service
• In deployment, a routing layer handles routing requests from a public-facing host name to the port-bound web processes.
• typically implemented by using dependency declaration to add a webserver library to the app
• such as Tornado for Python, Thin for Ruby, or Jetty for Java and other JVM-based languages
• The contract with the execution environment is binding to a port to serve requests.

Concurrency (Scale out via the process model)

• In the twelve-factor app, processes are a first class citizen
• Processes in the twelve-factor app take strong cues from the unix process model for running service daemons
• A managed process should run automatically when the operating system starts up, and should be restarted if the process crashes or dies for any reason.
• For example, HTTP requests may be handled by a web process, and long-running background tasks handled by a worker process.
• The share-nothing, horizontally partitionable nature of twelve-factor app processes means that adding more concurrency is a simple and reliable operation.
• Twelve-factor app processes should never daemonize or write PID files

Disposability (Maximize robustness with fast startup and graceful shutdown)

• The twelve-factor app’s processes are disposable, meaning they can be started or stopped at a moment’s notice.
• facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys
• Processes should strive to minimize startup time
• Short startup time provides more agility for the release process and scaling up and it aids robustness
• Processes shut down gracefully when they receive a SIGTERM signal from the process manager.
• web process, graceful shutdown is achieved by ceasing to listen on the service port
• a worker process, graceful shutdown is achieved by returning the current job to the work queue
• Processes should also be robust against sudden death
• A recommended approach is use of a robust queueing backend, such as Beanstalkd, that returns jobs to the queue when clients disconnect or time out.
• twelve-factor app is architected to handle unexpected, non-graceful terminations

Dev/prod parity (Keep development, staging, and production as similar as possible)

• The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small.
• Make the time gap small: a developer may write code and have it deployed hours or even just minutes later.
• Make the personnel gap small: developers who wrote code are closely involved in deploying it and watching its behavior in production.
• Make the tools gap small: keep development and production as similar as possible.
• The twelve-factor developer resists the urge to use different backing services between development and production
• all deploys of the app (developer environments, staging, production) should be using the same type and version of each of the backing services.

Logs (Treat logs as event streams)

• Logs provide visibility into the behavior of a running app
• Logs are the stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services
• A twelve-factor app never concerns itself with routing or storage of its output stream
• each running process writes its event stream, unbuffered, to stdout
• The event stream for an app can be routed to a file, or watched via realtime tail in a terminal.

Admin processes (Run admin/management tasks as one-off processes)

• The process formation is the array of processes that are used to do the app’s regular business
• one-off administrative or maintenance tasks for the app, such as Running database migrations ,Running a console , Running one-time scripts committed into the app’s repo
• One-off admin processes should be run in an identical environment as the regular long-running processes of the app
• Admin code must ship with application code to avoid synchronization issues.
• Twelve-factor strongly favors languages which provide a REPL shell out of the box, and which make it easy to run one-off scripts.
• In a production deploy, developers can use ssh or other remote command execution mechanism provided by that deploy’s execution environment to run such a process.

The motivation behind 12-factor app is to raise awareness of some systematic problems in modern application development. It provides a shared vocabulary for discussion those problem and to offer a set of broad conceptual solutions to those problems with accompanying terminology.

Who is Sabin Sharma ?

If you are interested in automation you should check my other article Automating Tinder?! Perks Of Being A Programmer

If you are interested in Algorithms you should check my other articles, Molecular Dynamics Simulation of Hard Spheres — Priority Queue In Action With Java , Make Your Own AI Powered Game, NVIDIA Fan Controller For Linux(DIY).

And If you are interested in Cyber Security read my recent article Getting Your Hands Dirty: Exploiting Buffer Overflow Vulnerability In C