Stateful vs stateless

The state of an application (or anything else, really) is its condition or quality of being at a given moment in time—its state of being. Whether something is stateful or stateless depends on how long the state of interaction with it is being recorded and how that information needs to be stored. 

A stateless process or application can be understood in isolation. There is no stored knowledge of or reference to past transactions. Each transaction is made as if from scratch for the first time. Stateless applications provide one service or function and use content delivery network (CDN), web, or print servers to process these short-term requests. 

An example of a stateless transaction would be doing a search online to answer a question you’ve thought of. You type your question into a search engine and hit enter. If your transaction is interrupted or closed accidentally, you just start a new one. Think of stateless transactions as a vending machine: a single request and a response. 

Stateful applications and processes, however, are those that can be returned to again and again, like online banking or email. They’re performed with the context of previous transactions and the current transaction may be affected by what happened during previous transactions. For these reasons, stateful apps use the same servers each time they process a request from a user.  

If a stateful transaction is interrupted, the context and history have been stored so you can more or less pick up where you left off. Stateful apps track things like window location, setting preferences, and recent activity. You can think of stateful transactions as an ongoing periodic conversation with the same person.

The majority of applications we use day to day are stateful, but as technology advances, microservices and containers make it easier to build and deploy applications in the cloud. 

As cloud computing and microservices grow in popularity, so too has containerization of applications, whether stateful or stateless. Containers are units of code for an application that are packaged up, together with their libraries and dependencies, so that they’re able to be moved easily and can run in any environment, whether on a desktop, traditional IT infrastructure, or on a cloud. 

Originally, containers were built to be stateless, as this suited their portable, flexible nature. But as containers have come into more widespread use, people began containerizing (redesigning and repackaging for the purposes of running from containers) existing stateful apps. This gave them the flexibility and speed of using containers, but with the storage and context of statefulness.

Because of this, stateful applications can look a lot like stateless ones and vice versa. For example, you might have an app that is stateless, requiring no long-term storage, but that allows the server to track requests originating from the same client by using cookies. 

With the growth in popularity of containers, companies began to provide ways to manage both stateless and stateful containers using data storage, Kubernetes, and StatefulSets. Statefulness is now a major part of container storage and the question has become not if to use stateful containers, but when. 

Whether or not to use stateful or stateless containers comes down to a matter of what kind of app you’re building and what you need it to do. Stateless is the way to go if you just need information in a transitory manner, quickly and temporarily. If your app requires more memory of what happens from one session to the next, however, stateful might be the way to go.

When it comes to stateful or stateless, Red Hat has you covered. Whether you’re orchestrating stateful containers on our enterprise-ready Kubernetes platform, Red Hat OpenShift, or creating a unified environment for app dev with Red Hat Integration, you’ll be backed by our award-winning support and the industry’s largest ecosystem of partners. 

See how all of our products build solutions, improve developer productivity, and promote innovation—the open source way.