DevOps, Meet the Twelve-Factor App Methodology

The Twelve-Factor app methodology is a ritual just for Ruby programmers of social applications, right? Far from it. All sorts of programmers and testers, especially those working in a DevOps framework, deserve to know more about Twelve-Factor. Here’s why.

Twelve-Factor’s origin

To be clear about how Twelve-Factor (often written as “12 Factor” or some other variant) started to help understand its current role.

In the mid-1990s, Yukihiro Matsumoto’s Ruby programming language emerged largely to compete with Perl, and especially to make object orientation more “natural.” From 2003 to 2004, David Heinemeier Hansson, in the course of first constructing the Basecamp software-as-a-service (SaaS) project management product, released Ruby on Rails (RoR) is an open-source web application framework.

RoR partially inspired the Rack webserver interface. The rack was prominent enough to serve as the foundation for the 2007 launch of Heroku as a platform-as-a-service (PaaS). Salesforce.com acquired Heroku at the end of 2010, and, over the following year, Heroku launched a number of ambitious projects. It expanded its span to the point that it now supports a half-dozen programming languages besides Ruby.

Also in 2011, Heroku co-founder Adam Wiggins published “The Twelve-Factor App” as a guide to the successful creation of cloud applications, or, as the essay puts it, “ideal practices for app development.”

“Heroku” appears only once in the original guide, and references to Ruby alternate with a wide array of other languages. Still, some readers and competitors argue that Twelve-Factor is tied too closely to Heroku; a related claim is that Twelve-Factor requires an update for a microservices-oriented architecture. NGINX, in particular, offers its Microservices Reference Architecture as a respectful modernization of Twelve-Factor.

Does all that history mean that best practice has moved on past Twelve-Factor? Is it truly only for Rubyists or Heroku customers?

No. Even niche REST providers or mobile app authors, writing in a language Heroku doesn’t support and operating entirely on their own architecture in their own data center without a hint of cloud service, profit from Twelve-Factor study.

Programming

At least half of the 12 factors have to do with how programmers work in a narrow sense, with no particular regard to deployment, operations, or even scalability or physical architecture. When we choose, for instance, to implement exactly one codebase, as the first factor prescribes, we’re a large step forward from “Right now, the current-latest is on Terry’s machine,” or even organizations that think they have a single consolidated codebase … except that testing has its own special copy.

Understand that the 12 factors are no guarantee of a good application. In themselves, they don’t address all the specific requirements and values that make a particular application worthwhile. Like a spellchecker, they don’t ensure the content of the application. Also like a spellchecker, though, they eliminate common distractions to help programmers, testers and other technical workers concentrate on true content.

The first factor is an ideal starting point: “One codebase tracked in revision control, many deploys.” Different programmers or testers might have their own copies of the application, but each instance can be referred back to an authoritative and unified repository.

These best practices aren’t specific to any particular language or architecture; they help establish a predictable starting point, whether coding the embedded automotive controller for a pollution control system or analyzing global biomedical data for a clinical study. Newcomers to a technical team with rationalized repositories will be able to find their way around better. Disaster recovery is easier to complete when codebases correspond closely to applications.

A standard source organization makes it easier to apply new tooling, rehost repositories or explain assets to director-level decision-makers.

Operations and security

Even factors that mention DevOps responsibilities beyond coding are meaningful in testing or programming perspectives.

Consider the third factor: “Store config in the environment.” This hasn’t always prevailed, in the sense that many successful applications in the past were built according to different principles. Indeed, the write-up for the third factor — one of the longer ones, at 450 words — describes a handful of alternative configuration mechanisms, along with their applicability and weaknesses.

While security is the most prominent motivation in this description, followed by the manageability of deployments, the Twelve-Factor solution appears in terms that programmers and testers can understand. A consistent expectation that configuration comes from the environment at least clarifies testers’ responsibilities when they have to cover multiple operating platforms.

This hints at another of Twelve-Factor’s virtues: It makes for a winning starting point for programmers and operators first breaking out of their silos. A trip through all of Twelve-Factor constitutes an education in DevOps mentality and practices, but at the same time, it’s brief and focused enough to be digestible.

It certainly takes work to migrate an application designed without Twelve-Factor to full Twelve-Factor standards, and some of the factors definitely constitute larger hurdles than others. Number seven, for instance — “Export services via port binding” — is incompatible with the widely used Tomcat architecture, or the even more widely used reliance on the modular extension of Apache.

The good news is that each of the different factors can be addressed separately. To complete factors one through six will pay off, even if seven is deferred indefinitely. Note that there’s no obligatory sequence of the different factors; it’s feasible to address factors two, four and nine, for instance, in any order. It’s perfectly reasonable to start with low-hanging fruit and schedule factors from easiest to most difficult to implement, from the vantage of a specific application.

Choose a starting point

What’s most important is to start somewhere. Not all applications should be Twelve-Factor-ized, and zealots for microservices or other emerging architectures will insist on at least refinements of Twelve-Factor. However, Twelve-Factor is brief enough that all programmers can profitably read it through, and it brings specific benefits in security, scalability and manageability.

Twelve-Factor applications are also cloud-native and easy to containerize, even if not otherwise designed for containers.

Suppose you know your application will never go inside a container, nor expand past its current customer base. Does that leave any reason to read Twelve-Factor? Yes. Even in the extreme case where only a couple of the factors apply, take advantage of Wiggins’ research, read how those few factors have manifested in a wide range of successful applications, and lightly standardize and document your own work in terms of the Twelve Factors. You’ll be thankful you did.