Enabling Successful Stateful Kubernetes Deployments
Due to their portable nature, containers were originally intended to be stateless. But over time, developers have begun to utilize containers for stateful scenarios as well, combining the speed of containers with the flexibility and storage capabilities of statefulness. Simultaneously, Kubernetes as an orchestration platform has soared in use—Gartner now estimates that 85% of all deployments will use Kubernetes in the next four years. Now, some teams are considering how to best navigate stateful deployments on Kubernetes.
However, when the industry discusses containers, it’s usually still referring to stateless workloads; in other words, short-term workloads that can be understood in isolation. Stateful processes, or workflows that involve more context and history to function, are often pushed aside in the discussion. The reality is that most workloads will carry an inevitable degree of state, so how do we build great stateful architectures in environments initially designed for isolation? What are the barriers to stateful Kubernetes adoption?
I recently met with Michael Greenberg, head of product at Statehub, to discuss the challenges of designing stateful container-based cloud-native architecture. According to Greenberg, the top barriers to stateful Kubernetes adoption include cloud vendor lock-in and a lack of data ownership. Thus, IT teams must consider more agnostic infrastructure and increased control over data and storage to enable successfully stateful container ecosystems.
The Difference Between Stateless and Stateful
Stateless applications are transitory; they don’t use persistent volumes or rely on external dependencies and they have everything they need to function independently. Stateful applications, on the other hand, rely on more context and history to function. These apps typically connect with a data store or hold a memory of preceding events.
Both stateless and stateful applications have their place in modern software development. Yet, whether we like to admit it or not, “the majority of applications we use day to day are stateful,” acknowledges Red Hat.
So, what do we mean when we discuss stateless versus stateful architecture with containers in Kubernetes? Greenberg admits he has a bit of a cynical answer to this question. “People who say their applications are stateless are pretending,” he says. “In most businesses, applications rely on data; they process it and they store it somewhere. Show me a company without a huge database full of terabytes of data.”
It’s rare to have a genuine, 100%-stateless system. In reality, IT usually offloads state to a third-party data service and business data remains persistent, explains Greenberg. Can you really call an application “stateless” if it hooks into a managed database running outside of the K8s cluster? Perhaps not.
Stateful Workloads in Kubernetes
Initially, Kubernetes lacked the proper facilities to handle stateful workloads correctly, explains Greenberg. He credits this to the cloud phenomenon “making us a bit dumb.” For example, AWS’s RDS made it easy to instantly set up an operating system, configuration and install software. But that introduction was years ago before Kubernetes was on the scene. The reliance on cloud vendors also resulted in pushback from the open standards community, he explains.
Now, K8s can support persistent volumes. “The idea is that you can have your own cloud that is not tied to a specific cloud vendor or infrastructure,” says Greenberg. In this world, you can tie in all your workloads to perform business functions—infrastructure is more agnostic. “More and more people are trying to take a purist approach.”
Freeing organizations from cloud vendor reliances could help alleviate some frustrations, making data more free and transportable. However, there are quite a few roadblocks in the way of a genuinely agnostic cloud-native revolution. It would require a complete redefinition of compute infrastructure and data infrastructure.
Complexity of Stateful Kubernetes Deployments
There are a few hurdles associated with leveraging stateful deployments in Kubernetes. One big roadblock is figuring out the storage aspect. Storage requires system administration that is unrelated to the application itself. “People just don’t like storage—they don’t want to deal with it,” says Greenberg. The problem is compounded as fewer young developers learn storage skills. DevOps teams are likely already stretched thin, trying to offload as much as possible which makes it challenging to address.
Another critical hurdle in stateful Kubernetes development is cloud vendor lock-in, describes Greenberg. The cost of cloud migration is high, and the lack of unifying standards between cloud vendors makes it difficult to copy snapshots of volumes. There is a huge downside to being locked into a specific vendor and a geographic location, he adds. This is making open standards and technologies that don’t bind you to a particular vendor look more attractive.
We are starting to see a shift lately, with continued investment around cloud-native open source Kubernetes tooling. This is helping deliver more mobility and business continuity, says Greenberg. “You should be using tools that allow you to retain ownership of your data,” he adds.
Tips to Enable a Great Stateful K8s System
Being able to design stateful apps in Kubernetes is a relatively new phenomenon. Greenberg notes the growing prevalence of stateful Kubernetes, which could bring mobility and improved business continuity. Yet, the challenge will be to make stateful applications as transportable as other applications.
Barriers to stateful Kubernetes could hinder growth if not addressed. And, according to Greenberg, many of these roadblocks boil down to the control of data. “Everything is data—you have to store it somewhere,” he says. “The question is who has the ability to control you through the ownership of data.”
When you do take ownership of that data, you reap the following benefits:
- Testing: Increased control over copy management, allowing you to spin up environments for testing or business intelligence without incurring fees.
- Disaster recovery: More robust business continuity and disaster recovery options. Helps distance from cloud failures.
- Application mobility: This is naturally granted with more data ownership. “The biggest obstacle to application mobility is data immobility,” he says.
Managed databases and data services have their niche and won’t be going away any time soon. However, Greenberg sees more and more businesses starting to leverage platforms that allow more flexibility on an infrastructure level. In the future, he predicts we will see more organizations shifting toward taking control of databases instead of going down the managed route.
In addition to solving the storage component, to enable successful stateful Kubernetes, Greenberg recommends staying apprised of developments in the tooling space, as the landscape is progressing extremely rapidly. “A lot of people are putting effort into making stateful workloads more usable, robust, reliable; this is where the industry is going.”