The Stateless Fallacy: Why Containerized Apps Need Stateful Storage


When containers were first introduced as a way to package microservices, they were designed to be entirely stateless and ephemeral. A container would spin up, do its job and disappear, without leaving any record of what happened while it was running. Most companies started using containers for functions that lent themselves well to statelessness.

However, as companies’ container maturity increases and they start moving more and more of their applications to containers, they run into a problem: Most real-world applications need to retain state of some kind. While there might be parts of an application that don’t need state, it’s usually nearly impossible to containerize an entire application without finding a way to give the containers state—and this is even more difficult if you’re containerizing a preexisting application rather than writing a new, container-native app. That means finding a way to connect containers to stateful storage.

The Stateless Application Fallacy

Any application that stores any kind of data from one time it’s run to the next is stateful. For example, if the calculator app on your phone always displays zero when its opened, it is stateless. In the real world, most applications maintain some state. When you turn on your weather app, it remembers what city you live in—in other words, it has state.

Truly stateless applications that require zero data are fairly rare. Often, when people talk about stateless applications or stateless architectures, what they are really referring to is outsourcing your storage needs, perhaps to a host operating system or browser, so that the development team does not have to consider storage problems directly. That does make development simpler in some cases, but it can also make it impossible to use containers for either services that weren’t originally written with containerization in mind or simply for certain types of functions that require state, even if written from scratch for containers.

Connecting Containers to Stateful Storage

It might be possible to find a complex, awkward workaround to give containers access to data without connecting them to stateful storage. In practice, and especially in an enterprise setting, it makes far more sense to use software-defined storage to connect containers to data.

While containers can spin up and down dynamically, storage needs to be accessible at all times, so that the container can access the data it needs to do its job and to ensure that the data it’s storing isn’t lost. The only way to containerize applications that require state is to connect containers to stateful, persistent storage.

When done right, with cloud-native, software-defined storage, connecting containers to stateful storage doesn’t have to limit the system’s scalability or agility. Software-defined storage and automation tools make it possible for containers to connect and disconnect from storage as they move around the cluster, maintaining both state and the advantages of a containerized application.

Limiting container use to functions that don’t require state would ultimately make it impossible to containerize entire applications. Using containers for just a fraction of the application doesn’t allow businesses to get the agility, portability and elasticity that truly containerized applications offer, and also increases the complexity of the entire application. Connecting your containers to stateful storage expands the possibilities for containerizing applications.

written by:
Alex Chircop
Alex is a founder and CTO of Ondat (formerly StorageOS), building software-defined solutions for cloud-native environments. Alex is also a co-chair of the CNCF Storage TAG (previously SIG). Before embarking on the startup adventure he spent over 25 years engineering infrastructure platforms for companies like Nomura and Goldman Sachs.