Systems administrators are the heart of any IT team. Since IT is arguably what keeps most modern organizations operating, then in some ways sysadmins are the heart of modern organizations. Of course network automation can make the lives of network engineers easier, but it can also benefit enterprises as a whole. Yet here’s an interesting quandary: does network automation even benefit systems administrators?

Sysadmins shepherd hardware, virtualization platforms, Operating System Environments (OSEs), and more.  They must master multiple disciplines within IT, and are under the constant pressure to learn even more. The life of a systems administrator is one of trying to carefully balance the solving of immediate problems while investing with their future via automation to prevent these problems from recurring, additionally with lifelong learning.

As a profession, systems administration has been cyclical. In one part of the cycle the generalist sysadmin is championed. In the next, specialization is all the rage.  The past decade has seen the generalist brought once more to the fore, as specialties such as “storage administrator” are automated away by clever software.

However, throughout the decades the physical networks have largely remained the jurisdiction of dedicated network administrators.  If the networks belong to another team, how does automating them help the sysadmins?


Though mastery of the physical network has traditionally been a different group of people than those wrangling the servers, this doesn’t mean that sysadmins haven’t had to learn their fair share of networking.  Virtualization platforms, for example, have offered increasingly sophisticated networking capabilities. Because virtual networks are, by nature, technically existing on a server instead of a physical switch, they have been traditionally the province of the systems administrators (not network administrators).

Today’s workloads can exist on physical servers, inside virtual machines, within containers, or on a vendor-supplied appliance.  Workloads can be on-premises, located on a service provider’s network, or be spun up in the public cloud.

Somehow, someway, someone also has to take charge of the increasing number of things that aren’t part of the physical networking infrastructure, but also don’t live on a server.  Printers, lightbulbs, and entire armies of mobile phones are just the beginning of the gifts that the Internet of Things (IoT) keeps on giving. Sensors are popping up everywhere, and previously air-gapped or otherwise isolated systems — some of which control millions of dollars of equipment and may not even be able to be patched — all have to be taken care of.

Today’s organizations are undergoing a digital transformation, with that term itself something of a conceit.  “Digital transformation” has never really stopped, but the marketing buzzword is seeing a resurgence today. The reason why “digital transformation” is back on everyone’s tongue, however, is at the very core of why network automation matters: because much of what’s getting chucked onto today’s networks is insecure, unsecurable, and utterly unknown to the systems and network administrators tasked with managing it.

The short answer to “how does network automating physical networks help admins” is that the IT requirements of today’s organizations are growing so fast that sysadmins simply must automate everything in sight just to survive.  None of the automation done in other parts of IT stack matters much if there’s a huge bottleneck at the network layer that requires actual humans to implement or review every change.  That might have been fine 20 years ago, but today it’s a nightmare and a half.

Breaking Down Walls

Against this backdrop, consider that in most organizations there exist (at least) two different types of networks: virtual and physical. These networks are managed by two different groups of people. In some cases, rivalry between the two groups exist, and naturally this can lead to problems.

Network automation is the perfect opportunity to break down some of the walls between the different groups within IT, in the same way that DevOps and related approaches can help to break down the barriers between operations teams and developers.

At a very high level, DevOps has become a practice wherein operations teams set up automated infrastructure for dev teams; that automated infrastructure has various guard rails and the developers roam free within those confines. Ops teams put a lot of effort into their environments, creating templates and images, building in monitoring and reporting and more, but the practical and pragmatic end of the DevOps approach to IT has a lot to do with self-service IT, all in a quest for “agility.”

Self-service, however, doesn’t mean “without limits”, which is where the guard rails come into play.  The ops teams might, for example, say that a particular dev account has the right to use 100TiB of class C storage, 20TiB of class B storage, and 5TiB of class A storage, along with 300 vCPUs and 1TiB of RAM.  The cloud software in use will let devs cut that up and allocate it however they want, but they can’t surpass their limits.

DevOps is systems administration via profiles and policies, with the aid of software which automates and orchestrates infrastructure. This is not so different from network automation.

On the face of it, network automation is about making networks more robust, resilient, and scalable. Take a bucket of water into the data center, pour it on a switch, and watch the network reconverge to bypass the drowned switch. Need to add 1,000 switches to a software-defined network (shortly before you’re confronted with prejudice by security staff)? No problem. Plug them in and let automated provisioning and configuration sort ’em out.

However, beyond the basics of “making physical network bits talk to other physical network bits” software-defined networking allows network admins to grant a significant amount of freedom to systems admins, also with guard rails. The fundamental adaptability of software-defined networks, for example, mean that network admins don’t have to oversee the addition of new switches or servers to the network. When new equipment is needed, it is simply added, and the automation tools take care of making sure it’s properly configured.

Similarly, capabilities such as policy-based routing, VXLAN routing, VXLAN virtualization integration, and QinQ/hybrid cloud interconnectivity allow network administrators to build guard rails that prevent systems administrators from stepping out of bounds or breaking anything outside of their domain. Software-defined networking allows network administrators to not only use traditional tools like ACLs to build guard rails, it also allows the physical network layer to participate in the virtual networks used by virtualization platforms and cloud providers.

This interconnectivity allows network administrators to build the network functions, defenses, and cross-site links that make sense for the network as a whole. It also means that the creation of these tools can be put in the hands of the experts “the network administrators” instead of the already overburdened systems administrators.

Systems administrators thus become consumers of network resources in the same way that developers are consumers of operations resources. They can provision what they need, when they need it, but if they want to do anything truly strange, a conversation with the experts will be required.

Learning to Automate Together
Network automation thus has multiple real-world benefits for systems administrators, and the organizations they serve. It enables infrastructure automation, but in a manner which allows boundaries to be set.

Automation makes IT teams as a whole more responsive, but it also gives systems administrators the experience of being consumers of resources managed by another group within IT.  This can help systems administrators better relate to those who consume their resources (for example, developers), which may help bring all the various groups within IT together.