Here's why: Software Defined Networking Abstracts the control plane from the data plane. Both the control and data mechanisms continue to exist. What does change is the means by which we interact with them.
So, as Software Defined Networking and Network Function Virtualization (and SD-WAN, etc, etc) continue to enhance the abstraction, the fundamental knowledge of how the logic of the systems function is still required.
I can't say, for sure, that the value of someone that knows a particular command line interface is going to be continually valuable though. Look at what happened with the controller (control plane) developments in wireless networking. The value of the CLI diminished drastically with advent of the controller for enterprise wireless networking. The value of how the wireless system actually operates increased and so did the people that could balance the change. The same thing will happen with SDN technology.
REST API and/or eAPI calls are going to replace current system management methods. Any number of programming languages are going to provide the basis for automation of the service. Consider methods like Python scripted interaction with the control plane currently being done with OpenStack and you'll have a glimpse into that future.
You also shouldn't forget that this isn't the first time software definition has been applied to networking. Some of you may remember TCL. Just saying, not the first time.
The other element that's driving these advancements in networking can be attributed to the structure of the interface. JSON or similar structure is surely going to play a role in managing software defined elements.
I urge networkers that are concerned about what looks like an uncertain future in networking to explore the pieces that make up the software defined element. This is the path to value for the individual with Software Defined Networking.
Take a course, read a book, grab stuff off the web like this and figure out how it's done. You won't regret it.
Other Reading:
No comments:
Post a Comment