Is your organization ready for automation deployment? – TechTarget

Remember the voice-data convergence? I hope you're prepared, because a similar transition is ready to take roo...

Enjoy this article as well as all of our content, including E-Guides, news, tips and more.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

t.

This time, it is the transition to automation, and then to forms of automation deployment and advanced control and management.

When we transitioned from wired PBX systems to voice over IP, the team that handled the voice system had to make a big change. In the old system, circuits and wires were the basic components. Sure, there was some multiplexing -- T1s and the like -- but nothing like IP packets. Training voice technicians was an interesting process. Some made the transition, while others retired, along with the equipment they supported.

A similar situation is unfolding today. I've had more than one network engineer tell me they hope the latest transition takes long enough to allow them to retire before they have to learn new things. I was shocked.

Change is coming, and it is necessary. Compute and storage are dynamic, having made their transition over the last 10 years. The network is the final obstacle to dynamic IT systems that can more easily adapt to changing business requirements. Change is needed to increase networking efficiency, just as it has for server automation. The only thing we need to determine is the path this journey will take.

This transformation of IT and networking is gathering speed. The growth in the DevNet section of Cisco Live is one indication. When I search the web, I find a lot more activity around the use of APIs for automation deployment. I even took a class on using Ansible for network configuration control.

It's pretty incredible how simple a configuration can be when it is constructed in a YAML definition. Configuration elements that are repeated in a normal configuration get entered once in YAML, such as loopback interface addresses or Border Gateway Protocol addresses. A BGP peering relationship can be reduced to just a few lines of configuration and ported between hardware vendors with simple changes. A complete data center pod can be configured with a similar reduction in complexity.

The tie-in to culture is due to the change in how network configuration is handled. Processes and procedures that have been developed -- over the past 10 to 20 years -- need to change when automation is used. These past procedures will often have the network staff propose a set of changes, a test plan and a back-out plan to be executed if a change fails.

A change control board reviews the change and frequently approves it. Because changes sometimes create brief network outages -- for example, a spanning tree root bridge change -- they are typically implemented during a preapproved change window. Part of the reason for this step-by-step process is to force the network engineers to think more carefully about changes before rolling them out to the network.

Many organizations use network change and configuration management (NCCM) tools to push changes to devices. That's a step toward automation, but they still rely on command-line interface (CLI) configuration commands. Manual methods are then frequently used for the validation test, limiting the extent of things that can be checked. This is where automation can be applied. Construct good test plans and a set of automated checks to be performed on the network -- not just the device being changed. Likewise, the back-out plan should be automated through the NCCM platform so it is easy and fast to back out.

Automation is just the next step in the journey. It isn't the final step.

Automation is just the next step in the journey. It isn't the final step. The problem I have with basic automation tools is they don't create new abstractions. The Ansible libraries for Cisco NX-OS use the same parameters in the API as are used in the CLI. There's nothing new there, just a new communications mechanism that's uninteresting. There are no new abstractions that allow us to hide the details of a complex configuration.

Some companies, like Amazon, are already in this next phase. Create an Amazon Web Services (AWS) compute instance with X CPU power, Y storage capacity and a public IP address. How long does it take for AWS to create the instance, modify the network to support it and have a public IP address assigned? It's just a few minutes. You specified what you wanted, and the system delivered it. You didn't have to specify "how to do it" details like VLAN ID, firewall rules or any Layer 4 VPN to keep your traffic separate from everyone else's. AWS created an abstract compute and storage entity.

We need new abstractions in networking that allow us to hide as much complexity as possible. It remains to be seen whether new abstractions will come from the intent-based networking systems that companies like Apstra have pioneered and Cisco has now embraced. These systems are worth investigating, but probably only after you've undertaken the effort to learn about basic automation. Think of it as a "walk before you run" approach.

Clearly, some people are concerned that automation and whatever follows will replace their jobs. As with the convergence of voice and data, some people make the transition and others don't. That transition, just like this one, was more about changing jobs than eliminating them. There will always be a need for people who understand how complex technology works, how to use it in good designs and how to diagnose problems when it doesn't work the way you intended.

This is a journey. You don't get to skip steps. The entire organization has to learn new technology, how to best apply that technology, and to develop processes to implement and maintain it. Several things must happen to make a successful journey, among them:

You get to decide if you're going to participate in this journey to automation deployment as a leader and control your destiny, or if you're going to participate after someone else has blazed the trail. Just note that first movers frequently have a competitive advantage over their slower-moving peers.

What will the future hold for enterprise networking?

SDN now includes virtualization and automation

DevOps and automation in software-defined networks

Read more:

Is your organization ready for automation deployment? - TechTarget