What Is the Twelve-Factor App and How Do I Monitor It?

The Twelve-Factor App: What It Is and How to Monitor It

1. An app is made up of a single, versioned codebase. 

​We didn’t use source code versioning at all in my early days as a software developer—we manually synced code across engineers, dumped it in a shared folder, and prayed for the best. Setting up IDEs was difficult, application packaging/deployment was a dangerous “artform,” and a lot could (and did) go wrong. 

​You work from a single codebase tracked in a version control system (such as GitHub or Subversion) and use numerous deployment environments in a Twelve-Factor App (staging, dev, production, etc.). Consider the following scenario: You have a distributed system, not an application if you have many codebases. 

​2. An app declares its dependencies explicitly. 

​It is just another fantastic advantage of current programming languages and frameworks. Gone are the days of hunting down jars/dependencies to try to compile a project. And gone are the days when large projects were plagued by dependency hell, with different components requiring different versions of the same program. A deterministic build process is guaranteed with a Twelve-Factor Program. Thus can always rebuild the app from scratch, and dependencies will never be missed or collide internally. 

​3. Save the configuration of an app in environment variables. 

​The setup of an application is likely to differ from one environment to the next. Different versions of an app’s codebase, for example, could be delivered to development, testing, staging, and production environments. 

​The Twelve-Factor App recommends keeping “tight separation of config from code” and storing application settings in environment variables. 
​

4. Resources are behind services.

As part of their routine operation, most apps connect via API with various services; backing services include local or third-party databases, message queues, and cache services. The Twelve-Factor App defines a backup service as “any service the app consumes across the network as part of its usual functioning.”

According to the Twelve-Factor App, “the code for a twelve-factor app makes no distinction between local and third-party services.” “Both are associated resources to the app, accessible via a URL or other locator/credentials stored in the configuration.”

5. Make your app’s stages distinct.

The Twelve-Factor App has three primary steps: create, release, and run.

You compile all of your code from your version control repo and package that version of the app in the build stage. To deploy the app live, you must combine the build and the app’s settings in the release stage. Finally, you’ve completed the app’s execution in the run stage and generated a new release.

According to the Twelve-Factor App, “every release should always include a distinct release ID, such as a date of the release (for example, 2011-04-06-20:32:17) or an increasing number (such as v100).”. Any changes to the build (such as bug fixes) necessitate a new release.

6. It’s critical to have stateless processes.

It is an important consideration when developing cloud apps that are both flexible and scalable. The program is deployed as one or more processes in the execution environment, and the processes are stateless and share nothing. According to the Twelve-Factor App, “all data that needs to persist must be kept in a stateful backing service, often a database.”

According to the technique, even session state data (think “sticky sessions”) should be saved in a solution that allows for time-based expiration, such as Memcached or Redis.

I recall having to deal with stuck sessions and load balancing. It now appears like so much time has been wasted. Scalability, resiliency, and redundancy are all built on statelessness. If your app parts are stateless, you can scale up your funding and resources to load “automagically.”

7. Instead of packing a web server, use port bindings.

The services of a Twelve-Factor web app are delivered over HTTP rather than through a web server. It is accomplished by binding the app to a port that allows it to send and receive requests. It ensures that the program is self-contained and not dependent on a specific web server.

8. Run processes in parallel

Different processes handle different types of labor in a Twelve-Factor App: “A web process, for example, might handle HTTP requests, while a worker process might handle long-running background chores… it does not rule out the possibility of individual processes handling their internal multiplexing.” In this model, scale denotes the number of concurrently operating processes, whereas workload denotes the number of different types of running processes.

In essence, a Twelve-Factor App must be able to scale horizontally, and if stateless processes are used, this scale should be smooth.

9. Processes are thrown away.

Before we started creating cloud apps, I had cloud infrastructure that took 10 minutes to reach production. It would jeopardize our system if a production server went out of rotation. To make matters worse, essential components of the applications were stateful, which meant that any server or process shutdown, whether graceful or not, caused disturbances for our users.

The processes of a Twelve-Factor App are disposable: “they can be initiated or discontinued at any time.” It is all made possible by fast and elastic scalability, rapid deployment of code or configuration changes, and stable production deployments.

From the start, systems should be able to run jobs as quickly as possible. Similarly, if they receive a signal like SIGTERM, they should be able to gracefully shut down (i.e., finish any active requests before ending).

For applications that use auto-scaling, this process disability is critical (such as containerized apps orchestrated by Kubernetes). Disposability is evident in today’s containerized environment. New Relic discovered that most containers have an average lifespan of less than an hour by studying how our clients use Docker to execute their apps.

10. Keep dev and prod deployments in sync as much as possible.

How often did I make live updates to a local app deployment without keeping those changes in sync with production back in the day? To put it another way, if this were a software crime, I’d have to plead “guilty as charged.”

According to the Twelve-Factor App, three gaps might occur due to a lack of parity: time, personnel, and tools. To avoid these gaps, developers should have their code deployed as soon as possible, be present when ops—or whoever—deploys the code, and utilize the same tool stack as production.

11. Logs are streams of events.

According to the Twelve-Factor App, a log is “a stream of aggregated, time-ordered events collected from the output streams of all operating processes and backing services…. [They] have no specified beginning or finish, but continuously flow as long as the app is operational.”

It’s nearly impossible to imagine operating production-grade apps without it nowadays. However, before the widespread use of Application Performance Management, logs were often the only monitoring tools available.

I recall creating extensive logging “frameworks” to standardize log style and output across my applications. Another process would parse the logs and inform us when things weren’t working as expected. I often wonder how much time I squandered maintaining all that code.

Unfortunately, some systems and technologies are still unable to be instrumented, relying mainly on logs for monitoring.

12. Run administrative and managerial tasks in the same environment as regular tasks.

“Process creation” is defined as “an array of processes used to do the app’s regular work as it runs” by the Twelve-Factor App. In some circumstances, such as database migrations, developers may need to run management processes for an app. Therefore the approach advises that “one-off admin processes” run in the same release environment as usual processes, using the same code and settings as any other process in that release.

Conclusion

Although there will never be a proper “one-size-fits-all” application framework, approaches like the Twelve-Factor App give an excellent set of best practices for architecting, implementing, and sustaining modern apps. Still, the essential, actionable data we collect will help you make sure your apps—and your customers’ experiences—are as good as possible.

Enteros

About Enteros

Enteros offers a patented database performance management SaaS platform. It proactively identifies root causes of complex business-impacting database scalability and performance issues across a growing number of RDBMS, NoSQL, and machine learning database platforms.