Adopting, designing, and governing SOA well

SOA Best Practices Digest

Subscribe to SOA Best Practices Digest: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get SOA Best Practices Digest: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


SOA Best Practices Authors: Jason Bloomberg, Hollis Tibbetts, Pat Romanski, Liz McMillan, Lori MacVittie

Related Topics: F5 Networks, DevOps for Business Application Services, SDN Journal, DevOps Journal

Blog Post

What is Control Plane Scripting? | @DevOpsJournal [#DevOps]

So within the realm of software-defined (everything) and DevOps one can find lengthy (and often in depth) discussions

F5 Friday: What is Control Plane Scripting?

#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.

data plane control plane

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.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.