#DevOps #SDN And more importantly, what can I do with it?
So within the realm of software-defined (everything) and DevOps one can find lengthy (and often in depth) discussions on the relevance and indeed importance of programmability to both. In the case of SDN, programmability is specifically subdivided into two areas: control plane and data path.
That's because its core premise relies on - no requires, actually - the decoupling of the two paths.
So you use the control plane to centralize the "state" of the network. What that really means is that some entity external to the data plane (or data path) is responsible for authoritatively managing (and controller) the configuration of the services that reside in the data plane. That happens either using control plane APIs (like F5's iControl) or protocols (OpFlex, OpenFlow, etc... ). This is where the ability to efficiently automate and orchestrate services comes from, resulting in the benefits of reduced risk and improved time to market touted by SDN and related architectures.
Now, what most people don't know is there's a second control plane programmability component known as control plane scripting. What control plane scripting does is allow the control plane to dynamically modify configuration and policy.
That's what F5 iCall does.
Here Comes the (Computer) Science
So let's say you want to be able to dynamically do something sometimes, but not all the time. In other words, you want it to only happen when certain conditions are met, say log a tcpdump when an application experiences a failure. The "event" is "application failure". The response is "run a tcpdump and log it to X."
So what happens is we're moving along quite normally and as expected, F5 selects App Instance 1 to service a request. For some reason, App Instance 1 experiences a failure. Maybe it's a 500 Internal Server error or maybe it's a network level failure (a time out). The failure triggers the iCall script, which then executes a tcpdump and merrily sends it off to a log somewhere. Oh, and it might even send you an e-mail to let you know, cause it's thoughtful that way.
Basically iCall can perform tasks in response to a triggered event, on a periodic basis, or as a perpetual daemon-like service. iCall enables folks to react to specified events by executing services on the control plane, such as logging a full TCP stack dump on a failure, executing a specific iApp to reconfigure application network service settings, or adjusting weights on application services based on a change in health-monitoring data. iCall can be used to periodically manage backups or repopulate DNS. Additionally, perpetual services such as configuration audits can be managed simply using iCall.
The unique thing about iCall is that it can be triggered from the data plane. That means that as traffic is flowing through a service, a data path script (iRules) can trigger a control plane script (iCall). A good example is invalidating the cache. This example executes when a specific URI is invoked, but because it's programmability you have the flexibility to pretty much think of whatever trigger you'd like. For example, you could trigger on an HTTP 404 error seen on the data plane to execute an iCall script that sends an e-mail. Cause, you're thoughtful that way.
iCall is not an API, it's not data path scripting, it's control plane scripting. It's another tool in the network that enables greater flexibility and responsiveness to events that happen in real time that should be handled but often aren't because, well, you aren't fast enough to hit the button to start that TCP capture.
Control plane scripting, like data path scripting, is a programmatic means to an end. The "end" being a more operationally efficient and agile network.