|By Derick Winkworth||
|August 6, 2014 06:00 AM EDT||
In networking, workflows are awfully complicated. There are many workflows, and the exact nature of each depends on a number of variables. What task comes next is often dependent on the outcome of the previous task, and there is a large amount of data to navigate sometimes to complete a workflow. Nevertheless, there plenty of opportunity to identify and automate common tasks and segments of workflows. Once we’ve identified these, we need to ask ourselves, how exactly should we automate them?
“Encapsulation” means a vendor (possibly a third party vendor) has written software that accomplishes the same thing the workflow does, but usually not the in the same linear way a customer would do it. Sub-components within an encapsulation have well-designed interfaces for the purpose of accomplishing the goal. The encapsulation would likely be written in Java or C. In networking, encapsulated workflows are usually specific to a vendor’s product and often lack flexibility and features. Encapsulated workflows will manifest as products or product features.
Consider the following workflow:
Figure 1 shows a simplified packet walkthrough for a device. Here, in the course of evaluating what is happening to a packet passing through this device, we have discovered a filter policy applied to the ingress interface. This policy has two terms, and each of these terms references an access-list. A network engineer would need to evaluate this filter policy to determine if it is doing something to the packets of interest. The thing is, policy languages have a great deal of expressiveness and grammar. They are also proprietary. After the filter policy is evaluated, this workflow follows the forwarding pipeline to the egress interface. If you are an expereinced network engineer, you will know that there are other elements in the pipeline that should be checked for any given network device. However, there is enormous variation in the structure of the pipeline from one platform to the next. Therefore, this is a great candidate for discrete encapsulation.* There are more effective ways of achieving the goal of a packet walkthrough than the way a network engineer must do it now (particularly for SDN products), and vendors know their platforms and policy idioms best.
*Discrete means it’s a workflow with a beginning and an end. It can be manually invoked by a user, and runs for a finite amount of time, reaching some conclusion.
A workflow automation, on the other hand, consists of sub-components that are “glued together.” These components were not built especially for automation, and the interfaces between these components were not designed for any particular workflow. Automations can be developed by the customer, and very frequently discrete automations are employed by network engineers. A great example here would be a script to configure the login banner on some number of devices. These automations are written in “softer” languages like Python or Perl.
There is a clear need for Continuous Automation in networking. Plexxi’s own DSE, now an integral part of the OpenStack Congress project, attempts to address this need. As the name implies, Continuous means it’s an on-going process. In the case of the Congress, it is a modular, event/data driven system. In an environment where there are a plethora of protocols and APIs, each with their own idiosyncracies, this kind of automation makes sense. Particularly in the context of an open-source community.
Curiously, some workflows may best be addressed by a combination of automation types. For instance, if a customer wanted to know what was going on in the network relative to a particular application, that workflow automation could use the packet walkthrough encapsulation of a vendor combined with an automation tool like the DSE to harvest network meta-data from external systems about application endpoints. This could yield a network map of the application’s endpoints along with visual indicators of issues in the network that could be impacting to the application. In this way, the network engineer could quickly and accurately gauge the health of the network in the context of an application versus engaging in a tedious and error-prone search “by hand.”
Customers, vendors, and open source communities should work togethor to make networking better. Identifying common workflows and determing the best way to automate them is a good first step. This will require vendors to think differently about how they develop their products, with their user’s needs in mind first. Traditionally, just getting a network feature to work and interoperate was the goal, but now we must consider how this feature fits into common workflows performed by network engineers.
[Fun fact: Broccoli is a member of the cabbage family. In spite of this, Broccoli tastes good. When someone offers you cabbage, they are insulting you.]
Sep. 2, 2015 04:00 AM EDT Reads: 244
Sep. 2, 2015 04:00 AM EDT Reads: 481
Sep. 2, 2015 03:30 AM EDT Reads: 607
Sep. 2, 2015 02:00 AM EDT Reads: 697
Sep. 1, 2015 11:45 PM EDT Reads: 399
Sep. 1, 2015 03:00 PM EDT Reads: 448
Sep. 1, 2015 02:45 PM EDT Reads: 179
Sep. 1, 2015 01:00 PM EDT
Sep. 1, 2015 12:45 PM EDT Reads: 484
Sep. 1, 2015 12:30 PM EDT Reads: 926
Sep. 1, 2015 12:15 PM EDT Reads: 252
Sep. 1, 2015 11:45 AM EDT Reads: 332
Sep. 1, 2015 11:15 AM EDT Reads: 300
Sep. 1, 2015 09:45 AM EDT Reads: 249
Sep. 1, 2015 09:00 AM EDT
Sep. 1, 2015 08:15 AM EDT Reads: 370
Sep. 1, 2015 08:00 AM EDT Reads: 172
Sep. 1, 2015 08:00 AM EDT Reads: 182
Sep. 1, 2015 08:00 AM EDT
Aug. 31, 2015 02:30 PM EDT Reads: 435