Is an application stateful or stateless? And what does that mean? This is a question that many decision-makers are trying to wrap their heads around as they consider bringing microservices into their organizations to deliver new services to their clients. Let's use an imperfect but useful analogy:

Remember Dory and Marlin in the classic “Finding Nemo” movie? Marlin, weighed down by a host of memories, is on a mission to find Nemo, his son. But he finds that he can’t do it without the help of the wacky Dory, who doesn’t remember much of anything. Every moment for Dory is a brand new transaction, usually uncomplicated with the details of what happened just before that. Naturally, this infuriates Marlin on many occasions. While his memory is essential to reaching the end goal of finding Nemo, it is Dory’s agility—primarily because the past doesn’t weigh her down—that enables her to act on the moment, without any fears or baggage, and get across the vast ocean to finally find Nemo. Although this isn’t the perfect analogy, it’s one way to start thinking through stateful vs. stateless microservices’ benefits and limitations. It's also an excellent way to start thinking about getting the two working together for your strategic advantage.

The bottom line as to whether an application is stateful or stateless comes down to answering two key questions:

1. For how long is the “state” (or condition) of interaction recorded?
2. How is the data about each interaction stored?

With those two questions in mind, it’s possible to give very basic answers to what is stateless or stateful:

• Within a stateless architecture, no memories of past transactions are kept after the transaction is finished. The app starts every transaction from scratch like it’s a first-time experience, every single time, kind of like Dory.
• A stateful architecture collects and stores data about previous transactions, and these memories can, and often do, impact future transactions, a lot like Marlin.

Developers have increasingly turned to build and deploying stateless applications because they boost agility, increase the speed between development and deployment, and maximize scalability. Stateless apps are also generally easier to manage than stateful applications, which can quickly become heavy with overhead memory requirements. Nevertheless, many companies require apps that manage a persistent “state,” which means they often rely on stateful applications. They require reliable data storage to protect against failures so that the application can hold on to a persistent, healthy “state of being” to serve their clients. It can be challenging to fit stateful applications into the new world of stateless microservices, but it isn’t impossible. With containerization strategies, more and more solutions for harnessing the power of both architectures are coming online.

Stateful or Stateless? Two Extremes with Benefits and Limitations

Let’s dig deeper into each “state” case and discuss the benefits, limitations, and intersections of stateless vs. stateful architecture. One of the fundamental dilemmas of cloud application design is that businesses usually run on stateful applications, but the cloud works best with stateless components. Some microservice definitions require stateless behavior, but still, others demand stateful behavior. The challenge is to find ways to harmonize these two definitions with the reality of outlying Transaction Processing Systems (TPS) that collect, store, and retrieve all of those transactions. This allows the cloud to truly and optimally support robust business activities with stateless microservices’ flexibility.

The Benefits of a Stateless Approach

Every transaction is brand new for a stateless application, even if this is the day’s millionth transaction. When a client makes a request from a stateless app, the incoming request contains all necessary information for the server to fulfill the request. The server does not record information from previous requests because the details are stored on the client-side. There are some important benefits to the stateless approach that are worth considering:

• Because every transaction is fresh as the moment it was born, this eliminates the need for large memory overheads. Although there may be one need for one database connection, it’s manageable, and server-side memory requirements are far lower.
• Different servers can process different requests because of this lack of overhead, making the system more elastic, agile, and resilient.
• As a follow-on benefit of this flexibility, stateless applications can be scaled horizontally to an amazing degree, enabling the app to grow as the number of users increases, straight into the millions.
• Companies can easily add or remove new instances of the application, on-demand, whenever necessary.
• Stateless applications can be more easily maintained and repaired when needed without knocking out the entire system.
• Session expiration issues are a thing of the past, making the system easier to manage; it’s sometimes difficult to find, test, and repair session expirations in a stateful system. Because stateless apps don’t use sessions, this simply isn’t an issue anymore.
• Stateless apps create a seamless, consistent experience on the user side, even in multiple instances. If one person links another person to the same resource, it appears the same to each user.

You already use stateless applications on a regular basis. When you use a search engine to pull up a query about a question you have, you’re using a stateless application. Even if you’re interrupted during the process, you can come straight back and ask the same question, or a different question, because all memory of the previous transaction is gone between takes. Cookies may be stored on the client-side, but on the app side, there’s no memory of the previous query.

Yet, even with all of these benefits, a stateless approach isn’t for every situation and can come with some particular challenges.

Drawbacks of the Stateless Approach

There are a great many applications that need to “maintain a state” using data that was collected earlier in order to know what to do during a subsequent transaction. In fact, many users expect to be able to pick up where they left off with particular applications. This is the case with many enterprise applications, as well as things most people use daily—like email or online banking, or even online shopping. Of course, this is where cookies often come in, storing memory data bits on the client-side. However, the cookie approach in stateless apps can be inefficient and cause more work for webmasters who need to maintain the cookies. This then makes the app a little less robust and a little harder to manage. So, for all its agility, stateless architectures do have their problems—and for all their inflexibility, stateful architectures can provide the necessary value that end users need and want.

Benefits of a Stateful Approach

Stateful apps require the use of servers and databases to process requests from users, hence a heavier reliance on overhead databases. This store, processed data is necessary to address because subsequent transactions depend on the context of previous transactions. Typically, the same server needs to maintain the data so that the proper state can be maintained and shared with any other servers that require that same data. Many users expect to be able to return to the same state that existed during an earlier session, and stateful applications make that possible. It creates value for the end-user, often in ways that stateless apps struggle to achieve.

Other cases in which you might need a stateful approach include when you have a group of tasks that have to be combined into one step with an asynchronous response that may come later or isn’t nailed down to a specific response time. You also need a stateful architecture if a group of tasks is part of one transaction, wherein the failure of one task requires a rollback of all tasks, which then requires a return to the original state. A significant amount of memory is required in order to do those things.

Drawbacks of the Stateful Approach

As explained before, the need for extensive memory in the form of databases and servers can make stateful application architectures slower, heavier, harder to manage, and difficult to scale horizontally. Managing the resource isolation pieces of a stateful workload requires reliable memory and storage, or client data can be lost, with disastrous results. It can also be a challenge to determine the best persistent storage types (e.g., distributed file systems or block devices). Part of the problem is that many stateful applications are legacy apps built-in yesteryear’s monolithic architecture. Challenges arise, naturally, when trying to adapt these systems to a more containerized microservices architecture that favors stateless application styles. These considerations make it hard for stateful applications to run with the same flexibility and agility as stateless applications. It takes a lot of hard work, it can be expensive, it requires a considerable amount of resources, and it can be a risky thing to do without proper planning.

Stateful or Stateless: What is More Suitable?

When it comes down to choosing between stateful or stateless architecture options for your application needs, it’s essential to consider what kind of app is being built, why it’s being built, and how it will be used. If the information that passes during transactions can be transitory, transmitted quickly, and temporarily on the spot, stateless is the smart choice. If the system needs to remember what happens between sessions, and the data entered during the first session may affect what happens during the next session, stateful is the way to go.

At the same time, even for a stateful enterprise application, scalability is an important, yet elusive quality. There must be a way for stateful applications to plan for backups in case rapid disaster recovery is needed. While this is almost always possible, the effort can be Herculean compared to the effort required to get even better results on a stateless microservice. Like Marlin and Dory learning to work together with their very different and particular ways of thinking, it takes some time to work out the challenges. It requires a re-thinking of how to solve the same problems in a different, more reliable, flexible way. There can even be a mix of these two approaches with the use of containers.

How Containers Work

Container architecture can provide a means for stateless applications to take on stateful qualities while giving stateful applications more flexibility to operate like stateless applications. There are now ways to divide legacy applications into distributed objects or smaller units of software. This is exactly what is meant by containers. These smaller units can run from their own containers and be modularly connected to other containers’ efforts. By dividing applications into containers like this, it offers the ability to house them on different physical or virtual machines, inside the cloud or outside of the cloud. Containers give enterprises more flexibility and provide new ways to manage workloads while also making more fault-tolerant systems.

Benefits of Using Container Architecture

Containerization reduces complexity and inflexibility because container abstractions aren’t dependent on the application infrastructure. This eliminates the need for a complex and heavy native interface to deal with platform services. Containers also leverage automation to maximize portability by removing manual scripting needs.

Containers also improve security and app governance, external to the containers. Because security and governance services are platform-specific and not application-specific, placing these services outside of the container reduces complexity.

Using containers enhances distributed computing capabilities significantly. If a stateful application can be divided into separate containers, it can be placed into different domains, making it more portable. Improved portability means apps can execute on a number of different cloud platforms. This empowers engineers to pick and choose the platforms that they run on, based on the best performance, the most efficiency, and the best price.

Containers can optimize policy-based automation services. Developers need to add an automation layer that is located the best platform upon which to execute. At that point, the container can auto-migrate to the ideal platform. This also makes it possible to automate dealing with configuration changes as they come.

Containers Can Bring out the Best in Stateless and Stateful Microservice Apps

In the real world, there are few truly stateless applications. There are many stateful applications that take advantage of stateless concepts using containers—just like Marlin and Dory crossing the ocean using their very different ways of thinking to accomplish the end goal, it’s important to find the optimal approach, which is often a blend of the two.

It’s essential to plan ahead and ask what will work best in your situation. What will best accomplish your goals? If the service needs to be stateful, it can be partitioned into separate containers. Although stateless services scale better, which makes them the best choice when fast, flexible scaling is required, not all processes can reasonably be made stateless. Some apps must rely on past memories, making them more expensive to maintain, more difficult to scale, and more open to potential bugs. Again, containers can be a way of approaching stateful apps to make them act in a more stateless, flexible manner.

What microservices architecture issues are you currently trying to solve? Are you trying to make a stateful enterprise app more stateless? Are you curious about how containers could make your apps more flexible and agile? Your business isn’t like any other, so it’s imperative to get a customized look into how microservices architecture choices can optimize your business processes. Let’s talk about how these concepts can help you reach your strategic objectives now.

‍