How the Container Storage Interface (CSI) Boosts Cloud Native DevOps
Dell Technologies sponsored this podcast.
The intrinsic battle in modern digital organizations lies between speed and security. As software development velocity seems to endlessly increase, IT organizations are looking at what tools are available to them to provide guardrails and governance — without slowing things down.
Infrastructure-as-Code is arising as the solution and the common language between the two sides. As developers demand cloud-like consumption and automation continues to be the secret to successful DevOps organizations, tooling and specification arises as the welcome solution.
At KubeCon + CloudNativeCon, The New Stack founder and publisher Alex Williams sat down with Dell EMC’s Audrius Stripeikis, product manager responsible for container storage and interface drivers, and Parasar Kodati, portfolio marketing consultant, to talk about one of the newest fixes for one of the oldest bottlenecks. They dive into the Container Storage Interface (CSI) specification and its interface drivers, and how they are responding to the needs of the enterprise DevOps, Kubernetes-backed space.
The Battle Between Speed and Security
The CSI aims to give final control to the IT admin, while still allowing developers to provision their own storage directly instead of waiting for someone to provision it for them.
Stripeikis explained that a container storage interface is basically a specification that defines how storage areas can be connected to Kubernetes clusters.
“Initially when [Kubernetes orchestration] started, everybody came up with their own definition on how storage areas will connect to Kubernetes. And that made life very difficult for us vendors to develop those drivers that connect to various container orchestrators,” he said.
So the Kubernetes community tried a spec called FlexVolume, but it was deemed an inefficient, even cumbersome and complicated solution. Drivers could only be updated during Kubernetes releases.
So the Kubernetes community decided to develop a spec that allowed vendors like Dell EMC to deliver new drivers, which act as the realization of the spec in the form of software.
With CSI, the storage admin allocates the storage for the developer consumer to use. Then the consumer will use that allocation in the form of persistent volumes.
CSI Lets Storage Admins Set Guardrails
Stripeikis warned that with these interface drivers, “Storage admins aren’t used to this paradigm. They feel like they are now losing control, which is not the case.”
He says CSI gives these admins storage class which allows them to define which storage area can be used, how much capacity will be allocated within that storage area, and who will have access to it. It enables admins to set guardrails and quotas, like you can only have so many branches at a time consuming at a specific volume.
If a developer’s build goes past these quota rules, the deployment will be stopped.
CSI is intended to be applied to CI/CD pipelines. Kodati explained that whatever storage class is being defined is automatically provisioned for their application or microservice.
It all comes down to “how do you educate your IT organization which has traditionally been responsible to keep the lights on to help developers move at the speed they want to by kind of getting into the mindset of automation and provisioning infrastructure as code?” Kodati said.
This is part of the larger trend toward embracing infrastructure that, as Kodati said, is “baked in” to the CI/CD pipeline that allows for developer independence and policy-based provisioning, configuration management and an automated handing off of processes.
