Editorial StaffWe’ve been looking at the survey data we gathered from 114 attendees of the MPLS SDN World Congress this past March in Paris, and we’re coming to some surprising conclusions. For example, of the 111 people who answered the question – “Do you believe all of your relevant network staff have the skills and experience to implement and manage SDN?” – 84 people or 75% said
One recurring theme we’ve seen in the free responses to the follow-up question – “Why or Why Not?” – is that for the most part, network engineers don’t have the IT skills or development skills to implement and take advantage of SDN. One respondent put it bluntly: “[Network engineers] don’t do software.”
Of course, this is one of the factors that holds adoption of SDN back. When asked how much of their total network is a production SDN, more than half said zero (0%). One-third indicated it is only “1-25%.” Only three respondents revealed that more than half their production networks are SDN.
So, why haven’t network engineers learned the software development skills to make good use of SDN? Network engineers tend to be smart autodidacts, so I don’t think it’s a matter of ability. Nor do I think it’s a matter of stubbornness: Network engineers who have lasted for more than a couple of years in their careers have lived through so many changes to network infrastructure that even a big change like SDN should not faze them.
Some may be afraid that widespread SDN adoption will cost them their jobs, but as I wrote in a blog post last year (No, Software Defined Networking will not Doom Engineers), “It will, if anything, free up network engineers from maintenance and routine tasks, and allow them to focus on the really tough problems as well as big projects that can increase business agility, reduce costs and/or increase revenue.”
I think the biggest factor that explains why engineers aren’t picking up the skills to become SDN experts is that SDN is not yet seen as truly mature. To be sure, some service providers and companies that implement SDN are taking an educated risk to be on the cutting edge and secure a “first mover” advantage, but it is a risk.
Naturally, it doesn’t make much sense to study today’s SDN development techniques when tomorrow’s might be radically different. As SDN isn’t fully standardized yet, early adopter service providers and enterprises might spend a great deal of time and money training their network engineering teams to use development tools that will eventually be discarded (Indeed, “lack of industry standards” was cited as a concern for 45% of the survey participants). Nobody wants that, so many companies are willing to hang back and wait for the SDN technology to mature a little bit longer, learning from the mistakes of others.
Over on LinkedIn, there have been a number of comments suggesting this might be the case. These were in response to our survey findings from last year’s SDN/MPLS International Conference in Washington, D.C., where 70% of the respondents said their network teams are not ready to manage SDN. While multiple anecdotes are not statistically significant, these quotes can be quite insightful:
“It’s slightly murky out there for SDN. SDN or NFV – which way will the industry sway? The required skill sets may vary according to the nature of programmability needed. Interesting times. 🙂 Once SDN/NFV gets off the POC stage and takes a grip on networks and services, a clearer path should become visible.”
— Santanu Ganguly, Sr. Consulting Engineer, EMEA Channel Partners at Juniper Networks
“Lots of interest is given to the SDN and what it could bring to the table, presentations are given by big names like Cisco, ALU, and Hawaii, to introduce their products, but when we talk to the engineers responsible for making the decisions, they don’t think that SDN is ready.”
— Guedrez Rabah, Ph.D student, Orange Graduate Programme
“These new techniques blend networking, server technologies and IT. Those skill sets have different cultures and historical baggage. You have enough hassle getting those groups to use consistent acronyms and language, never mind cross-train.”
— Stephen Hope, Design Architect at Vodafone
One thing that may explain slow SDN adoption is cost: About 34% of our respondents said “cost to implement” is one of their biggest concerns about SDN. SDN is still early technology, and as technology matures, it almost certainly drops in price. (The classic example is the pocket calculator, which retailed for $129.95, or $692.48 in 2015 dollars, at Radio Shack in 1973.) The return on investment (ROI) for SDN may be positive now, but service providers and enterprises might be waiting for the costs to decrease so they can get more bang for their buck when they finally do implement SDN. Current wisdom suggests that expensive, forklift infrastructure upgrades for SDN are infeasible for most organizations. Most of Packet Design’s customers favor an evolutionary, hybrid approach. This is the focus of our SDN analytics and orchestration efforts.
Something else that surprised us was that only 16% of the respondents checked “inadequate management visibility and control” as one of their biggest SDN concerns. This is down from our previous year’s polling data, where “lack of management visibility” came in at 22%. This is especially interesting considering 89% indicated “We will need NEW analytics and orchestration tools for SDN.” In addition, 75% said “Some of our existing tools will NOT work with SDN.”
Obviously, since we make the Explorer Suite, we’re happy the number concerned about management was relatively low and dropping. However, it may increase once SDN becomes more widely adopted and more network engineers realize that traditional management methods are not up to the task of managing SDN. Management always seems to be the last consideration when new technology comes to the fore, but we’re doing our part with our SDN service assurance platform. We’ll be releasing our first SDN analytics and orchestration application later this year.
Add comment