3 Reasons the Container Storage Interface Is a Big Deal – InApps 2022

At {code}, we’ve been writing about the benefits that cloud-native patterns and container technology gives us all, as well as the challenges that we (as technologists, users, and industry leaders) need to address. In part, these articles serve as background for the announcements we have been making about standardizing to the Container Storage Interface (CSI), into which {code} has invested heavily.

By now, I think it’s clear why we need such a thing. Containers are enabling us to solve some really hard problems by dynamically managing applications abstracted from the resources they consume. The people, communities and organizations in the container ecosystem are working earnestly to create ever-more-powerful tools that interoperate to aid in that endeavor. And yet, when it comes to managing storage, we all run into the brick wall of, “everyone does it a different way.” Innovation is blocked and we never stop focusing on the basics.

With previous competing, innovative and rapidly-evolving technologies, the computer industry has learned that it’s a good idea to create standard interfaces, which serve as ground rules and minimizes user confusion. Without them, the path leads to complexity and fragmentation. Setting standards is like making a blueprint for a home renovation. By recording where a power outlet should be placed, the resident can know where to plug in the hardware — and make his own decision about what gizmo to install without worrying about how to power it or what limitations it may have.

CSI is a community-driven initiative led by the container orchestrators — Mesos, Kubernetes, Cloud Foundry and Docker — to define an interface that satisfies the storage needs of applications they manage. We all want smarter, more empowered applications enabled by containers.

I think CSI is important for three primary reasons:

1: CSI Offers a KISS and Community Approach

It isn’t as though others have not tried to universally integrate with storage previously. In some ways, they have offered more detail and functionality. However, earlier projects ended up more opinionated, broadly focused, and a burden to complete, if not implement. It was more difficult to get participants on board to even collaborate because there were so many decisions.. cough.. distractions.

So CSI takes the simplest approach: Capture how people use storage with containers today, but in an interface specification and as a pluggable code. Simplicity — the “keep it simple, stupid!” (KISS) approach — makes CSI first focused on the basics. The result — we hope! — is that the CSI will deliver better integration between container orchestrators and storage platforms that we can iterate on to improve, but rely on, to build better applications.

We have been building on CSI ourselves, releasing of a couple of key drivers: a ScaleIO driver for bare metal and a vSphere driver for virtualized cloud native environments.

2: CSI Provides a Predictable and Functional Interface for More Use Cases

The challenge in building any kind of interface is that it needs an easy-to-grasp user experience for developers and data center professionals, yet supports the deep feature sets of the applications that use it.

For example, Docker created a spec for its volume driver, but (to be gentle) it has some room for improvement. Its interface isn’t capable of handling situations gracefully when failures occur. If one component goes down, it can be difficult to re-sync to the right state.

I don’t mean to point fingers at Docker directly. We have a lot of these interfaces being defined, and none are perfect shining examples of user interface wonderfulness.

The CSI team is doing its best to learn from others’ imperfections. We want to expand the storage-related design patterns to work with more applications.

For example, we currently only bring in volumes that have file systems. When an application needs to store data, it has to grab a volume with a filesystem on it. With CSI we have raw block device support — something fundamental but not available today. Users can define the volumes without file systems. This enables new applications to run from containers which excel when paired with logical block addressed storage. Practically, apps that require high performance or shared devices among hosts may prefer this.

3. CSI is Driven by User Needs and Community, not a Storage Company

The CSI top-down design is coming from container orchestrators and the community. With the aim of simplicity, the team members aren’t reaching to the moon; rather, it’s an old-school approach of “do a little, but do it very, very well.” To me, this is probably the single most important aspect of CSI.

Everyone working on CSI is trying to make the spec relevant to the people who’ll use it. The team is not making decisions based on what a storage company can offer and what they want to sell you.

Instead, the questions that the CSI team considers include: “How can this problem get solved? Who’s the right person to solve it? What’s the ideal solution look like? How would that be implemented?”

How Will This Change Your Life?

If there’s anything a techie hates, it is being forced into choosing one tool because it’s the only one with reasonable connectivity or that interfaces with a tool your company uses. If CSI is a success, it will ensure that organizations won’t need to choose container platforms simply because of support for specific storage or cloud providers. It will increase the quality of interaction for all platforms. Success here brings a once complicated task to the masses and further solidifies cloud-native patterns of dynamic management and portability for storage. It will make everyone’s job just a bit easier.

{code} and Cloud Native Computing Foundation are sponsors of InApps.

Feature image via Pixabay.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.