Get|your|free DevNet account for access to developer resources, learning labs, and sandbox.
I am a tremendous fan of J.R.R. Tolkien. His books are, without doubt, among the best epic fantasy novels. His characters, races, and the overall world are vast and abundant.
There is a conversation between Frodo and Gandalf, while at the caves of Moria where Frodo expresses his frustration and fear of carrying the ring. It goes like this:
"I wish it need not have happened in my time," said Frodo.
"So do I," said Gandalf, "and so do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us."
In the past few years, the market increased the pressure of delivering more business value at a faster rate. The technology change associated with that shift put a burden on the way infrastructure engineers manage their devices and servers.
The trend began in server administration, especially in Linux ones. However, it rapidly expanded to other parts of the infrastructure. The network is key to providing business value and managing it with agility is fundamental to take advantage of what technology can offer to a company.
As network engineers, we use the gold standard of infrastructure CLIs, the Cisco CLI, to administer our devices. The familiarity that some engineers have with it is astonishing. CCIEs, for example, could probably write every single CLI command from memory.
But things change, and technology evolves. The old ways of operating the network are rapidly becoming obsolete. The CLI is excellent for troubleshooting or small changes, but in increasingly complex infrastructure it is not feasible to only use the CLI. Today, the network is programmable. Key functions are automated. Network engineers are network programmers and need new tools and most importantly...APIs.
That is where I make the comparison between networking engineers and Frodo Baggins -i.e. wishing that this change had not been thrust upon them "in their time." I have talked to many engineers and hear their frustration and fears of being left out in that change or that their CCIE is not as valuable as before.
However, although the change might be scary, there are a lot of reasons for not worrying too much.
The first is that knowledge of key concepts is still immensely valuable and probably even more so than before. When your infrastructure is more complicated, taking the proper approach to designing a change -a network refresh, or defining how you are going to operate it -is more complicated. Having in-depth knowledge of how different protocols or devices on a network function is core to making the right calls.
The second one is that Cisco already defined the gold standard for infrastructure CLIs and building on top of that proven track of innovation and execution, invested in improving the management of their devices with the best platforms and APIs. The investment Cisco has done in the past years around programmability and APIs is second to none. It has acquired companies built around these concepts (Tail-f) and contributed to open source projects like OpenStack, always keeping a significant focus on integrating their products with modern technologies like NETCONF, RESTCONF or building APIs on their platforms like the REST APIs we can find on several recent products like DNA Center.
But, where is Gandalf? Where is that wise wizard that guides Frodo and reassures him that everything is going to be okay, and that what the network engineers need to do is "decide what to do with the time that is given us." For me, there is an excellent team within Cisco that is leading this transition and guiding those interested in making the necessary adjustments in their career. The DevNet team is the Gandalf in this analogy.
They have done a fantastic job in the last few years understanding the market transition, producing the content to bring the traditional networking engineers up to speed with the new technologies and building the necessary sandboxes and learning tracks for the network engineers to practice and learn.
The people that make the team have some of the mystics that you identified in Gandalf. Some have even re-invented themselves to become API evangelists or developer advocates, and right from the start with the same risk-taking attitude and willingness to question the status quo.
There and back again is the subtitle of The Hobbit. It summarizes the journey that Bilbo takes leaving the Shire, experiencing great adventures and getting back to the Shire and writing his memoirs. There and back again is what we network engineers are doing right now. We have managed mission-critical infrastructures during our careers, now we are on a journey of new technologies, programmable infrastructure, and platforms. Once we have a grasp of that, we can get back to what we do best - i.e., innovate in the network, run mission-critical operations, and provide business value.
Change is hard, but for an individual, it is impossible to control when change is going to happen in an industry impacted by market forces.
As in the Lord of the Rings, what we have to do is decide what to do with the time given to us. Not everybody needs to become a developer, but everyone needs to understand the new technologies and how they can be leveraged to benefit a company. Frodo always trusted in Gandalf and counted on his advice; I feel the same way about DevNet, a group of experts in the industry leader, focused on helping networking engineers in this transition.
There and back again to what we do best, connecting the world and empowering the people.
I started on this journey a while ago, if you have something to share I would love to hear it and collaborate with you, please contact me at @josebogarin on twitter or join me in the Webex Teams DevNet Support space.
And if you haven't done it already, get your free DevNet account for access to developer resources, learning labs, and sandbox.
We'd love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Twitter @CiscoDevNet | Facebook | LinkedIn
Visit the new Developer Video Channel