Every time I sit down to consider the future of infrastructure, I start out thinking about the past and the present. Maybe it’s too many years spent as an infrastructure engineer, years spent analyzing problems so I could build a solution. Or maybe it’s the result of having accumulated 20 years’ worth of experience in IT that has made me suspicious of solutions that don’t have clearly-articulated problems they’re addressing. In any event, let’s retrace our steps a bit and figure out why we’re so enamored with all things automation lately.
Enter the Command Line Interface
In the beginning, there was the command line interface (CLI). It was a blinking cursor that unnerved the uninitiated by offering limitless, poorly-documented possibilities. And it was unforgiving above all else: the command you issued was executed, no matter how inelegant or destructive. You want to delete entire file systems recursively with a few keystrokes? Cool. You want to change permissions on / to 777? Also, cool. The CLI offered no warnings to the novice nor the expert. It followed your instructions, and the result was always your fault.
If you’ve never spent time managing a network switch via the CLI… well then, you’ve never spent time managing a network switch. While server administration embraced the graphical user interface in the early 2000s, network administration was done exclusively by CLI. And if you thought that issuing commands to your Linux systems was nerve racking, keep in mind that a mistake on a server might bring that server and its application down. But a mistake made on a network switch might bring down the entire network, leaving server administrators to exclaim in the most hated phrase in IT: “It must be the network!” It’s one of the reasons that change management is often built around networking and extended into other technical disciplines.
What Day Is It?
We often break down tasks into Day 1 and Day 2 operations. For example, a Day 1 operation might include installing an OS on a switch, creating a virtual machine, or building a new hypervisor host. By contrast, Day 2 operations include configuring a switch port, modifying an existing virtual machine, and patching a hypervisor. Consider that Day 1 operations are done to bring a device into service, while Day 2 operations are done to operate a device already in service.
Day 1 operations like deploying a new switch can be nerve-racking for even experienced IT professionals. Most network teams rely on detailed documentation that can be cut and pasted into a terminal session. (Yes, Control-C and Control-V play a big role in IT). It’s like Mad Libs for networking: you fill out a template with unique answers for your deployment, and you’re off. Surely there’s a better way to handle new switch configurations, and it’s done through automation.
Don’t Hate, Automate
The Cumulus Networks approach is a simple and elegant solution to the problem of how to automate network switch deployments. “Cumulus on a Stick” is a quick way to build a switch by combining the Cumulus OS, your license files, and the configuration information needed to put a new switch into service. Once you’ve built the image and placed it on a USB drive, you just plug it into your unconfigured switch and power it on. This approach offers a high degree of repeatability in your deployments; it’s the equivalent of deploying a VM from a known-good template.
Day 2 network administration tasks can be broadly categorized into three groups: moves, adds, and changes (MACs). Because on-prem workloads are still predominantly virtual, MACs on a physical switch often affect hypervisor host interfaces. The risk of affecting multiple virtual machines is ever-increasing, thanks to compute nodes with ever-increasing amounts of physical cores and memory. To mitigate this risk, we again rely on automation to minimize, if not altogether avoid, human error.
Automation of both Day 1 and Day 2 operations remove a major burden on IT staff: non-trivial amounts of time spent on trivial work. With IT staff relieved from these mundane tasks, they are free to consider whether other facets of the infrastructure are ripe for automation. And it doesn’t take much time to realize that automation in the enterprise cannot thrive when it’s constrained to a single technical silo. If you have a separate automation solution for servers, switches, storage, firewalls, etc., you end up with siloed automation that only services to further entrench the old ways of IT.
In my opinion, this is the most exciting prospect of the partnership between Cumulus Networks and Nutanix. It’s a cooperative solution that extends automation beyond the organizational limits of the enterprise. It’s a symbiotic relationship that benefits both network and server administrators. It’s a first step in the long journey to the fully-automated SDDC. And it’s a reminder that innovation isn’t confined to the old server vs. network battles of the legacy IT world. This degree of automation frees more than just your IT staff; it frees your infrastructure to more efficiently serve the needs of your business.
