Mark Coleman, General Manager NetBox, NS1
Network automation is not yet a concept embraced by all networking teams. Many still view it as too complex, too time-consuming or too costly to implement. Others fear that automation may eliminate jobs. But the truth is that all employees in the company, not least the network engineers themselves, can benefit from implementing network automation.
Understandably network operations teams are under pressure as the world around them becomes more convoluted and more dynamic. A perfect storm is beginning to emerge, threatening to engulf them in multiple workloads on multiple private and public clouds, while these systems need to communicate seamlessly for their companies to maintain the same operational agility. The immediate solution for NetOps teams – who by the nature of the critical workload responsibility are all too often encouraged to maintain systems stability, rather than prioritising agility – is to create ticketing systems, ‘change control boards’ or any number of other processes to ‘protect’ themselves from the broader organisation. This often includes adding more staff to existing manual processes to cope better with the workload.
Unfortunately, it is not just technological or organisational challenges that NetOps professionals face. By opting for short-term fixes that can be managed quickly, they can become seen by their colleagues upstream – such as development – as lacking agility, or as being a costly resource ripe for replacement by automation.
We have seen this scenario before. It reflects exactly the conditions that brought about the DevOps and DevSecOps movements. When companies reach the point where existing processes fail to scale, automation is often the best way out, and the good news for NetOps teams is that they can stand on the shoulders of those who went before them.
Starting the automation journey
A Network Source of Truth (NSoT) is the first step that companies need to take on their automation journey. As Gartner’s Andrew Lerner explains: “The SoT is the single source from which the automation tools will gather the data they need to execute the pipeline. The SoT represents the desired state of the network.” This is what NetOps teams need as the backbone for levels of automation, monitoring and reporting, allowing them to be in full control of their networks. While an NSoT provides the view of the network at a level that automation tools will understand, teams who are coming from disparate tooling immediately gain operational benefits by being forced to agree on a common view of what the network should look like, even before they consider the step to network automation. Too often the networking knowledge in teams is tacit and when something breaks or somebody is sick or on holiday, tacit knowledge doesn’t scale. The earlier organisations invest in an NSoT, the faster they recoup the investment and realise performance improvements.
As with all tech movements, the exact definition of this move to network automation is evolving, but the term gaining the most traction is NetDevOps. As with DevOps before it, NetDevOps is more than just network automation and will likely grow over time into an umbrella term for a collection of processes, practices and tools that help NetOps teams to manage this shift.
This can, however, be difficult. There will be dissenting voices, just as there were for all previous tech movements. As with DevOps, for example, it is best for both practitioners and leaders to regard the movement as an exciting shift to stay close to. Not all aspects of NetDevOps will be useful in all contexts, but it’s almost inevitable that it will be the movement to watch in the networking space over the next few years.
Take engineers with you
For existing network engineers, while automation can seem like additional overhead on top of an already demanding role, we see many indications that those who are willing to make the investment end up both saving time, and also seeing new career paths open up for them. For those concerned that network automation may “automate them out of a job” history doesn’t suggest this will happen – there are more DevOps engineers today than there were systems administrators a decade ago, and the same will apply in the network environment for those willing to adapt.
Network engineers will not need to become full-blown software engineers over the next few years, but many will need to become familiar with scripting, and the good news is that there’s never been a better time to start. Network engineers can relatively safely focus on Python for the foreseeable future, and there are a plethora of resources online to get started, often for free. As we have seen with previous movements, the lines between traditional roles will blur to some extent but concerned networking leaders can take solace in the fact that it takes far longer to teach a Python scripter to be a network engineer than the other way around.