Understanding stateful vs. stateless containers
Understanding the difference between stateful and stateless containers is crucial for designing resilient and scalable applications. But what exactly are stateful and stateless containers?
Imagine for a moment that you visit a coffee shop every morning. In one scenario, the barista remembers your name and your usual order. In another scenario, the barista treats you like a new customer each time, asking for your order from scratch and forgetting all past interactions.
In the world of containers, this is the difference between stateful and stateless containers:
- A stateful container remembers past interactions and maintains data between sessions.
- A stateless container treats each request as independent.
What is a stateless container?
A stateless container does not retain any data or state between requests. Stateless containers are widely used in cloud-native applications because they are easy to scale, load balance, and replace. They are typically used for microservices, REST APIs, and front-end applications.
Example: a simple stateless web service
Here’s a basic Flask application running in a stateless container. Let’s call the file “app.py”:
from flask import Flask
app = Flask(__name__)
@app.route('/')
def hello():
return "Hello, world!"
if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000)
If this service runs in a container and gets restarted, no data from previous interactions will be retained. Each request is handled independently.
To deploy this as a Docker container, create a Dockerfile as follows:
FROM python:3.9
WORKDIR /app
COPY app.py .
RUN pip install flask
CMD ["python", "app.py"]
To build and run the stateful container with a persistent volume, use:
docker build -t stateless-app . docker run -v $(pwd)/data:/app/data -p 5000:5000 stateless-app
Running this container multiple times will always give the same response, with no memory of previous users or requests. Each time you visit http://127.0.0.1:5000 in your browser, you should only see the text “Hello, world!” displayed.
What is a stateful container?
A stateful container retains data between requests and relies on persistent storage or an internal state to maintain continuity. This is useful for applications like databases, session-based web applications, and stateful services. However, compared to stateless containers, stateful containers cannot be easily replaced without considering state consistency. Often, stateful containers depend on volumes or external databases.
Example: a stateful web service
Imagine a simple Python-based counter application that increments a value every time it’s accessed. Let’s again consider this the contents of a file called “app.py”:
from flask import Flask
app = Flask(__name__)
counter = 0
@app.route('/')
def count():
global counter
counter += 1
return f"Visit count: {counter}"
if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000)
This service maintains state within the counter variable. However, if the container restarts, the counter resets to zero. To persist this state, external storage is required.
To persist data, we can mount a Docker volume. First, create a basic Dockerfile:
FROM python:3.9
WORKDIR /app
COPY app.py .
RUN pip install flask
CMD ["python", "app.py"]
Finally, run the container with a persistent volume:
docker build -t my-stateful-app . docker run -v $(pwd)/data:/app/data -p 5000:5000 my-stateful-app
This setup allows the application to retain data even if the container is restarted. You should see “Visit count“ continue to increment when visiting or refreshing http://127.0.0.1:5000 in your browser.
When to use stateful vs. stateless containers
The table below summarizes the strengths and weaknesses of the main features of stateless and stateful containers. By leveraging the right approach for the right workload, teams can optimize performance and reliability in containerized environments.
| Feature | Stateless | Stateful |
|---|---|---|
| Persistence | No | Yes |
| Scalability | High | Lower (due to state dependencies) |
| Restart impact | No effect | May cause loss of state if not handled properly |
| Use case | REST APIs, front-end apps, microservices | Databases, session-based apps, message queues |
