Acronym fans rejoice! Just weeks after releasing a wonderfully acronym-free reference configuration with Hewlett Packard Enterprise (HPE), Portworx unveiled an avian-based tag for a new open source stateful storage project.

The Storage Orchestrator Runtime for Kubernetes, more fluidly known as STORK, uses the extensibility of Kubernetes to support stateful applications. This allows DevOps teams to run stateful applications – think databases, queues, and key-value stores – on Kubernetes.

The product uses a schedule extender to offer storage health monitoring for stateful applications on Kubernetes. It uses a plugin interface to communicate with storage drivers that allows it to work with any Kubernetes storage driver.

A Kubernetes scheduler extender can impact container pod scheduling based on the location of the content that a pod needs to function. This allows pods to remain scheduled to run on hosts that already have a copy of the data even if there is a failure in the scheduling.

Portworx CTO Gou Rao said the company developed STORK because it was seeing customers trying different ways to address issues when a storage drive fails — especially on day two or day three of deployments.

“We saw customers trying different ways, with a lot of effort, to address challenges like hyperconvergence, relocation of containers when a drive fails, and disaster recovery of volumes on a per-container basis,” Rao said. “We wanted to ease that manual orchestration burden that platform operators were experiencing.”

Containers were initially viewed as a perfect match for stateless applications that did not require stored data to operate or support a running application. These were typically web services that acted as a go-between for any storage needs. Any actual storage within a stateless container was ephemeral, and thus a restart flushed out stored data.

However, as container use cases have evolved, stateful models have matured. These allow containers to maintain stored data even if a container is restarted and can support more developed applications. This model has become critical for enterprises that are running more advanced applications within containers.

Portworx is targeting storage technology partners in the container and cloud-native ecosystem with the platform. Rao said it was looking to attract three to four storage technology partners and around 10 customers to more fully flesh out the project.

Rao said the company was also looking to migrate the platform under the guidance of the Cloud Native Computing Foundation (CNCF). He noted that will likely take increased maturity and adoption of at least 50 “key accounts” before having a chance to move to a body like CNCF.

CNCF has become the de facto home for numerous open source container projects. It currently houses 15 official projects, including Kubernetes, Prometheus for monitoring, and Open Tracing for application flow monitoring.

CNCF earlier this week added Rook, which was the organization’s first storage-based project. Rook brings file, block, and object storage systems into the Kubernetes cluster as opposed to relying on an external storage source. This allows the systems to run alongside other applications that use their data, and it makes the cloud-native cluster portable across public and private clouds.

Portworx last month release a reference configuration with HPE that uses Kubernetes to offer enterprises a quick way to deploy and manage stateful container workloads. The reference configuration combines HPE’s Synergy composable system as the basis for running Portworx’s PX-Enterprise storage platform using Kubernetes as the container orchestrator and scheduler.

Rao said STORK is not directly related to the HPE announcement, but that HPE was one of the partners it planned to work with on the new project.