The Cisco Developer Days are a two-day event bringing together service provider and enterprise network automation professionals from around the globe, sharing best practices, experiences and learning about new trends. This year Flint IT Architect Marko Zagožen joined in the fun and was invited to speak on how to simplify device management in an NSO environment.
The fifth annual Cisco Developer Days were held on September 14th and 15th, 2021. Due to current circumstances, the sessions were held virtually for a second time. Attendees were able to attend ten sessions about Network Automation to learn more about new features, tips and tricks and best practices.
Flint IT Architect Marko Zagožen was selected to speak on day two, sharing useful insights on using declarative configuration management in an NSO environment. Marko was one of only two speakers outside the Cisco corporation invited to the event: “It was an honour to be on the other side of the ‘podium’ this time. I am looking forward to meeting everyone in person again soon.”
Marko, could you tell us a bit more about your session’s main focal points?
My session at the Cisco Developer Days intended to introduce the device automaton NSO package to a wider audience. I first created the package in collaboration with my colleagues at Deutsche Telekom for internal use, but then we decided to release it as an open-source project. In a nutshell, it is a service that greatly simplifies the steps needed to add a device to NSO and making sure NSO can always connect to the device throughout its lifetime. What was previously a complex dance of creating configuration then executing a series of actions in NSO is now a simple service instantiation, possible in a single transaction. In the session, I quickly demonstrated the declarative interface exposed by the automaton package – adding a new device with a single management address and then changing the management credentials. The emphasis is on showing the ability to just change the service configuration and then observing the device automaton perform the iterative steps needed to reach the goal – change the management credentials. This is of course just the tip of the iceberg; the automaton package has many more features related to device lifecycle management.
Where can users learn more about the package?
At the end of the presentation, I invited everyone to try the package at their own pace in the NSO reservable sandbox hosted at DevNet Sandbox labs. The instructions on how to get started are available in the public repository. I also plan on recording a series of short videos introducing different aspects of the package.
What are your key takeaways from this year’s Cisco Developer Days?
A lot of work went into creating and curating content for new and experienced users. To really master a new concept, the best way to learn is to practice it yourself. That was the focus on Day 2 – the Learn by Doing track led by Jason Belk. Jason introduced the new NSO Dev Center website that links to all the content that was presented in the track and more. A lot of examples use the Sandbox Labs, so you don’t really need any lab equipment to follow along.
The continually growing demands of today’s networks have made network automation and orchestration a necessity. What are the main benefits that network orchestration tools like NSO bring?
I see Cisco NSO as the impedance matching device. Nowadays, networks and infrastructure in a broader sense consist of many components often provided by different vendors. Even within the same vendor ecosystem, the capabilities for programmatic device management can differ wildly across platforms. As a concrete example, I work with a service provider that used NETCONF, CLI and SNMP to manage their devices. To complicate matters even more, this is a multi-vendor environment where many of the components are viewed as interchangeable – replacing the core router with an equivalent model from a different vendor and a “should just work” attitude. NSO helped us bring all the devices management interfaces on the same level. It took years for all four vendors we worked with to provide a NETCONF management interface on their network equipment. Of course, the network existed before this happened and we used NSO to create services that are vendor and management protocol agnostic. After we obtained the new software versions from the vendors, the transition to the new management interface was seamless from the perspective of the users of our services.
You are also an awarded winning Cisco certified instructor. What advice would you give to an engineer that is just starting out on their NSO journey?
The quickest way to get started with NSO specifically is to use the content available on Cisco’s NSO Dev Center. Of course, there are instructor–led and self-paced classes available as well for those that prefer those methods of learning. The second piece of advice is that NSO does not exist in isolation, so do not dismiss other tools or products even if their functionalities overlap. By having more tools in your figurative toolbox, you will be better equipped to make an informed decision on what to use when the time comes.
Commenting on the first part of the question, I view being an instructor as complementary to my daily responsibilities. My background is in software engineering. One of the best decisions I made (or rather was gently but persistently encouraged to make) career-wise was to become a Cisco Certified Systems Instructor (CCSI). It’s one thing to write code but another to explain the concepts in ways that others can relate to.
And when would you advise a company to look into orchestration tools?
It is very likely their operations team already uses some form of automation for their daily tasks. Many of the popular open-source products for infrastructure automation can be integrated into an orchestration solution, be it from the same vendor or a more generic platform, like NSO. These efforts should be driven by business needs. Orchestration tools help reduce the costs of delivering the requested product or service to the customer. Building complex systems is a noble pursuit in and of itself, but in the end, someone must be willing to pay for them.
Where do you see network orchestration tools going in the future?
Tools that bring together different domains will have an advantage. Even today, many services offered may include Virtual Network Functions (VNFs), so a tool that understands the underlying infrastructure as well is going to be more interesting.
At Flint, we are very proud that our engineers work at the cutting edge of technology and search for and develop customised solutions that make our customers’ (business) lives easier. Sharing our knowledge with our clients and the engineering community makes us even more excited about the work we do.
Do you struggle to find the right tool to optimise your network automation, or would you like to know more about the device automaton NSO package Marko created? Contact us!
For more information, articles and updates follow us on LinkedIn.
