For the purposes of this discussion, I’m going to define IT as the compute, storage systems, and application management. Modern IT systems use the ability to quickly migrate applications from one server to another server, perhaps to allow maintenance or to gain access to better hardware. The network must be able to adapt to the application’s new location. But in many organizations, the network changes are performed manually, one box at a time. Network processes often incorporate a time-consuming change process to help make sure that mistakes are identified and corrected before implementation. The process frequently slows network agility to a crawl.
How slow is the network, relative to IT systems? Applications can be migrated in a few minutes while enterprise network teams often take days or weeks to design a change, work through the change review process, and finally implement it during a change window.
Networking is going to have to catch up. IT is much more agile and is better able to support the business. This is frustrating the server and applications part of the organization. In some meetings, I’ve seen the IT members talk about using VXLAN as a way to bypass the slow networking organization in order to accomplish their goals. That’s not good. The two organizations need to be working together for the benefit of the business. After all, a business that doesn’t stay healthy doesn’t continue to exist.
Network Agility & Automation
The road to network agility is turning out to be quite long. As an industry, we’ve done an exceptional job of teaching network engineers how to configure, manage, and troubleshoot individual network devices. Just look at all the “Certified Expert” certifications that are available from a variety of vendors. There is currently no comparable “SDN” type of certification because there are a wide variety of SDN and SDN-like systems (OpenFlow/OpenDaylight, Cisco’s ACI, BigSwitch’s Big Cloud Fabric, etc).
The road to network agility needs to start with retraining network engineers to use more advanced configuration tools than the CLI, a text editor, and cut-n-paste. Perhaps systems like Ansible are the light at the end of the tunnel. It’s just that the tunnel is very, very long. Ansible is an IT system automation tool that has gained quite a following in the networking automation world. I recently spent time learning how to use it to build configurations and found that it is comparable to learning CLI configuration. It doesn’t require extensive Python knowledge and scripting, though some knowledge of Python lists and dictionaries is useful. There are many YouTube videos and blogs about using it to build configurations and pushing those configurations to devices, making learning about Ansible easy and free.
Learning Ansible requires a little investment of time to learn the commands that you need and the syntax of YAML files, but it’s not very difficult. I was able to build some basic configurations that would be pushed to network devices after a few days of study and experimentation with Ansible.
Changing Network Processes
What about those time-consuming network change processes that decrease the network’s ability to adapt to IT changes? Once templates and the corresponding Ansible playbook are built and validated, the source of many human errors (typos) is removed. Playbooks can then be built and validated (i.e. tested and approved through the change management process) for each common task, such as the configuration changes required to support a VM migration. Validated playbooks can then be used with shorter review processes. (Note: Any changes to a playbook or template should trigger a full validation process.)
We have the fundamental tools necessary to improve network configuration responsiveness to IT changes. We just need to learn how to use the tools and move them into the production environment. In this regard, IT agility requirements are forcing networking to move towards SDN.