imelamory - Fotolia
As SDN evolves from a strategic vision to an engineering reality in the new WAN, network professionals are focused on plenty of challenges: How do the different vendor architectures stack up? What are the limits of interoperability? And what about software-defined security?
What network professionals are likely not thinking about -- but should be -- is the operational and organizational sea change that SDN and software-defined WAN (SD-WAN) brings. Just as server virtualization dramatically modified the job function and career prospects of sys admins, SDN changes the job function and career prospects of network engineers. And it forces their managers to rethink how to organize and staff their teams.
Rethinking job functions in the new WAN
Start with the basics: roles and responsibilities. Today’s network engineers are responsible for setting up routing topologies, configuring quality of service (QoS), and troubleshooting routing and switching errors. The underlying assumption, though, is the concept of a static network: Once routing domains are set up, they don’t change. So the job fundamentally requires depth of knowledge of routing protocols and device configuration.
With the advent of SDN, the assumption of a fixed environment no longer holds. Instead, routing architectures can shift with changes in traffic flows, which in turn result from dynamic workload changes. In other words, the job functions shift from setting up, managing and troubleshooting the network, to defining network configurations for a range of application and workload use cases. From a skills perspective, this means having a much deeper understanding of both application dynamics and out-and-out programming, including programming languages and frameworks -- Python, Ruby, SOAP and the like.
For managers, this shift in required skills poses several challenges. First is how to acquire the combination of network and programming expertise: Is it better to teach network engineers programming skills or teach programmers the fundamentals of routing? There’s no right answer -- you can make a solid argument either way -- but the fact remains that the required skill set is a blend of expertise that's currently rare.
Team remix in the new WAN
A second, weightier challenge is the team mix. While it's important to have networking expertise, and a few individuals blending networking and programming expertise, what's the right ratio of "deep" network engineers to more software-oriented SDN specialists? Again, there's no right answer, although experience from the server-virtualization transition suggests there's likely to be a dramatic reduction in the number of "deep" network engineers, compared to their more software-focused counterparts.
There's also the question of how much security expertise, and what sort, should be represented on the team. Although it doesn’t yet get a lot of press, software-defined security (SDS) is the natural outgrowth of an environment in which most infrastructure elements -- servers, storage and networking -- are virtualized. This requires, once again, a shift away from hardware-oriented expertise -- the ability to configure security devices such as Palo Alto and Checkpoint firewalls, for instance -- to more of a software focus.
Skill applications in the new WAN
Finally, one of the biggest challenges in a software-defined everything world lies in rethinking the current "horizontally portable" skills and recognizing the value of more "vertically focused" skills. What I'm getting at here is this: In the old, pre-SDN days, network architecture was a horizontally portable skill: A routed network for, say, a financial services firm wasn’t significantly different from one for a pharmaceutical company. The important depth to acquire was in technical competence, not in the specific company or vertical industry.
But SDN's ability to deliver specific use cases means infrastructure engineers need to think longer and harder about what those use cases might be -- and use cases are typically specific to a vertical or a particular company. A retail company might shift traffic flows to cloud-based data centers for increased capacity at specific times of the week, month or year, for instance.
So just as former sys admins moved from configuring servers to match technical specifics to crafting various computing solutions for internal customers, network professionals will move toward developing a library of SDN use cases that meet specific business needs. Much of the value of SDN technologists will be encapsulated in that use case library.
The bottom line: Network professionals at all levels -- engineers, architects and managers -- need to be prepared for a sea change in their job functions. Some takeaways:
- Network engineers and architects should decide whether they want to become "deep technologists" -- the go-to folks for understanding the finer nuances of routing and network design -- or more general SDN specialists with both coding and networking expertise. In making that decision, they should consider that there will be a reduced need for "deep technologists," but an increased need for SDN specialists.
- Network managers should think about how they want to acquire the right blend of networking and programming expertise. Do they want to train their current networking teams in programming or hire programmers and teach them networking? The decision will also affect the career advancement possibilities for architects and engineers.
- Network managers will need to fine-tune the composition of their teams. As noted, the SDN-centric networking team is likely to include a very limited number of deep networking technologists, often only one; a handful of SDN specialists with both networking and software expertise; and at least one individual with expertise in SDS.
- Finally, all professionals should think about taking a structured approach toward developing and managing a library of SDN use cases.
SDN is the new WAN. Gain a better understanding of the technology and its benefits here.
Should you consider SD-WAN?
Verizon launches managed SD-WAN service