A recent blog post on Kubernetes 1.7 enhancements for stateful workloads stirred up a little controversy when I said:

“The 12 factor ban on stateful processes was really an artifact of technology limitations in the pre-Docker, pre-container-orchestrator world”.

I wanted to expand on this subject. The 12 factor manifesto proposed patterns and anti-patterns written to guide application architecture for the Heroku PAAS cloud.

There is no dispute that most components can and should be designed to be stateless, and thus allow easy and automated scale up and down. However, often apps built from these stateless components need to retain state somewhere. The 12 factors declared this must be stored in a stateful backing service. “Must” is a strong word and what exactly is that “stateful” backing service?

Well generally, a stateful backing service is a database of some kind (SQL, NOSQL, KV, etc.) exposed via an API. Essentially, you are making a declaration that storage of state is somebody else’s problem. It’s the elephant in the corner of the room that you choose not to see. For example, if you are on AWS, DynamoDB might be such a backing service. If you are on-prem, it could be an Oracle database maintained by a team of experts.

But what if you are responsible at the system level, and are pursuing goals of building an app that not only scales and is portable, but also runs in multiple public and on-prem clouds? What if you aspire to running with an identical architecture, even on isolated developer boxes? Now, you are the person maintaining the “backing store”.

The benefits of using containers and the associated orchestration platform to manage such a backing store are myriad.
Many like features such as dependency management, packaging, deployment automation, update management, and health monitoring – the same attributes enjoyed by the classic 12 factor containerized stateless processes on an orchestration platform. Some forms of stateful “backing stores” support horizontal scale out themselves. Orchestration platforms are beginning to add additional features (e.g. identity management) specifically targeted at hosting cluster aware stateful services. In other words container orchestrators are adding specific support for hosting of a backing service that you own yourself. Things like DynamoDB will be attractive to those who want to outsource that backing service, perhaps in exchange for the risk of lock-in. But container orchestration support for stateful backing services is a valuable feature for those in pursuit of a cloud native “run anywhere” strategy.

My point is not that the 12 factors is irrelevant, but that at 6 years of age in a rapidly evolving space some aspects are in need of refresh. Yes, as a general rule, apps should be composed of stateless processes – but this should not be blindly applied to rule out the possibility of utilizing containers and orchestration to deploy and manage stateful components. Container orchestration has advanced to the point where services that used to be “somebody else’s problem” can be advantageously deployed and managed by the orchestration platform.

When, or if, you deploy such stateful components, I am in full agreement that the 12 factor principle of “publishing” this behind a standard documented interface applies – in other words it is a “backing store”, but one that is hosted on the container orchestration platform and gets to cheat on the “all processes are stateless” rule. By granting this exception, rather than accepting the whole set as a religious dogma, we can redouble the usefulness of the 12 factors to help architect deployments of “backing stores”.

BTW a great revised and expanded “refresh” on the original 12 factors, “Beyond the 12 Factor App” by Kevin Hoffman is available as a free download O’Reilly book:
Beyond the Twelve-Factor App – O’Reilly Media
“In 2012, early cloud pioneer Heroku developed the Twelve Factor App, a set of rules and guidelines for helping organizations build cloud-native applications. It served as an excellent starting point, but as technology inevitably marched forward, some areas needed revisiting…”