Part of:Container storage 101: Implementation best practices
Consider these container-native storage features, vendors
Container-based applications have a major effect on storage. It's important to assess the benefits, functionalities and providers of container storage.
As container-based applications make their way into production, storage becomes an important consideration for IT operations. The need to store data for these apps has created a new type of storage in recent years called container-native storage.
Also known as cloud-native storage, container-native storage (CNS) is different from traditional storage because it needs to be application-centric, with self-service features for developers or application owners. CNS also needs to run inside containers and work with the Kubernetes container orchestration platform.
There are CNS products already, and there will likely be more. Here are a few considerations to keep in mind.
What is container-native storage?
Just as the popularization of VMs changed the game for storage, so, too, does the rise of container-based applications. Hypervisors with VMs virtualize the hardware stack; containers virtualize the operating system. Each container includes all resources needed to run a software application. That makes them more portable than VMs. Groups of containers -- called pods -- can move freely between Kubernetes clusters running on premises and in public clouds.
CNS is a form of software-defined storage (SDS) that runs inside a container cluster, creating a storage pool from drives inside each host. As a result, CNS can run anywhere on premises or in public clouds as data moves between data centers and cloud providers. This process is different from container storage interface (CSI) drivers that enable storage systems and traditional SDS products to make their storage capacity and features available in Kubernetes.
Traditional products with CSI -- known as container-ready storage -- do not enable the portability required by containers. CNS attaches to an application and stays with it through the app's development and deployment lifecycles, as it moves from on premises to public clouds and between public clouds. Traditional storage with CSI drivers does not do that.
How CNS compares to other storage
Like other types of SDS, container-native storage pools capacity and compute across standard hardware. A good way to think of CNS is like hyper-converged infrastructure (HCI) for containers. Like HCI, container-native storage combines storage, server and virtualization into a common platform. The key difference is that CNS runs inside containers and the Kubernetes orchestration platform manages it, while HCI runs as a VM and a hypervisor manages it.
A central SAN does not typically manage HCI nor container-native storage. Just as virtual administrators often provision and manage storage in HCI, DevOps teams usually manage container-native storage. Kubernetes integration enables developers to provision storage through tools they already know. But while developers and cloud admins may have responsibility for hands-on deployment, IT operations teams are responsible for governance of data stored on CNS and need to be familiar with these products.
Top CNS vendors
As is the case with most emerging storage trends, early CNS vendors are mainly startups. There are two notable exceptions: Red Hat OpenShift Data Foundation (ODF) and Pure Storage's Portworx. Red Hat ODF is part of Red Hat's OpenShift container platform and was called OpenShift Container Storage until March 2021. OpenShift is part of the IBM family following IBM's 2019 acquisition of Red Hat.
Portworx launched its software built specifically for container storage in 2016. Flash array vendor Pure acquired Portworx for $370 million in late 2020. Pure continues to sell Portworx software independent of its arrays; although, it is integrating in some areas, beginning with Portworx PX-Backup software on Pure's FlashBlade backup target.
A good way to think of container-native storage is like hyper-converged infrastructure for containers.
Other startups with storage software running inside containers include Diamanti, Ionir, MayaData, Robin.io and StorageOS.
Most major storage vendors support the CSI driver that enables their arrays to store data from container-based apps. But this will not be enough as these apps proliferate. The Pure-Portworx case is an example of how these products differ. Pure supports CSI for its FlashArray and FlashBlade systems that admins manage as traditional storage, but the vendor sells Portworx for DevOps storage.
Top CNS features to consider
CNS ties into Kubernetes through APIs. Developers can provision persistent storage volumes in the orchestration platform they know, rather than put in a request to a SAN administrator. CNS supports dynamic provisioning in Kubernetes, which enables storage provisioning on demand. Other key Kubernetes functions that CNS supports include persistent volumes, persistent volume claims and storage classes.
By integrating into Kubernetes, CNS can scale with a Kubernetes cluster and simplify management compared to an external storage system. But just working with Kubernetes is not enough. When organizations use container-based apps in production, they need enterprise storage features. CNS must also provide storage services such as replication, compression, encryption, thin provisioning and data protection. Latency is another key consideration for container-native storage, as response time is critical when organizations speed the application development cycle.
Data protection is always an issue for production applications. Some CNS products have built-in data protection such as snapshots, while others rely on traditional backup software with added container support. There are also backup products built specifically for container data protection, such as Kasten (now part of Veeam) and Trilio.
