If you’re a longtime network operations professional, you know the field has come a long way from the days when your main worry was running cables through ducts. But the past few years have seen a huge shift: a move toward software-defined networking, an architectural approach that separates the management of the control plane of network devices from the underlying data plane that forwards packets across the physical network. Arcane command-line interfaces into individual network devices are being superseded by user-friendly GUIs that allow you to set policies across the entire network. And these moves have the potential to radically improve productivity on the networking side of IT.
While some people are dazzled by the march of technical progress, those who spent most of their career investing in a certain set of skills might view this shift with alarm. But these changes are nothing new to the networking community, which has constantly evolved. Yet, remaining relevant in the networking field is going to require more aggressive changes in skill set as the concept of software-defined everything pervades the data center. While these new changes will require significant effort to navigate, the potential rewards are great.
The shift to software-defined networking comes with its share of hype. But the benefits are real: SDNs mean less grunt work for network pros, as menial tasks and low-level configurations are largely automated and abstracted behind high-level GUIs. “The opportunity is that operation tasks will not be as tedious and network management tools will be aligned much closer to the high-level intent of the operators and the business,” says Brandon Heller, co-founder and CTO of Forward Networks. “Troubleshooting network issues will be less about looking for a needle in a haystack, as it will be possible to apply software models and later AI techniques to quickly diagnose and remediate problems.”
These changes don’t just mean less irritation for you. They also have transformative implications for networking’s role in IT. For many networking professionals, “two-thirds of their day is spent fixing stuff instead of building stuff and optimizing stuff,” says Shamus McGillicuddy, research director for network management at Enterprise Management Associates. “If a company wants to roll a new customer-facing service out into the cloud, it might take the network team a few months to do their end of it instead of a few days because they spend most of their time fixing stuff that is broken. They won’t have enough time to devote to specifying network segmentation and network security policies for using the applications.”
It’s holdups like those—and, in contrast, the productivity boosts and nimbleness that SDN promises—that have enterprises salivating. Low networking productivity doesn’t exist in a vacuum; it affects every other part of IT. “Everybody will tell you that the IT organization doesn’t respond to the business quickly enough,” says McGillicuddy. “And part of that is that the network is highly manual and slow to move whereas some parts of the IT organization, like DevOps, are really fast.”
A new attitude
Network engineers need to embrace this key shift as enterprises approach digital transformation, both in mindset and changes in specific technologies (though some new technical skills are necessary). Networking needs to become part of the “Ops” in DevOps. Because without networking, the DevOps philosophy won’t succeed. “Sometimes, DevOps teams won’t bring the networking and security people in until they’ve moved too far along,” says McGillicuddy. “Networking will say, ‘Oh, you gotta do this, this, and this. If you had brought us in from day zero, we could’ve made sure that you addressed this in the very beginning.'”
New-model network engineers need to approach their job like IT generalists. “Think about the network as a platform that enables things, rather than just a bunch of boxes that you need to program one by one as you go into the CLI interface that you’ve relied on for years,” says McGillicuddy.
Adding to your toolbox
To a certain old-school mindset, this might sound like a lot of buzzwords without much substance. What does it all mean in practice? What specific skills do you need to transform your career for the SDN and DevOps age? The biggest keys are scripting and automation tools, which are the lifeblood of DevOps shops. And Heller says that while many network pros may balk at the notion of becoming programmers, “everyone has the capacity to add scripting and automation to their toolkit.”
Among such tools, these open source offerings are some of the most popular networking pros will encounter:
- Ansible, a suite of software provisioning, configuration management, and application deployment products owned by Red Hat, which includes a networking-specific tool.
- SaltStack, a Python-based configuration management tool that offers network automation functionality.
- Puppet, a software configuration management tool that uses its own declarative language to describe infrastructure as code. Puppet also claims it can apply DevOps to your network devices.
If your shop is already implementing DevOps, some of these tools are likely already in use for purposes other than networking.
Networking pros should also learn how to use the APIs offered by other tools and systems their enterprises use internally to further the DevOps goal of end-to-end automation. These skills can be picked up even by those who are averse to making a full leap into programming. “If you’re adopting a SD-WAN solution, you may need to take the API that vendor provides and integrate it with some of your IT management systems,” says McGillicuddy. “Maybe you need to connect your SD-WAN solution to an IT service management tool like ServiceNow so if there is a problem with the SD-WAN, it can automatically create a ticket in ServiceNow and get integrated into your formal processes—that might be your responsibility as a network guy. You might also need to integrate it with something like a SEIM system. That’s going to require some programming skills and also just understanding how the different tools you’re integrating work.”
Another big advantage of SDN is that it makes it possible to set up hybrid networks that span local networks and the cloud. That means an understanding of cloud networking is a must, including the tools that providers such as Amazon and Microsoft offer specifically for network pros. Much of your enterprise’s interactions with cloud platforms fall under networking’s umbrella, so understanding and taking charge of those project aspects can help your team succeed—and demonstrate networking’s importance to boot.
“A lot of the enterprise network teams that I survey or talk to say they have some responsibility for monitoring the networking costs associated with public cloud consumption,” says McGillicuddy. “In many cases, you can track that in your network monitoring tool. If you need to, you can send a warning to your DevOps guys saying, ‘The way you’ve built your application is really driving up our operational cost because you set it up in such a way that too much data has to be pulled out of AWS on a daily basis. Is there any way you can minimize that?'”
How to school yourself
If you’re reading this article and seeing a lot of unfamiliar names and terms, you’ve got options on how to learn more. Most tech pros are used to learning new technologies on the fly and sometimes on their own time, and this is an area where you’re going to want to put in the effort. As noted, some of these tools are probably already at use in your enterprise. Talk to your peers internally for help on how to get started, or ask which conferences to attend. Learning these technologies benefits the overall IT team.
In fact, you might spearhead the spread of these tools into the network side of your shop, says McGillicuddy. “Some people will tell me, ‘I see that my cloud team’s using something like Ansible or SaltStack or Puppet to do a lot of automated configuration management of their stuff. And those tools can be applied to the network as well, even though it isn’t. So in my spare time, I’m trying to learn how to work with that stuff.'” Often, there are specific programming languages for specific APIs or tools, like Python for SaltStack. If your enterprise is already committed to one of these offerings, you can let that guide your self-education.
As with anything in tech, you’ll find plenty of material online for self-directed study. “Many automation tools, such as Ansible, Puppet, and Chef, are free to use and have Stack Overflow posts, forums, and useful results if you become stuck,” says Heller. “Trying out tools like Postman or languages like Python can be a good start, even if not used directly in a network context. You don’t need to be certified to be useful in something.”
But don’t feel like you have to be entirely self-directed, either. “Every vendor is incentivized to make getting started easy, and most of this stuff requires no hardware,” says Heller. “Many cloud platforms, like AWS, Azure, and Google Cloud Platform, all offer free credits.”
McGillicuddy says you shouldn’t be afraid to approach vendors directly with your career concerns, especially if you have a pre-existing relationship with them. “Talk to your vendor specifically about how any new technology that makes everything automated or easier affects you. Before you buy whatever product that they’re selling that’s going to make you potentially irrelevant, you should ask them how you stay relevant. They should have an answer for that.”
Also, don’t be afraid to ask your employer for institutional support. Jamie Campbell, a former network administrator who is now a security engineer at Google, says he hasn’t observed people getting left behind in the transition to SDN. “Companies that are leaders of the industry offer valuable educational programs within the organization or sometimes stipends so employees can pursue further education themselves.” And McGillicuddy says that you might consider software engineering classes if you find yourself facing complex coding challenges: “Don’t just learn how to code so you can write some one-off scripts. Maybe think about formal modeling of software so you can build quality tools.”
Don’t forget your old tricks
[to continue, CLICK HERE]