Beyond the Twelve-Factor App

Chapter 10. Administrative Processes

The twelfth and final factor originally stated, “Run admin/management tasks as one-off processes.” I feel that this factor can be misleading. There is nothing inherently wrong with the notion of an administrative process, but there are a number of reasons why you should not use them.

The problem with the original twelve-factor recommendation is that it was written in an opinionated way with a bias toward interpreted languages like Ruby that support and encourage an interactive programming shell.¹ Administrative processes were a feature the authors wanted customers to utilize.

I contend that, in certain situations, the use of administrative processes is actually a bad idea, and you should always be asking yourself whether an administrative process is what you want, or whether a different design or architecture would suit your needs better. Examples of administrative processes that should probably be refactored into something else include:

• Database migrations
• Interactive programming consoles (REPLs)
• Running timed scripts, such as a nightly batch job or hourly import
• Running a one-off job that executes custom code only once

First, let’s take a look at the issue of timers (usually managed with applications like Autosys or Cron). One thought might be to just internalize the timer and have your application wake itself up every n hours to perform its batch operations. On the surface, this looks like a good fix, but what happens when there are 20 ...