Navigating the Lines Between Container-Native and Container-Ready Storage
In the world of containers and storage, it can be difficult to navigate the myriad options available. This guidance can help you sort out two options.
- By Kirby Wadsworth
- June 23, 2021
Containers changed the way applications were developed and delivered. This requires a complete rethinking of how we store, deliver, protect, and manage data. This is a once-in-a-generation opportunity to address fundamental data storage and management issues including data gravity, performance, cost and complexity of data protection, disaster recovery (DR), RPO, and granularity.
Container environments -- more specifically Kubernetes, which is now the de facto container platform -- see all resources as services. Therefore, a storage services layer is required, although perhaps it would be better to call this a data service layer because this services layer must provide far more resource capability than simply storing data.
There are two primary approaches to this new container data services layer: container-native and container-ready.
Given the mixed messaging and differing opinions in the market, the differences between the two can appear murky. However, even a high-level comparison belies critical distinctions. Let's take a look at what sets these two approaches apart and how to know which type of solution makes the most sense for your enterprise's needs.
Container-Native Versus Container-Ready/Container-Attached Storage
Container-ready and container-attached approaches use existing traditional storage -- typically external arrays -- attached to the Kubernetes environment using software shims. This is attractive because it allows an enterprise to reuse existing investments in storage and may make sense as an initial bridge to the container environment. It may be especially effective for those experimenting with containerization (or planning to do so at a smaller scale) or as an adjunct to traditional, monolithic IT environments.
In contrast, container-native storage (CNS) is built for the Kubernetes environment. CNS is a software-defined storage solution that itself runs in containers on a Kubernetes cluster.
Kubernetes is designed for container orchestration. Everything inside of Kubernetes is a resource, and every resource is managed and orchestrated by Kubernetes. As additional resources are required, Kubernetes spins up more storage capacity, connectivity services, and compute services. It copies and distributes application instances. If anything breaks, Kubernetes restarts somewhere else. As the orchestration layer, Kubernetes generally keeps things running smoothly. CNS is built to be orchestrated; container-ready or container-attached storage is not easily orchestrated.
Container-attached storage adds friction that limits the full benefits of Kubernetes' inherent agility, reduced operational complexity, and lower cost. Keeping with the Kubernetes seafaring theme, attaching traditional storage to Kubernetes environments is like throwing an anchor overboard. The reason you switched to Kubernetes in the first place is because you wanted unified, simple, self-orchestrated IT. The separate storage and data management required for container-attached approaches can't scale, can't adapt, and can't respond at the speed required for Kubernetes. It may work acceptably in a very small cluster of two or three nodes, but as soon as you start to scale, you'll realize the limitations.
Perhaps more important, traditional approaches separate primary and secondary data. Primary is live, present-time data. Secondary is protected data (backup or snapshots), copies of data as it existed at some previous point in time. This entire concept is upended in the Kubernetes world. The concept of secondary data in Kubernetes is reminiscent of Henry Ford's "faster horse" analogy ("If I had asked people what they wanted, they would have said faster horses."). In implementing containers, we are rethinking IT entirely from the ground up. It makes no sense to drag old notions of data protection (such as backup and snapshots) with us into this new world.
CNS Offers a New Approach
Kubernetes-native storage offers a unified data services layer that provides high-speed, agile primary storage -- live data as it exists in the present time -- just as easily and fluidly as it provides secondary storage (instantly accessible clones of live data as it existed at ANY previous point in time). The entire notion of data being here or there, current or previous, evaporates. The container-native storage layer offers instant access to data anywhere, and from any time. Kubernetes is free to orchestrate what is needed and when.
If this concept seems far-fetched or difficult to grasp, be consoled by imagining how difficult the automobile was to grasp for a late 19th century horse owner. Do not allow yourself to be confused or misdirected by those who would sell you faster horses. Faced with disruptive technology, legacy vendors have long resorted to a common playbook: give a nod to the innovation, pile on fear, uncertainty, and doubt to delay adoption, then promise to offer the innovation once it is fully tested and proven.
That model once successfully stymied innovation while protecting the revenue streams of established vendors. Thankfully, today's cloud-first, hack-everything DevOps approach thwarts that ruse, and container-native is now largely accepted as the way forward.
Agile Storage for the Enterprise
Enterprises need enterprise-level storage. In the world of containers and storage, it can be difficult to navigate the myriad options available. It can be hard to know what the best fit will be for your particular use case, which is why you need to be clear about your terms. Container-native and container-ready storage may sound similar, but they are worlds apart in terms of manageability. Kubernetes makes orchestrating changes across containers a breeze, so it's ideal for newer applications. It's a specific solution for a specific scenario that brings automation and agility right where they're needed most.
About the Author
Kirby Wadsworth is the chief marketing officer at ionir. In his career, Kirby has helped pioneer the cloud storage, continuous data protection, and file virtualization industries. Prior to ionir, Kirby served as CMO at Illusive, Bayshore, Mendix, Limelight Networks, and as vice president of global marketing at F5 Networks. Kirby earned an MBA from the Kellogg School at Northwestern University and a BS in Information Technology at Northeastern University. He can be reached on LinkedIn.