The State of State in Cloud Native Applications
In a recent survey conducted by The New Stack in partnership with streaming data platform provider Lightbend about how companies are handling state in containerized applications, 68% percent said that managing state is at least somewhat of an obstacle to moving more applications to microservices-based architectures.
So how are companies managing everything from application configuration to persistent storage in their cloud native applications? Let’s dive into the state of state in cloud native applications.
Stateless Beginnings
To understand where we are now when it comes to managing state in cloud native applications, it’s important to remember one key fact: Containers were designed to be stateless, and Kubernetes was designed to orchestrate stateless, ephemeral, immutable containers. At first, any state that these applications needed to have was just stored externally.
“Even if containers were meant to be stateless, containerized architectures still needed state,” explained Alex Chircop, CEO of StorageOS. This state just couldn’t be stored in the container or managed by the orchestrator.
As companies start seeing how Kubernetes and containerized architectures can increase application agility and speed, however, there’s been an increasing push to package more and more applications in containers, and to use Kubernetes to manage both compute and storage resources.
“Now everyone has started putting stateful applications into containers,” explains Chris Merz, principle technologist at NetApp. “Whether or not that is the right design, whether or not that was ever intended, it is what’s happening.”
A Tangled Landscape
“Applications can store state in a lot of different ways,” Chircop explains. Organizations have a plethora of options when it comes to how to manage state for the particular application needs — and it’s not a mature landscape, so in most cases, the companies that are successfully handling state in containers are early-adopters and still fairly early in the process of using containers to handle state.
The fact that there isn’t one “standard” way to handle state in a container-based architecture is a good thing, too. Each company and each application has a different set of requirements, and the best way to manage state in one situation might not be appropriate in another.
“There’s a decision matrix,” explains Michael Ferranti, vice president of marketing at Portworx. First, you decide whether to handle data on Kubernetes or outside Kubernetes. If your data is managed outside Kubernetes, it will connect to Kubernetes via an API, will be either a cloud provider data service or an on-prem database managed by a database admin. If you choose to use Kubernetes directly to manage storage, you’ll interact with Kubernetes via a container storage interface (CSI) to provision volumes.
Typically, the storage you want is some combination of objects stores, key-value stores and files. The best way to handle the data depends on the particular use-case — video, for example, would probably be best stored using an object-store.
Because it’s still relatively early days when it comes to managing state for cloud native applications, there’s no broad consensus or best practices checklist about how to handle state in any given situation.
“It is a new problem for developers who are development-centric,” Merz explains. “Traditionally, solving state at scale was an operational or database administrator thing. These are hardcore ops functions. Handling state at scale was like the biggest topic at KubeCon Barcelona.”
A Stateful Future
In practice, moving to a cloud native architecture is also a big leap, explains Jonas Bonér, chief technology officer of Lightbend. In his experience, many companies aren’t aware of the need to change the application architecture to be cloud native and continue handling things like state in essentially exactly the same way they used to on monoliths — at least until they learn the hard way not to do so.
Everyone interviewed for the article agrees that state is something that is possible to manage successfully in container-based, cloud native applications — and in fact must be handled successfully if companies are going to move their entire application suite to a cloud native, container-based architecture. In general, companies seem to be moving in the right direction — slowly abandoning practices that work in a monolith but not in a distributed system, for example.
But there are still some problems that are tricky. Visibility, or understanding what particular data is located where, is difficult in a distributed environment where the actual data placement is handled by software rather than a database admin. But it’s important: If one server is hacked, companies need to know what data was stored on that particular server for compliance reasons. Maintaining data security by default, at all times is also a primary concern as companies move more sensitive data to cloud native applications, Chircop says.
Particularly as more and more applications become data-centric and machine learning becomes increasingly important, it’s also important to store data close to the compute resources, Bonér says. On the other hand, Merz thinks focusing on locality is short-sighted, but acknowledges that the core goal — making it easier for data and compute to interact and reducing processing friction — is important. Merz thinks a very smart orchestration platform is a better way to solve the connection between compute and data in data-centric applications.
There are also still cultural challenges. Storage used to be an Ops problem, and developers often had no control over the storage provisioning process. In a cloud native, DevOps world developers have both the ability and the responsibility for storage, which involves making choices that will influence application performance.
Ultimately, Merz says, the types of challenges enterprise customers need to solve, when it comes to managing state, are the same as the challenges from 20 years ago. They need a way to manage persistence and to do so in a way that is scalable. Data needs to be kept secure, and it needs to be highly available and meet business requirements around compliance. But the ecosystem has changed, the architectures have changed, amounts of data have changed and the extent to which data is integrated into the application and the business has changed.
“I would say that the majority of enterprises are not yet running their stateful services in a cloud native manner,” Ferranti explains. “But they will be in the next 10 years. The agility gains of running your entire application stack in a cloud native manner are so great that as soon as the business requirements can be addressed, businesses of all sizes will start to do it.”
KubeCon + CloudNativeCon, Lightbend, NetApp and Portworx are sponsors of The New Stack.
Feature image by A. H. from Pixabay.
