Software-Defined Infrastructure

Software-Defined Infrastructure#

“Software-defined” means the control plane that configures a resource is decoupled from the data plane that carries the traffic / data. Operators describe what they want in software; the infrastructure conforms.

Software-defined infrastructure (SDI) is the architectural shift that made cloud computing possible. Networks, storage, and, ultimately, whole datacenters reduced to APIs.

The Control Plane / Data Plane Split#

Traditional networking gear had policy and forwarding tightly coupled inside each box. Software-defined approaches separate them:

  • Control plane, a programmable controller computes routes, policies, and configuration. Lives apart from the forwarding hardware.

  • Data plane, forwards packets / writes blocks / serves files based on rules pushed from the control plane.

The split lets you replace the policy engine without touching the boxes carrying the traffic, and lets a single control plane manage a fleet of devices uniformly.

SDN, Software-Defined Networking#

The original software-defined idea, born from OpenFlow and Open vSwitch. A programmable controller computes routes and policies; dumb forwarders apply them. Modern Kubernetes clusters consume SDN through CNIs like Cilium, Calico, Flannel, and Weave; eBPF-based options are the 2026 favorite.

The original “software-defined”, networking with a programmable controller and dumb forwarders.

  • OpenFlow, the original SDN protocol; defines how a controller programs a forwarding switch.

  • Open vSwitch (OVS), programmable software switch; the data plane in many SDN deployments.

  • OVN (Open Virtual Network), logical-network layer on top of OVS.

  • Calico, Cilium, Flannel, Weave, Kubernetes CNIs implementing SDN at the cluster level.

  • Tungsten Fabric (formerly OpenContrail), Cisco ACI, VMware NSX, enterprise SDN platforms.

Concrete capabilities:

  • VLAN / VXLAN / Geneve overlays.

  • Per-pod / per-VM virtual NICs without re-cabling.

  • Network segmentation enforced in software.

  • Flow steering for service mesh, DPI, observability.

  • Multi-tenant isolation in the same physical fabric.

In Kubernetes, eBPF-based networking (Cilium) is the modern favorite; programmable kernel hooks deliver near-native performance with rich observability and policy.

SDS, Software-Defined Storage#

The storage analog of SDN. Ceph leads in open self-hosted clouds; Longhorn and OpenEBS bring container-attached storage to Kubernetes; MinIO covers S3-compatible object storage; commercial options like Portworx and Pure Storage serve enterprise estates. Cloud storage is itself SDS.

The storage analog. Decouple the storage controller (which decides where data lives, replicates, snapshots) from the underlying disks.

  • Ceph, open-source distributed object/block/file storage; the reference implementation. Powers most large self-hosted clouds.

  • GlusterFS, distributed filesystem; less common in 2026.

  • Longhorn, Kubernetes-native block storage from Rancher.

  • OpenEBS, Kubernetes container-attached storage.

  • MinIO, S3-compatible object storage you can host anywhere.

  • Rook, Kubernetes operator that runs Ceph.

  • Portworx, Pure Storage, Datrium, Nutanix – commercial.

Cloud equivalents (the entire storage offering of a hyperscaler is software-defined behind opaque APIs):

  • AWS EBS / S3 / EFS / FSx.

  • GCP Persistent Disk / GCS / Filestore.

  • Azure Disk / Blob / Files / NetApp.

Properties of SDS:

  • Replicate / erasure-code across many disks transparently.

  • Add capacity by adding nodes; rebalance automatically.

  • Snapshot, clone, encrypt, dedupe in software.

  • Expose multiple personalities (object / block / file) over the same pool.

SDDC, Software-Defined Datacenter#

The whole datacenter as software:

  • Compute, virtualized; declarative provisioning (IaC).

  • Network, SDN.

  • Storage, SDS.

  • Security, microsegmentation, software-defined perimeter.

VMware popularized “SDDC” with vSphere + NSX + vSAN; the cloud providers built theirs from the ground up. The pattern is universal: declare what you want, the system provides it.

SD-WAN#

Software-defined wide-area networking. Routes between branch offices chosen dynamically by a controller across multiple underlay links (MPLS, broadband, LTE, Starlink) based on application policy.

  • Cisco SD-WAN (Viptela), Versa Networks, Silver Peak (HPE Aruba), Fortinet Secure SD-WAN, VMware VeloCloud.

  • Common on enterprise edge networks; less common in cloud-only shops.

Software-Defined Perimeter / Zero Trust Networking#

The model replacing classic VPNs in 2026. Trust shifts from network location to authenticated identity; software policy decides who reaches what. Tailscale and NetBird run WireGuard meshes; Cloudflare Access and Zscaler proxy identity-aware traffic; SPIFFE standardizes workload identity.

Replace network-location-based trust with identity-based access:

  • No flat trusted network; every connection authenticated.

  • Software policy decides who can reach what, regardless of where they are.

  • Enforced by an identity-aware proxy or per-host agent.

Tools:

  • Tailscale / NetBird, WireGuard mesh with managed control plane.

  • Cloudflare Access / Zscaler Private Access, identity-aware proxy.

  • HashiCorp Boundary, session brokering with identity.

  • Google BeyondCorp, the seminal model.

  • SPIFFE / SPIRE, workload identity standard.

The model that replaces VPNs in many shops in 2026.

Why It Matters Operationally#

Software-defined infrastructure has three big ops consequences:

  1. Everything is an API call. Provisioning, security policy, networking, and storage all reach the same control plane, all manageable by code.

  2. Drift is detectable. A controller that knows the desired state can report and correct deviations.

  3. Multi-tenant isolation in software. No need for separate physical networks per environment; logical separation is enough when the control plane is solid.

The downside: the control plane is now a critical dependency. SDN / SDS controllers must be highly available; their failure modes affect everything.

Where SDI Sits in the Evolution#

  • Traditional ops needed dedicated network engineers and storage admins.

  • Virtualization made compute software-defined.

  • SDN / SDS made the rest software-defined.

  • Cloud and Kubernetes consume software-defined infrastructure as a given.

  • Platform engineering wraps it in higher-level abstractions for developers.

The whole DevOps evolution depends on this split having happened. Without programmable infrastructure, “infrastructure as code” is just a wiki of commands.

Pitfalls#

The traps an SDI program meets. The control plane is a distributed system with its own failure modes; mixing software- and hardware-defined at one layer leaks inconsistencies; vendor SDN/SDS suites lock in via proprietary data planes; software-packet processing has performance limits eBPF only mostly closes.

  • Underestimating the control plane, it’s a distributed system with its own failure modes.

  • Mixing software-defined with hardware-defined at one layer – the inconsistency leaks.

  • Vendor lock-in, enterprise SDN / SDS suites have proprietary data planes that are painful to leave.

  • Performance assumptions, packet processing in software is slower than ASICs; eBPF mostly closes the gap, but verify.

See Also#

  • Networking, the network components that SDN configures.

  • Storage, the storage tiers SDS provides.

  • Cloud, the consumer of all the above.

  • Security, zero-trust and identity-based access.

Contents