Revisiting the 12 Factors: Port Binding, Disposability, and Processes

Three of the 12 Factors factors are closely related and I want to cover them here as they collectively may seem remedial to some of us, but are historically important.

All services/apps are:

• Stateless Processes…
• …that bind to a Port…
• …and are Disposable

Prior to working at Stitch Fix—where everything was hosted on Heroku and thus followed the 12 factors—I had very little experience operating apps in production. Most of my experience was working on Java enterprise apps.

Your Code as a Plugin

If you never had the pleasure, deployment for Java enterprise apps required creating a special .zip file (with the suffix .war instead) that contained the app's compiled classes and some metadata about the app (all in XML, 'natch).

To deploy, you make the file available to an app server like JBoss or a web server like Tomcat or Jetty. PHP and Rails were initially managed in a similar fashion: they were run inside a web server as a plugin and not standalone.

(Of note, this is how serverless functions tend to be deployed as well. You create a special archive and upload it to your cloud provider's infrastructure and they handle invoking it.)

12 Factor wants you to manage your app as a process.

Your App is Just Some Process

Instead of running inside some other management process, your app runs as a process on its own. In order to serve requests, it must listen on a port. The real special part is being stateless or disposable.

To scale up or down, you can add or reduce the number of processes that are able to handle requests. To do that quickly and without worry, the processes must not have internal state. If they did, new processes might lack that state, or processes that are stopped would lose valuable information.

When the processes are stateless, restarting them is a non-event. In fact, Heroku restarts your app at least once a day. Non-Heroku deployment systems work differently. The platform we built at Stitch Fix did this, as it was a way to ensure that any built-up state (including malicious actors) would never live more than 24 hours.

And Then There is Serverless

I don't have a ton of experience with Serverless/Functions-as-a-service, but I know that we might be in the Trough of Disallusionment part of the Gartner Hype Cycle. A lot of teams are moving away from it as a generalized solution, instead only using it for very specific workloads.

I wager one reason for this is that they aren't managed like normal UNIX processes. You are at the mercy of the platform owner to provide any level of observability, and this often requires additional set up and cost. Even the most degenerate hosting situation can run tail, ps, lsof, or top to understand what the UNIX processes are doing.

With Serverless, you usually get nothing by default. This is how JBoss worked as well - anything you wanted to know or observe had to be configured explicitly.

So, these three factors still seem apt. They may have been revolutionary at the time, but now they seem almost trite. Of course our apps run as a process listening on a port without meaningful state in the app's memory.

Unless otherwise noted, my emails were written entirely by me without any assistance from a generative AI.