Businesses have a mandate to gain a competitive advantage from IT. Invariably, this discussion turns to cloud-native apps. Leaders ponder questions like “How can we create, run, and scale new applications quickly and easily?” “How do we experiment, get to market faster, and reduce the cost of trying new things?”

The answer: embrace the development and operational principles behind “12 Factor Apps.”

Our AppFog service (based on Cloud Foundry) makes it easy for developers to create apps that adhere to these 12 factors.

But what are these 12 factors? What does the developer need to do differently?

12 Factor Apps Meme

Thankfully, this phrase - defined on this manifesto - has avoided the fate of terms like “cloudbursting” or “as-a-service.” It has a very specific technical meaning, and strong roots with engineers, not vendors.

For those just getting started with cloud native apps, we thought it might be helpful to discuss each of the factors – and what you can do to adhere to each one. We’ve included quotes from the 12 Factor site when helpful.

I. Codebase - One codebase tracked in revision control, many deploys


Many organizations have siloed development and operations teams (unintentionally or otherwise). This results in different codebases; different versions across different systems, from the corporate servers running production, all the way down to employee laptops. By contrast, a single codebase with many branches, dramatically simplifies the ongoing management, improvement, and deployment of said code.

With many codebases, the variation makes it very difficult to understand the impact of new enhancements on production code. As a result, enhancements don’t happen very often. And when a push to production does occur, it’s a white-knuckle moment for everyone.

Multiple codebases also occur when the business has said “yes” to multiple, custom versions of the software – usually to appease one-off customer requests.


A single, shared code repository like Github. This environment enables developers to work in branches off the same base with incremental changes happening multiple times a day. These are easily merged and managed with Git-based tools. Deployments to environments (lab, QA, staging, master, production, what have you) are dramatically easier.

II. Dependencies - Explicitly declare and isolate dependencies

A twelve-factor app never relies on implicit existence of system-wide packages.


Code always depends on something – a library, package, or data store. The presence of these dependencies are not guaranteed to be on any given environment, so you should ensure your apps identify each dependency and account for them.

This is also about explicitly declaring and not assuming dependencies. Most developers are mindful of this idea today. The importance of it though has grown as apps have become more fluid and portable across different hosts.


Developers have to check for existence of ANY dependency and install what’s needed. Most modern languages and frameworks support this factor – it’s “best practice” that dates back decades. In the IDE, the developer can usually declare the libraries that need to be in place, and then a command can be run to assemble them as specified. In the world of containers, for example, you set up your own dependencies, and never look for something existing on the server.

III. Config - Store config in the environment

The twelve-factor app stores config in environment variables


There are two elements of a code deployment: the code (that does not change) and the environment (that does change). Configuration is what changes to make the code run on different environments: credentials to other services, locations of required resources, and so on.


This one is simple: don’t hard code configuration details into the code. Instead, store them as environment variables that can be easily changed based on the target environment.

IV. Backing Services - Treat backing services as attached resources

The code for a twelve-factor app makes no distinction between local and third party services.


A backing service is simply any service that the app uses over a network (database, storage, identity, etc). Of course, these days apps touch many different types of services – and your code shouldn’t care where they are located. This means that swapping out one type of service for another (either local or remote) should require no code changes.


Backing services should be called via an API using credentials that are stored in configuration from the run-time environment. Any other approach creates complexity, and won’t allow you the flexibility to swap out services (say an S3 object storage service across vendors, or a local DB for a production DB) in different locations easily.

V. Build, release, run - Strictly separate build and run stages

The twelve-factor app uses strict separation between the build, release, and run stages.


These stages of deployment should be distinct – the “build” process is complex and requires that developers be on-hand to manage. The run-time execution of the app on the other hand – should be highly automated, since it will need to be invoked in many scenarios (such as during the auto-recovery of a new instance after a hardware failure) when engineers may not be available. Clear separation of these processes will result in more streamlined (and more frequent!) deployments.


Achieving this factor can be a large cultural shift that shows up in development tools and frameworks – the IDE, the continuous integration servers, and automation. With the right tools and processes, the work should be done for you, including making sure that every release should always have a unique release ID.

VI. Processes - Execute the app as one or more stateless processes

Twelve-factor processes are stateless and share-nothing.


When you hear the term “build for failure” – this is the factor they usually have in mind. Stateless apps are designed to withstand failure of underlying hardware components. This is a fact of life in cloud (regardless of the provider you are using).

Will Koffel explains stateless apps below:

“…the state of your system is completely defined by your databases and shared storage, and not by each individual running application instance. Let’s say you have a signup workflow, where a user has to enter 3 screens of information to create their profile. One (wrong) model would be to store each intermediate state in the running code, and direct the user back to the same server until the signup process is complete. The right approach is to store intermediate data in a database or persistent key-value store, so even if the web server goes down in the middle of the user’s signup, another web server can handle the traffic, and the system is none-the-wiser.”


As the manifesto notes, persistent data should be “stored in a stateful backing service, typically a database.” Storing this in running code, as noted above, will result in all kinds of operational problems and troubleshooting headaches as your app scales.

VII. Port binding - Export services via port binding

The twelve-factor app is completely self-contained.


This is related to the fourth factor discussed earlier. Just as the backing services you consume are connected via URL, your application must interface the same way, via URL.


If you have a web application, this is already done via the web server. In addition, most developer tools support this natively. So, chances are, you’re already doing this today. If not, consider tools that do offer you this capability.

VIII. Concurrency - Scale out via the process model

In the twelve-factor app, processes are a first class citizen.


In the cloud computing era, rapid scale and elasticity are common as developers rapidly iterate on apps and a culture of experimentation takes hold in the business.

With this backdrop – processes – simply a running slice of code – need to be constructed independently so they can start, stop, and restart with a minimum of disruption to others.


Ensure that a single instance runs in its own process. For instance, in Linux environments, you could actually see a process for a Java app that is bound to a port (as mentioned above in the previous factor). On Windows you would see a separate service running for each app rather than using an app server to run all of the web apps behind a single port.

This independence will help your app scale out gracefully as real-world usage demands.

IX. 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. This facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys.


The 12 Factor site quote above is straightforward enough. So let’s consider this from the opposite angle – what are the consequences of a slow initiation and a clumsy shutdown sequence? It’s more stress and strain on the app itself, and it’s harder to introduce change to the code. Not to mention, it can result in a poor user experience and high latency.


Use components that are ready and waiting to serve jobs once your app is ready – you can’t (and shouldn’t) try and do this on your own! Technologies to consider are databases and caches like RabbitMQ, Redis, Memcached, and CenturyLink’s own Orchestrate. These services are optimized for speed and performance, and help accelerate startup times. There are many other technologies you can consider for other application components, but these are tools to consider for this particular factor.

They also help with graceful shutdown – the example the factor cites is again helpful: “for a worker process, graceful shutdown is achieved by returning the current job to the work queue.” Eliminating jobs or processes done upon shut-down should also be done.

X. 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.


This is one of the more intuitive factors - the more consistency you have across environments, the easier it is to rapidly iterate and change code. So what specifically should you make sure is consistent? The infrastructure stack, config management processes, software and run-time versions, deployment tools – you name it, it should be the same across the board.


Public cloud services make the infrastructure side easy, at least between QA/test, staging and production. This is one of Docker’s primary benefits (it can even work with tools like Cloud Foundry for this purpose), and there are other tools like Puppet that help dev machines look-and-feel more like production. Adopting continuous integration and continuous deployment models (as noted in the factor) will lead to adherence to this factor as well.

XI. Logs - Treat logs as event streams

A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles.


The data deluge has been widely discussed for quite some time. For developers, all of this data (log files for this factor, complete with timestamps) is a goldmine of information. Combined with cheap storage, useful SaaS apps, and open-source tooling, it’s never been easier to measure how your app is performing in production, how people are using it, and where you should look to improve.


Stream the logs to two places: view these logs in real-time on your dev box and store them in tools, like ElasticSearch, LogStash and Kafka. SaaS products like Splunk are also popular for this purpose.

XII. Admin processes - Run admin/management tasks as one-off processes


Once your application is in production, that’s when the real work starts! Gathering data on the health, performance, and usage data of the app – as well as running A/B tests - is crucial to understanding what should be enhanced. How you gather this data – the running of “admin/management tasks” mentioned in the final factor – is the key piece. This should be done in production.


As mentioned above, perform these activities from a machine in the production environment that’s running the latest production code. As Will Koffel notes, “Don’t run updates directly against a database, don’t run them from a local terminal window.” Why? You get an incomplete and inaccurate picture of what’s happening when you don’t work directly from prod.

Building 12 Factor Apps has never been easier than right now

AppFog delivers many of these factors “for free,” built-in to the platform (especially when combined with Orchestrate to store state!). Give it a try today and see for yourself.

For more on this topic, be sure to check out this wonderful podcast from Simon Elisha of Pivotal that explains the 12-factors with a Cloud Foundry focus. Another helpful explainer can be found on ClearlyTech.