Moving From CLI to Automation? You Have Choices.

Software Defined Networking (SDN), and the dizzying number of different ways IT organizations define it, continues to be a moving target.

However, whatever the definition of SDN is this month, it is clear from talking to customers and seeing how the large web and cloud providers are transforming their operations, that all IT organizations will eventually bring automation and programmability into their IT operations. To be honest, if they don’t, they will eventually get left behind.

What is also clear is that like any new technology or method of operations — in this case automating network operations — each customer will be at varying levels of programmability skills, understanding of new tools, and breaking away from command-line interface (CLI) operations in general. For these reasons and others, I like the approach Cisco is taking around SDN, programmability, and automation.

Offer Options

As the SDN hype has begun to settle, Cisco offers options, recognizing that each IT organization is at a different stage of developing in-house expertise. Moreover, no two network environments are the same; it is almost certain that more than 90 percent of the IT organizations looking to leverage automation have a current install base they need to support as well. This is where the offering of SDN options applies.

I have been referring to this as the “three-pillar” approach to offering customers options as they begin to embrace and begin to insert automation and programmability into their IT network organization, including heterogeneous multi-vendor environments.

What are these three options?

Prescriptive Turn-Key Solutions – This offering is for those customers with a limited amount of automation and programmability skill sets within the operations teams. The solutions Cisco offers in this category hide a large amount of complexity from the customer, offering a prescriptive solution that typically automates on-boarding of new network elements (plug-and-play), pre-built graphical user interface (GUI) applications, and automation of the fabric configuration which could take days/weeks using CLI. These solutions clearly target simplification and automation in a shrink-wrapped type of solution. Examples of these solutions from Cisco include:

• Cisco Application Centric Infrastructure (ACI)
• APIC-EM
• The WAN Automation Engine (WAE)

Open Programmable Cisco hardware/Virtual Network Functions (VNF) – This capability targets those customers desiring Cisco hardware/VNF, but that also prefer open-source controllers (Ex: Open DayLight) and/or a rich set of “open” automation tool sets driven from in-house developed applications not requiring a controller. This type of customer has typically already embraced a DevOps model and “do it yourself” mentality within their IT operations team, is moving towards a model driven capability for configuring or abstracting telemetry from the device, and is leveraging native and open source tools for automation, and even programming their own applications. Examples of open source tools and data models offered by Cisco and gaining traction in the network automation space include:

• Ansible for Network Operations
• REST APIs (APIC EM Controller)
• YANG models (Cisco native and open standard)
• The open source YANG Development Kit (YDK) for generating APIs using YANG models with NETCONF to the network element.

Support for Heterogeneous Hardware/VNF Environments – This option targets those customers that have either embraced a multi-vendor hardware/VNF environment, or must operate in a heterogeneous environment for other reasons. From an automation and programmability perspective, this approach is much like option two above: It also uses open source tools like YDK or Ansible, open standard communications protocols such as NETCONF, and a combination of native and open YANG data models. But here we also add a common open standard transport data plane and control plane at the network layers, capable of supporting multi-vendor networks.

Multiprotocol Label Switching (MPLS) with multi-protocol BGP (MP-BGP) is a good example of multi-vendor solution that has existed for many years in service provider and large federal networks, with an open standard interior gateway protocol as well. As this approach moves into the data center and campus networks, open standard solutions such as E-VPN/VXLAN, Segment Routing with PCE, and others are gaining traction. The key point here is, in addition to open standard automation and programmability offerings needed to support a multi-vendor environment, the need for an open standards transport must also be considered.

While offering options to customer and accommodating solutions to match their network operations skill set is a needed approach, there are key trade-offs for each of these solution offerings that must be considered within a federal agency. The prescriptive option is ideal for those organizations that don’t have deep skill sets to build their own automation environment, or the solution explicitly targets offerings an agency can leverage immediately. However, for vendors to accomplish this level of simplicity and innovation, the solution may require pre-standard offerings and specific capabilities tied to the network OS and hardware.

On the flip side, “open” solutions clearly offer more capabilities for heterogeneous environments, but they demand an advanced skill set and even DevOps experience within the network operations team. They also can bring challenges dealing with multiple vendor network operating systems, hardware and inconsistencies of supported features. In addition, typically in multi-vendor networks the designer must design the offerings and capabilities towards the lowest common denominator of support across all of the vendors, and that common level is almost always far less feature-capable and innovative than solutions from a single vendor. This is not to say the open solutions are a bad thing, these are just factors we have learned through experience that need to be considered in the overall evaluation.

Offering choices to customers as they move down the SDN/automation/programmability path is, in my opinion, no longer an option, but a necessity. The key point is aligning those options offered by single or multiple vendors, to the needs of the Federal IT organization.

Lastly, if you are new to automation, don’t try to do everything at once. Focus on automating operational processes you perform in your network operations on a daily basis. You will quickly see the power of network automation.