The Three Faces of Programmability in Software-Defined Infrastructure

#SDN #devops #API Your toaster is configurable, not programmable.

Programmability is becoming as hyped as the technology trends with which it is associated: SDN, Devops, and even cloud. It's used to (incorrectly) describe everything from policy-based networking and orchestration to script invocation in distributed environments. It's offered as a solution to everything from sun flares to inefficiency in operations, and apparently it can now not only make your coffee in the morning, it'll drink it for you, too.

While that may be hyperbolic (a little, at least) there is a lot of confusion about the term "programmable" and "programmability" and what it means. Toasters and coffee makers, for example, are often touted as "programmable". But I'd argue (vehemently and with my M.S. printed on a baseball bat) that such devices are configurable, not programmable. Programmability implies a level of Turing completeness that is simply not present in a toaster, but certainly is increasingly in software-defined infrastructure.

Whether we're talking SDN or ADN, real-time or management, programmability is the key value proposition for many solutions and technologies today. But each face of programmability has different benefits and can be used independently of each other to address a variety of challenges.

The Three Faces of Programmability

Without getting pedantic about it, there are three primary facets of programmability in software-defined infrastructure: control plane, management plane, and data plane.

Each one has a specific purpose and interestingly, they need not work in concert. You can benefit from one without the others, depending on what your specific goals with respect to software-defined technologies may be.

Management Plane Programmability

The Management Plane is perhaps what most people think of when they hear programmability mentioned in close proximity to software-defined anything. Management Plane programmability is generally enabled via an exposed API. This API allows programmatic control of the device/solution/software via external means. This might include pre-integrated control via automation and orchestration solutions like VMware and OpenStack as well as custom solutions. Generally speaking in today's environment, REST-based APIs are the norm, primarily because invocation via HTTP is simple, usable by both developers and devops, and is well understood.

Value: Efficiency and repeatable, successful deployments through orchestration and automation

Control Plane Programmability

The Control Plane is one of those grey areas of programmability. Within emerging SDN models, this plane of control is referred to as the "Northbound API" because, ultimately, that's what it is - an API. This plane is what enables extensibility. By using this API, the platform (in SDN land this would be the SDN controller, in the ADN world it would be the Application Delivery Controller) can be extended to include new functions, protocols, and services. Open source SDN offerings make this API open - anyone can extend the platform - while other solutions may keep this API closed to all but partners.

Value: Rapid platform extensibility, expansion of services, custom solutions

Data Plane Programmability

Perhaps the most misunderstood programmability is that of the Data Plane. That's because in some environments, notably SDN, this programmability is focused on pushing rules that define behavior to a commoditized switch fabric. In other environments data plane programmability is less structured and open. It is an API but it also acts as a platform, enabling domain logic to be executed on live traffic. Such programmability enables Devops Deployment Patterns (Blue-Green Deployments, Canary Deployments, A/B Testing, etc...) as well as extensibility of functionality (anyone need a network-hosted die roller for their tabletop RPG game?) of the system.

Value: Rapid response to business and operational incidents, flexible (and sometimes temporary) deployment architecture implementations, custom real-time logic


Published Aug 19, 2013
Version 1.0

Was this article helpful?

No CommentsBe the first to comment