Good article on Containers. In the real world, we always must maintain the state of the application and usage, per user, somewhere even with Containers.
Most existing applications must maintain their state. Containers and micro-services preach state-less. For many firms this does not make sense. They will not, and should not in most cases, rewrite their application stack to fit into a container-model. So what to do?
Most applications are stateful. Stateful is when streaming services remember where you left off in a movie even if you switch devices, or mobile applications store users’ preferences or recently opened files. For application-level cases, it’s the ability to recover from a session interruption, putting the users back to the place they left off, without loss of data.
We come from a stateful world. Stateful applications remember things about states, which is durable across sessions. The state data is stored within some nonvolatile mechanism, such as physical storage, including databases.
Enter containers, with new challenges and opportunities regarding state retention. In the world of containers, we are taught to be stateless. In container design, including courses I’ve taught, the idea is that a container emerges as an instance, does what it’s programmed to do, and goes away without maintaining state.
If indeed it works on data from some external source, it’s handed the data by another process or service, returning the data to another process before being removed from memory. Still, no state maintained.
The core issues are that containers, as invented years ago, just could not save state information. There was no notion of persistent storage, so maintaining state was impossible. We were taught early on that containers were for operations that did not require state retention.
Some people still argue the need for stateless when building container-based applications, contending that it’s the cleanest approach, and that thinking stateful means thinking in outmoded ways.
However, that may not be acceptable to most enterprises developers who are using containers. Traditional applications are not purpose-designed and built for containers. For example, applications refactored for containers are typically stateful and depend on state data.
Attempting to make these applications stateless is typically a Herculean effort. It adds cost and risk to the point of “why bother moving them to containers?” Moreover, even scratch-built container applications targeted for containers may find that maintaining state is a fundamental feature that they can’t avoid based on a business need. Indeed, workarounds to make applications stateless that should maintain state are really not going to be the cleanest approach.
The case can be made that container-based applications need to support both state models. Good thing Kubernetes and other technologies provide mechanisms to be stateful. In fact, given the fact that many container-based systems will be federated/distributed, stateful is a core requirement of those architectures.
What’s my take on this? All applications, including container-based applications, need to provide developers with an option to be both stateful and stateless. It’s just too limiting to say that stateless applications are the only valid approach when most developers know that in the real world that’s not true.
In the real-world VMs, Stateful applications and Stateless applications can all be valid. It is not a either-or choice, or a binary mutually exclusive model.
