Stateful vs. Stateless – An Overview

The key difference between stateful and stateless applications is that stateless applications don’t “store” data whereas stateful applications require backing storage.

Stateful applications like the Cassandra, MongoDB and mySQL databases all require some type of persistent storage that will survive service restarts.

Keeping state is critical to running a stateful application whereas any data that flows via a stateless service is typically transitory and the state is stored only in a separate back-end service like a database. Any associated storage is typically ephemeral.

If the container restarts for instance, anything stored is lost. As organizations adopt containers, they tend to begin with stateless containers as they are more easily adapted to this new type of architecture and better separated from their monolithic application codebase, thus they are more amenable to independent scaling.

Containerization: In Summary

The containerization of applications has become widely popular in recent years as microservices and cloud computing have likewise exploded in popularity.

Many tech companies, from startups to large enterprise, are experimenting with containerization. Containers (also known as partitions, virtualization engines [VEs] or jails typically look like standard computers i.e. programs run inside them.

However, compared to a computer running on an ordinary operating system, programs running inside a container are only able to see the container’s contents and devices assigned to that specific container.

Resource management features are often set to limit the reach of one container’s activities on other containers. Multiple containers can be built on each operating system, and a section of the computer’s resources is allocated to each different container.

Each container can contain any number of computer programs, which many run at the same time or separately, and/or interact with one another.

 Uses for Containers

Containers are typically straightforward and quick to deploy and make effective use of system resources. Container technology, such as Docker Engine, provide standards based packaging and runtime management of an application’s underlying components.

Developers can achieve application portability and programmable image management using containers; operations benefits from being able to use standard runtime units of deployment and management. Increasing numbers of companies are investing in container technology.

Barriers to Widespread Adoption of Containers

There are three particular challenges to the widespread adoption of containers:

  1. It is difficult to overcome persistent application aware storage.
  2. Application lifecycle management must be maintained long after the first day of deployment.
  3. Multi-cloud and hybrid cloud support is a necessity

Types of Application

Stateless

  • Stateless applications have just one function or service, such as an IoT device.
  • They use web, print or CDN servers.
  • The server processes requests based only on information relayed with each request and doesn’t rely on information from earlier requests – this means that the server doesn’t need to hold onto state information between requests.
  • Different requests can be processed by different servers.
  • The fact that any service instance can retrieve al application state necessary to execute a behavior from elsewhere enables resiliency, elasticity, and the ability for any available service instance to execute any task at all.
  • Stateless applications are essentially containerized microservices apps.
  • Orchestration for stateless apps helps determine the best location to run the container from the point of view of resources, including maintaining high availability (failover).

Stateful

  • Stateful applications are typically databases;
  • They involve transactions such as home banking;
  • They use mail servers;
  • The server processes requests based on the information relayed with each request and information stored from earlier requests – this means that the server must access and hold onto state information generated during the processing of the earlier request;
  • The same server must be used to process all requests linked to the same state information, or the state information needs to be shared with all servers that need it;
  • Orchestration for stateful applications involves determining the best location to run the container collection from the point of view of the applications’ overall needs including storage, network and IO Path point of view;
  • Orchestration for stateful applications also manages high availability – moving containers and remounting volumes with no application or code changes.

Common Mistakes about Containers

  • Containers will only work in combination with stateless microservices-style applications.
  • You can’t containerize stateful applications.

We have to be mindful in talking about stateful and stateless applications as what may appear to fall in one category may not actually. This is mainly because stateless services have become very good at mirroring much of the behavior of stateful services without actually becoming them.

Statelessness is about a self-contained state and reference instead of depending on an external frame of reference.

The main difference between it and statefulness, as stated above, is based on where the state is stored. In a stateless system, we are interacting with a limited system.

In stateful computing, the state is stored by the client, which generates data of some kind to be used for future use by various systems i.e. “stateful” computing references a state.

 

Source: spotinst.com