Welcome!

@DevOpsSummit Authors: Elizabeth White, Pat Romanski, Yeshim Deniz, Stefana Muller, Karthick Viswanathan

Related Topics: @DevOpsSummit, SDN Journal

@DevOpsSummit: 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.

@DevOpsSummit Stories
Adding public cloud resources to an existing application can be a daunting process. The tools that you currently use to manage the software and hardware outside the cloud aren’t always the best tools to efficiently grow into the cloud. All of the major configuration management tools have cloud orchestration plugins that can be leveraged, but there are also cloud-native tools that can dramatically improve the efficiency of managing your application lifecycle. In his session at 18th Cloud Expo, Alex Lovell-Troy, Director of Solutions Engineering at Pythian, presented a roadmap that can be leveraged by any organization to plan, analyze, evaluate, and execute on moving from configuration management tools to cloud orchestration tools. He also addressed the three major cloud vendors as well as some tools that will work with any cloud.
Serveless Architectures brings the ability to independently scale, deploy and heal based on workloads and move away from monolithic designs. From the front-end, middle-ware and back-end layers, serverless workloads potentially have a larger security risk surface due to the many moving pieces. This talk will focus on key areas to consider for securing end to end, from dev to prod. We will discuss patterns for end to end TLS, session management, scaling to absorb attacks and mitigation techniques.
CI/CD is conceptually straightforward, yet often technically intricate to implement since it requires time and opportunities to develop intimate understanding on not only DevOps processes and operations, but likely product integrations with multiple platforms. This session intends to bridge the gap by offering an intense learning experience while witnessing the processes and operations to build from zero to a simple, yet functional CI/CD pipeline integrated with Jenkins, Github, Docker and Azure.
"We do one of the best file systems in the world. We learned how to deal with Big Data many years ago and we implemented this knowledge into our software," explained Jakub Ratajczak, Business Development Manager at MooseFS, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
Traditional IT, great for stable systems of record, is struggling to cope with newer, agile systems of engagement requirements coming straight from the business. In his session at 18th Cloud Expo, William Morrish, General Manager of Product Sales at Interoute, will outline ways of exploiting new architectures to enable both systems and building them to support your existing platforms, with an eye for the future. Technologies such as Docker and the hyper-convergence of computing, networking and storage creates a platform for consolidation, migration and enabling digital transformation.