Programmable storage is a storage architecture where capacity, performance, data placement, and protection policies are controlled through APIs, code, and declarative configuration — rather than static manual provisioning. A programmable storage system can receive instructions at runtime: set an IOPS limit on this volume, move cold data to a cheaper tier, take a snapshot every six hours, encrypt this namespace. These behaviors are codified and enforced by the storage platform itself, not bolted on by scripts around it.
The term is most meaningful when contrasted with traditional storage: a SAN or NAS appliance where an administrator manually provisions LUNs, sets fixed RAID configurations, and adjusts performance tiers through a vendor console. Programmable storage replaces that model with a platform whose entire behavior surface is accessible and automatable through code. In Kubernetes environments, this is primarily expressed through CSI StorageClass parameters, VolumeSnapshot APIs, and storage operator configurations.
What Makes Storage Programmable
Not every storage system with an API is programmable in a meaningful sense. Programmable storage implies that the API controls actual runtime behavior — not just provisioning metadata. The capabilities that define a genuinely programmable storage platform:
Dynamic QoS: IOPS and throughput limits that can be set, changed, or removed per volume at runtime without remounting or downtime. This is the difference between a static tier (“gold/silver/bronze”) and a fine-grained performance contract enforced by the storage controller.
Policy-based data placement: Rules that determine where data lives — which storage tier, which node, which availability zone — based on access patterns, age, or explicit policy. Hot data stays on NVMe; cold data migrates to cheaper media automatically.
Automated data protection: Snapshot schedules, retention policies, and replication targets expressed as configuration rather than cron jobs. The storage platform enforces the policy, not an external scheduler.
API-addressable at runtime: Every behavior listed above must be changeable through an API call without service interruption. Static configurations that require unmount/remount cycles or admin console access do not qualify.
🚀 Want programmable storage for your Kubernetes platform? simplyblock delivers per-volume QoS, CSI-native provisioning, and snapshot automation — all controlled through the Kubernetes API or REST, with no storage console required. 👉 Explore Multi-Tenant QoS and Storage Control →
Programmable Storage in Kubernetes
Kubernetes provides the interface layer for programmable storage through several API objects:
StorageClass: Defines provisioning parameters for volumes. In a programmable storage platform, StorageClass parameters extend to performance characteristics: iops-limit, bandwidth-limit, replication-factor, encryption, tier. These become runtime configuration, not just labels.
VolumeSnapshot and VolumeSnapshotClass: First-class Kubernetes objects for triggering and scheduling snapshots. A programmable storage platform exposes snapshot creation, listing, and restoration entirely through these Kubernetes APIs.
CSI StorageCapacity: Allows the storage platform to publish real-time capacity availability to the Kubernetes scheduler, enabling smarter pod placement decisions.
Storage operators: Custom operators extend programmable control further — automatically adjusting QoS based on observed workload metrics, triggering tiering decisions, or enforcing storage SLAs defined in custom resources.
Programmable Storage vs. Traditional Storage
| Capability | Traditional Storage | Programmable Storage |
|---|---|---|
| Provisioning | Admin creates LUN manually | API call / PVC manifest |
| Performance tiers | Fixed at creation (gold/silver/bronze) | Per-volume IOPS/BW adjustable at runtime |
| Snapshots | Manual or scheduled via vendor console | VolumeSnapshot API, policy-driven |
| Data tiering | Manual migration or fixed tier assignment | Policy-based, automated, transparent |
| Multi-tenancy | VLAN / LUN masking per tenant | Per-namespace QoS + RBAC-enforced isolation |
| Observability | Vendor console metrics | API-accessible metrics, Prometheus export |
| Change mechanism | Admin console / CLI | Git PR → CI → API call |
simplyblock as Programmable Storage
simplyblock is designed specifically as a programmable storage platform for Kubernetes. The full storage behavior surface — from provisioning to per-volume performance limits to snapshot scheduling — is accessible through the Kubernetes API and simplyblock’s REST API, with no storage admin console required for routine operations.
Specific programmable capabilities:
- Per-volume QoS at runtime: IOPS and throughput limits set as StorageClass parameters or updated via API. A tenant can be throttled or accelerated without remounting their volume.
- CSI-native provisioning: StorageClass configuration drives volume creation, size, replication factor, and encryption. PVC creation triggers the full provisioning lifecycle via API.
- VolumeSnapshot integration: Snapshots are Kubernetes objects, triggerable from CI/CD pipelines, GitOps tools, or scheduled operators. Restores are also API-driven.
- NVMe/TCP transport: The transport layer is software-defined — volumes can be attached to any node without manual zoning or LUN masking. Attachment is an API operation.
- Erasure coding configuration: Redundancy policy (replication factor, erasure coding parameters) is set per volume via StorageClass, not hardcoded per storage tier.
Teams building internal developer platforms (IDPs) or multi-tenant SaaS infrastructure use simplyblock’s programmable surface to offer storage as a self-service resource to their developers — provisioned, configured, and managed entirely through the same Kubernetes-native workflows used for compute.
Relationship to API-Driven Infrastructure
Programmable storage is the storage-specific implementation of API-driven infrastructure. API-driven infrastructure is the broader model; programmable storage is what it looks like when the storage layer fully adopts that model — where storage behavior is not just provisioned through an API, but continuously controlled, observed, and adjusted through APIs and policies at runtime.
The difference matters: a storage system that supports API-based volume creation but requires a vendor console to change performance tiers is API-driven for provisioning but not programmable for operations.
Related Terms
API-Driven Infrastructure Thin Provisioning NVMe over TCP Kubernetes Persistent Volumes
Questions and Answers
What is the difference between programmable storage and software-defined storage?
Software-defined storage (SDS) refers to decoupling the storage control plane from hardware — running storage logic in software on commodity servers. Programmable storage goes further: it requires that the storage behavior surface be accessible and changeable through APIs and policies at runtime. An SDS platform that requires static configuration at deploy time is not programmable in a meaningful operational sense.
How does programmable storage benefit multi-tenant Kubernetes platforms?
In a multi-tenant cluster, different workloads (and different customers) share the same storage infrastructure. Without per-volume QoS, a noisy tenant can degrade storage performance for everyone. Programmable storage lets platform engineers enforce per-namespace or per-volume IOPS and bandwidth limits through API calls — giving each tenant a predictable performance contract without dedicated hardware.
What Kubernetes objects are used to interact with programmable storage?
StorageClass defines provisioning parameters including performance configuration. PersistentVolumeClaim triggers provisioning. VolumeSnapshot and VolumeSnapshotContent manage snapshots. CSI-specific custom resources (depending on the driver) extend control further. For storage platforms with operators, additional CRDs may expose tiering policies, QoS rules, and pool configuration.
Can traditional SAN storage be made programmable?
Partially. Modern SAN platforms expose REST APIs for provisioning, and some support QoS tiers. However, if changing a performance policy requires a reboot, remount, or out-of-band admin action, the platform is not truly programmable at the operational level. The gap is usually in runtime behavior control — not just provisioning automation.
How is QoS enforced in programmable storage?
In a platform like simplyblock, QoS is enforced at the storage controller level. When a volume is provisioned with an IOPS limit, the storage controller tracks I/O against that limit and throttles requests that exceed it — at the storage layer, before they hit disk. This is more reliable than application-level or OS-level rate limiting because it is enforced regardless of which node or pod is generating the I/O.
What observability should a programmable storage platform provide?
At minimum: per-volume IOPS, throughput, and latency metrics exposed via Prometheus-compatible endpoints, CSI-level events surfaced as Kubernetes events, capacity utilization per pool and per volume, and snapshot/backup status. A fully programmable platform also exposes API audit logs so platform engineers can track who changed what storage configuration and when.