DevNet authors discuss Cisco DEVCOR book, automation

The Cisco DevNet certification track reflects the broader changes occurring within the networking industry.

Networking has mostly moved beyond the conventional command-line interface and manual management and now follows a trajectory toward software-defined networking, automation and DevOps. The DevNet certification focuses on these concepts, exploring how networking, programmability and software development build on one another.

While software, APIs and working with code might seem like daunting topics to network practitioners, they're worthwhile investments -- and it's possible to overcome the intimidation with a mindset change, practice and study guidance.

That's where the authors of Cisco Certified DevNet Professional DEVCOR 350-901 Official Cert Guide, from Cisco Press, enter the scene. Most network pros who follow Cisco certifications and DevNet closely have likely encountered the names of Hazim Dahir, Jason Davis, Stuart Clark and Quinn Snyder.

Experts in their fields, the authors are no strangers to automation, continuous integration and continuous delivery (CI/CD) and network management. They understand what network engineers should know to collaborate with application and security teams and build networks that better support business applications. Here, they discuss DevNet challenges and the intersection between networking and CI/CD and provide advice for candidates studying for the DevNet Professional exam.

Editor's note: The following interview was edited for length and clarity.

What are some of the more challenging aspects of the DevNet track?

Quinn Snyder: If you're coming from a network infrastructure standpoint, the hard part is learning all the software development lifecycle things -- writing good code, writing secure code, writing all the bits and pieces you learn in software engineering classes.

Click here to learn more about
this book.

If you look at how you start as a network engineer, you're studying your CCNA [Cisco Certified Network Associate] or CCNP [Cisco Certified Network Professional], and you're getting to work on the same gear you're studying at night. Now, you have to make a conscious effort to practice these principles because you may not be able to use them in your day job. So, it's that much more intimidating to get started.

Coming from software development, computer science or engineering, then it's understanding all the different parts and pieces of Cisco's portfolio and how they play together to make packets go back and forth across the internet.

Jason Davis: The traditional network infrastructure engineer, especially one that has a long-tailed career, is going to be more comfortable with a primary interface that has been perpetuated for years, which was the command-line interface. When we look back eight or nine years ago with software-defined networking, or SDN, that pivoted the idea of having to manage every device atomically through a command line to managing thousands, tens of thousands and potentially millions of devices through controllers, then APIs and network programmability.

That shifted the mindset, and some traditional network engineers are having to learn that you can't scale if you have to type everything. I call that finger-defined networking, or FDN. The ability to pivot your mindset to learning Python, APIs, REST interfaces, the authentication, data encoding that's necessary -- whether that information comes in XML format or my favorite JSON-encoded. And it is a mind shift.

How are network practitioners stepping into automation?

Hazim Dahir: There's a strategic shift from companies and large enterprises as they deploy networks on a global level and have this standardization of processes and procedures. We started programming the network, but now, we're programming the network for an application or business purpose.

In a top-down or bottom-up approach -- any way you look at it -- there's a strategic emergence of the DevOps teams that sit in the middle and manage the entire infrastructure. They also provide the environment for deploying capabilities to facilitate business processes or applications.

That strategic emergence of DevOps teams was initially a convenience. Now, we're seeing that line blur between DevOps teams that weren't related to or interested in the network -- now, they see these environments they deploy require storage, compute, network, security. All these things have to be optimized, deployed, configured and programmed simultaneously because it's a whole environment or workload.

Davis: Cluing in on using commercial tools or rolling your own, open source and all that -- it's a valid question. Different companies have different investments in people, processes and tools, so that's going to dictate what they do.

I'll give you a recent experience from when we had our Cisco Live event. I was responsible for helping with automation, monitoring and dashboarding all the technology we use at our Cisco Live event. I get to wear a customer hat, in a sense, for the show.

Of course, we used our own commercial management tools -- DNA Center, Prime Network Registrar, the ACI APIC [Application Centric Infrastructure Application Policy Infrastructure Controller] controller. But we also had other solutions that helped support the event: VMware vCenter, the NetApp OnTap management tool. IT service management isn't just networking; it's a lot of things. We used the commercial products, and then we looked at them and said, 'Is this enough? Or are there gaps we need to fill in where we want more visibility or observability?'

Snyder: One trap a lot of people fall into is they're focused on, 'We want this to be platform-agnostic, and we're going to roll our own tooling because that means we can take out a box by this vendor and replace it with a box by that vendor.'

Even if you're not using commercial management tooling, there's still a cost associated with having to retool to a new platform. You have to figure out what is enough and where you need to extend it. Sometimes, it's rolling your own, and sometimes, it's taking a vendor's product, extracting data out of it and gluing it together with APIs and Python code.

Stuart Clark: When you go to the roots of GitOps principles, one of the 10 commandments, if you will, is you're able to switch the tools in and out. Say, in your CI/CD pipeline, you swap out Jenkins for CircleCI, or you go from using something that's free, like Jenkins, and you go to a commercial product.

Within network automation, that presents its own challenges. You see that, whether companies are going the DIY way or whether they're using a controller to abstract all that information from those devices. At the end of the day, that's where I like to think network automation is going -- in that we don't care what make the box is.

Meet the authors of Cisco DevNet Professional study guide

8:58

How does CI/CD play with network management and automation?

Davis: People get their feet wet by putting their toe in the water. We can think about CI/CD in grabbing configs and putting those in a Git repo. Through that, I can start to archive and look at differences, and that has a lot of value. We've had network management tools -- it's like configuration management discipline. You can tie together a network programmability discipline of getting that config through NETCONF [Network Configuration Protocol] or other means with telemetry and instrumentation and then drop it into a Git repo. That's the first step.

As you start to make changes to your environment, you might wonder, 'Can I run this through some kind of policy management scanning? Is it running the services the way I define them?' And the next step would be, 'Can I test out an idea?' That's where we might integrate a virtual network and upload that config into a virtual network or digital twin. Sometimes, people talk about a physical network but also have a virtualized representation of it as a digital twin. As I pretend to make changes, I want to observe how that impacts them.

That gets us into the testing aspect of CI/CD. Whether you go full hoo-ha into software development of getting something out into a customer's hands so they can see the sample net or the example configuration guidance, and it turns into SonarQube and Artifactory and all the other things you might do when you're trying to push code out into a repository and have other people pick it up. That's a much more advanced aspect.

Snyder: We talk about CI/CD, and it's like this big, amorphous blob. But there are a lot of different parts to it. There's the integration testing -- the CI portion -- and delivery, and how do you get that code from Git onto your network. We touch on that in the book, where we have these ways you can upload, say, Terraform plans into a Git repository and have it push that configuration automatically to infrastructure.

Beyond that, there are CI/CD pipelines that don't even use a source code manager. There are ways you can have sources of truth in the network that function as a service registry or service liveliness. If a service in your network goes down or a developer rolls out a new version of an application and it comes online, we want the fact that a new application is online to drive changes in the network automatically. And we can do that using API glue and some off-the-shelf tooling to drive network automation, without having someone click a button to do a Git commit. Application developers push an app, and we can we can make the network do things from there.

Clark: Jason was talking about gathering data. One of the things, if you've spent a lot of time in network engineering, is gathering metadata -- being able to use that metadata to record against certain events and things happening in your infrastructure, being able to pinpoint when changes impacted customer service.

For me, that's one of the big values of CI/CD. It goes hand in hand with other tools like telemetry, where you dig into those events and understand what's happening and why it's happening. Because, often, when it's two in the morning and your phone's ringing, you're sleep-deprived. You're wandering around, falling over the cat, standing on the kid's Lego, looking at these things with squinted eyes at two in the morning. Having that data at hand and having some historical record of that can solve a lot of pain problems for companies and teams.

Any final thoughts?

Davis: Embrace network programmability. Get comfortable writing programs. It allows you to use the flexibility you need to do your job.

Snyder: Programming doesn't have to be something where you need to go through this difficult process. Find a project that interests you. Have observability based on barbecue smoking or retweeting whatever information you find fascinating. Simple stuff like that just to get your feet wet and keep moving with it. Because it really can be fun, as long as you find something you're interested in.

Clark: One piece of advice when I'm talking to people about this is consistency. If you're applying yourself to network programmability, keep at it. To Quinn's point, find a little project -- some low-hanging fruit at work. Start trying to solve those tedious task problems, the ones where project managers come to you on a Friday night with a half-eaten pizza, and you know you'll be working late. Try to automate all those tasks away.

Dahir: It's a lot to take in. What we tried to do with our book is not just enable you to pass a test, but also provide you with a methodology to understand the why behind tools and processes, regardless of what direction you take.

Jason Davis

About the authors
Jason Davis is a distinguished engineer for the DevNet program in the Developer Relations organization at Cisco. His role is technical strategy lead for the DevRel organization as he collaborates with various Cisco business unit leaders, partners, customers and other industry influencers. Jason is focused on automation, orchestration, cloud-native technologies and network management/operations technologies. He has a tenured career working with hundreds of customers, worldwide, in some of the largest network automation and management projects and is sought out for consulting and innovative leadership. His former experience as a U.S. Army Signal Corps officer has provided insights to defense, government and public-sector projects, while his extensive work in professional services at Cisco has spanned commercial, large-enterprise and service provider segments. Most of his customer engagements have been in automotive, manufacturing, large retail, large event venues and health care. Jason has achieved Cisco Live Distinguished Speaker Hall of Fame status and is an automation/monitoring lead for the network operations center (NOC) at Cisco Live events in the U.S. and Europe. He resides in Apex, North Carolina, and enjoys IoT projects, home automation and audio/video technologies in houses of worship. Jason and his wife, Amy, have four children whom they homeschool and cherish daily. Jason is found on social media @SNMPguy.

Hazim Dahir

Hazim Dahir, CCIE No. 5536, is a distinguished engineer at the Cisco office of the CTO. He is working to define and influence next-generation digital transformation architectures across multiple technologies and verticals. Hazim started his Cisco tenure in 1996 as a software engineer and subsequently moved into the services organization focusing on large-scale network designs. He's currently focusing on developing architectures utilizing security, collaboration, edge computing and IoT technologies addressing the future of work and hybrid cloud requirements for large enterprises. Through his passion for engineering and sustainability, Hazim is currently working on advanced software solutions for electric and autonomous vehicles with global automotive manufacturers. Hazim is a Distinguished Speaker at Cisco Live and is a frequent presenter at multiple global conferences and standards bodies. He has multiple issued and pending patents and a number of innovation and R&D publications.

Stuart Clark

Stuart Clark, DevNet Expert #2022005, started his career as a hairdresser in 1990, and in 2008, he changed careers to become a network engineer. After cutting his teeth in network operations, he moved to network projects and programs. Stuart joined Cisco in 2012 as a network engineer, rebuilding one of Cisco's global networks and designing and building Cisco's IXP peering program. After many years as a network engineer, Stuart became obsessed with network automation and joined Cisco DevNet as a developer advocate for network automation. Stuart contributed to the DevNet exams and was part of one of the SME teams that created, designed and built the Cisco Certified DevNet Expert. Stuart has presented at more than 50 external conferences and is a multitime Cisco Live Distinguished Speaker, covering topics on network automation and methodologies. Stuart lives in Lincoln, England, with his wife, Natalie, and their son, Maddox. He plays guitar and rocks an impressive two-foot beard while drinking coffee. Stuart can be found on social media @bigevilbeard.

Quinn Snyder

Quinn Snyder is a developer advocate within the Developer Relations organization inside Cisco, focusing on data center technologies, both on premises and cloud-native. In this role, he aligns his passion for education and learning with his enthusiasm for helping the infrastructure automation community grow and harness the powers of APIs, structured data and programmability tooling. Prior to his work as a DA, Quinn spent 15 years in a variety of design, engineering and implementation roles across data center, utility and service provider customers for both Cisco and the partner community. Quinn is a proud graduate of Arizona State University (go Sun Devils!) and a Cisco Network Academy alumnus. He is the technical co-chair of the SkillsUSA - Arizona Internetworking contest and is involved with programmability education at the state and regional level for the Cisco Networking Academy. Quinn resides in the suburbs of Phoenix, Arizona, with his wife, Amanda, and his two kids. In his free time, you can find him behind a grill, behind a camera lens or on the soccer field coaching his daughter's soccer teams. Quinn can be found on social media @qsnyder, usually posting a mixture of technical content and his culinary creations.