The Team Behind Nautobot, Part 1: Source of Truth, Apps and Why Nautobot Exists

Welcome to Network Automation Nerds podcast where we explore the latest in network automation from a practitioner's perspective. I'm your host Eric Chou, a network engineer who loves everything about network automation. Today we got a special treat for all you network enthusiasts out there. You know, the kind of people who dream in subnets and whisper to your routers with BGP advertisements. We not only have one. not two, but three authors behind this upcoming book, Network Automation with Nautobot in the virtual studio with us today. I feel very special. And I hope you guys will enjoy this episode as well. We'll dive into the heart of Network Automation, the source of truth if you will, and how the book offers some hope for those of us who lost in the sea of cables and configurations or what they would call Network Source of Truth and what the book can help you and help us with our projects. And full disclosure, I am an employee of Network– and we'll leave some more time for our special guest, John. Go for it, Jason.

Yeah, thanks, sir. Much appreciated. I'll try to keep it short, although that's hard these days. My short version, kind of getting into networking, goes back now. It's crazy to say, 24, 25 years, my freshman year in college, somebody gave me the Todd Lammle Sybex book of CCNA. after Christmas break and that was January, probably of 2000. And I was obsessed. I read it everywhere. I brought it everywhere on these trips in the back of vans. That was probably the tipping point for me. And I just from there kept reading more and more and more and dove into networking. I probably gave like a quick glimpse and then 13 years later, Cisco launched onePK and that ended up becoming the start of my entrance into what became network automation as well.

Awesome. And I'll take it from there as Ken, very similar to Jason started in 2000. I joined the Air Force right out of high school and kind of fell into the network engineering role. I did talk about it on episode 24 with Eric to great details. My actual initial intention to join the Air Force was to go to the programming and that didn't work out and kind of ended up more in the networking realm, but I kind of carried with me that programming persona the entire time. So for the last 24, almost 25 years now. I've been doing both networking and programming and then obviously full-time network automation since I've been here at Network to Code almost about eight years ago now.

Yeah, what about you

Thanks for having me on, John Anderson. Yeah, my background is somewhat similar, but maybe a little younger, a little different. I was that nerd back in high school that would hang around the guy that did all the IT at the school and became his buddy. And that's kind of what I did, right? Learned what a switch was, learned what a router was from him, helped him do like AD forest migration from like Windows Server 2003 to 2008, that kind of thing. taught myself how to write PHP and built some auction management software back in the day. Then went to college for computer science. I really fell in love with the academia part of it and kind of used that skillset that I had built up at that point to get my first, you know, I'd say real job working at the college. And that kind of turned into a full-time gig. I'm starting out as a wireless engineer at the College of Charleston. Worked my way up into the wired world too. And then eventually into network security while I was there and really loved that domain. And of course all the while, you know, working through, you know, formal computer science degree as well. And did my master's at the college of Charleston, also in computer science. But that network security side was really interesting because that was kind of my first foray into this problem domain of, you know, I've got all of this data. right, that kind of backs these application flows and, you know, how services are talking to one another for these firewall rules and so forth. And how do we manage that at scale? So, you know, build some software to help understand firewall policies and, you know, denormalize those data structures and so forth. And really what I was doing without realizing it was network automation. And that got me into the network to code community within Slack. You know, I forget what my on our public Slack there, you know, got to meet Ken and Jason through those forums. And along the way, I also became a maintainer of NetBox with those folks was a maintainer for a while when I joined NTC as well. And then Nautobot to be and the rest is history.

Yeah, by the way, John, I threw up a little bit in my mouth when you mentioned PHP, but I'm okay now. So I'm good. because it's audio only, but your background is the sky, right? So you're also big on aerial engineering. You know, tell us a little bit about that. I think that's very interesting to me. So tell us a little bit.

Yeah. I'm a instrument rated private pilot. I love aviation. I'm an avgeek. Yeah. I love all of the technology surrounding that. I love hacking, ADS-B ground stations and so forth. For those that know about that and that's how flight aware works and that kind of stuff. Yeah. It's an interesting domain. very different than networking, some of the same paradigms actually underneath the hood.

I think last time at our company, all hands said, you gentlemen Eric, correct me. But one of the things we talked about was, you know, what do you do for fun? When John came up, he actually said, I'm building like an actual plane. There's this huge wing in a picture in front of his garage that's probably bigger than my car. So he's a total aerial geek.

Yeah, I love building stuff, software, RV, airplanes, all of it.

Yeah. So John, you mentioned, you know, you were a very low number on the user ID for network to code. So I wanted to go back to the beginning and ask Jason, for those who are listening who are not familiar with network to code, can you tell us a little bit about network to code, the company, the formation, the mission, that sort of stuff?

Yeah, yeah. I'd love to. And I would say like the TLDR is sort of like the summary is as a company, we kind of bridge the gap between DevOps, software and networking. That's kind of the high level summary helping customers sort of on their journey. But in 2024, we're 10 years old. For the last 10 years, we've been helping large enterprises. It really transformed their operational models through network automation, right? We kind of do that through a combination of services, everything from training, professional services, managed services. And really in software, right? I would say the past three and a half, four years, really double down open source software around all about and building solutions that really accelerate driving customer outcomes. Right. And for us, you're kind of solving problems, data management. I'm sure we'll talk about quite a bit. Config compliance, observability management, those are some of the, some of the common themes that we're seeing right now as a business, but Yeah, the overall mission and vision is really to automate one network at a time and really to transform this industry that hasn't changed all that much operationally in the past couple of decades.

Yeah, I would say unfortunately, right? Haven't changed all that much. So for those of you who doesn't know, right, Nautobot is relatively new, but the history actually goes beyond that. So why don't we start with a little bit about Nautobot, what it is and why do we need it?

Yeah, so Nautobot exists to service really two primary use cases. And more importantly, it's the marriage of those two use cases that I think is really why Nautobot exists. So the first is to form a source of truth for your network data. And what that means is we provide a primary data model that allows you to do things like tracking your device inventory, tracking the sites that those devices are deployed into, tracking the prefixes and VLANs and interfaces and the interconnection between those devices and so forth, right? but that data model is also extremely extensible, right? So we know every organization has different data requirements, different ways that they want to model their network, different use cases about the network that, you know, maybe they need to add new data models. Maybe they need to extend the available fields that are on an existing model that we provide or something like that, right? So we have a whole extensibility feature set about customizing that data model for your organization's specific needs. And the whole point is to really centralize all the network So it's not just that we're just a data lake, we're a data hub, right? It's the interesting relations between that data. So I mentioned like the interconnection of the devices. Like we model that as if it were the real world, right? Like you're connecting Eth1 on this switch to the uplink point on the router, right? And you actually get that relationship and you can apply the layer three IP addresses that exist on those two interfaces, right? That forms the relationship that you would then use to actually configure those two devices, right? So it's not just data that exists in an Excel spreadsheet or something like that. And then we're just throwing it in a database, right? Like we've taken a lot of care in thinking about this relational data model so that it can be both usable from a management standpoint, but also from an automation context. And that's a good segue into the second use case for Nautobot. It's the automation platform. So in concert with all of the data that you now have access to, we give you. this really powerful platform for building these automations. So we mentioned things like config compliance and remediation, right? So we can take that data. We can build the configs. We can build the understanding of what the intent should be from our business policy. And we can pull in backups from our network and we can do the comparison, right? We can build those plans to say, this is how we would actually correct those issues and actually go and deploy those. Now that's a recent feature, the actual remediation and in golden config, right? But it's this whole platform about doing automa- throughout the entire maturity evolution within an organization. So I can start with like simple scripts that maybe I've turned over to my help desk, whatever that helps them understand how a port in an office building is actually configured today so they can help someone that's called in with an issue, right? All the way up to that really complex but very powerful config remediation use case that I mentioned as well.

To add one piece to that is this is a term I kind of co-opted from one of our customers. Always think of Nautobot as being not the single pane of glass. but the first pane of glass, right? So it's the idea of like, this is the part you can go to first. I think, you know, one inventory is naturally like that. But once you start adding in all the automation use cases on top of it, I think it really becomes capable of being that. And if you think of configuration management beyond just the network configuration, but things like your network management configuration, your telemetry stack, your SolarWinds. your Splunk, whatever the different assets are that are not network devices, you can start thinking about it much differently. And some of the use cases kind of articulate that it's just kind of direct integration with things like your network monitors, deep links, iframes to kind of point there. And then obviously, we're trying to push some things closer. So it is a little bit closer to the single pane. without trying to encroach on doing things like network monitoring. We don't want to do network monitoring. We want to manage the configuration management for network monitoring. We have some customers with, you know, tens of thousands, hundreds of thousands, even millions of lines of configuration required for Telegraf and similar that we're able to manage it the same way for their network configuration as your network monitoring configuration. I think that's kind of an important differentiator. Let's just think about it as the first pane of glass.

And also want to differentiate between the extensibility part versus the Nautobot core, right? Because I think, you know, in that conversation, we kind of signal the fact that you could do a lot of stuff, but either John or Ken, can you walk us through the difference between out of the box? What do you get and the extensibility functions that goes beyond that

at its core, Nautobot core provides you an out of the box set of data models that allow you to really go pretty far. You know, you've got things like modeling. And we have other aspects of that that come into play for like custom validation logic, right? So it's like, I want to add rules that make sure that my devices follow my naming standards and so forth, right? And that's all configurable to your needs, right? And then for more advanced use cases, and I'm sure we'll talk about it much more in terms of the book here in a moment, we have the app ecosystem. Nautobot is a platform that provides these core functionalities, but it's extensible in that we can install applications on top of Nautobot. Inside of Nautobot and top of Nautobot, however you want to think of it, but these are applications that exist kind of as their own thing and you can pick and choose which ones are important to your use case. These are ones that are open source today or available for network to code and so forth, right? Or you have the ability to develop your own. We have pretty extensive developer documentation that allows you to take a more advanced use case of your own that might be, as an example, developing an entirely new data model from the ground up. Maybe I have a very specific way of configuring my telemetry stack on my routers. I could create a data model specifically for that for tracking those data points. And that would be developed as an app that would then install into my Nautobot instance. Anything you add there, Ken?

Yeah, I think the thing to think about in terms of accessibility is just there's kind of multiple levels of accessibility there, right? There's things that you can do from within the UI that will happen immediately. There is extensions that you can build to extend it and really make it feel integrated. And then there's kind of full apps that you can have, you know, to do whatever it is you want. Right. You know, like as an example, let's say, you know, right now we have like BGP models published. If you want OSPF models, that's an entire new data model that you can add yourself and it can look and feel to anyone else who is using the system. Like it's fully integrated. It doesn't feel any difference. And the other thing I'll mention is many of the most popular applications out there, I think of things like. ServiceNow, Ansible, and stuff like that. They all have a very similar construct, which is maximum extensibility. And you think about Ansible, you kind of open up Ansible, there's nothing there, but there's just a whole bunch of like Legos to kind of put together and you can build it out. And if you look at like ServiceNow, you open up and you have things like incidents and change controls and so forth. But then there's still the entire Lego blocks. And we're kind of very similar in that, which is You open it and you get a whole bunch of stuff right out of the box. But pretty much whatever you want to do, it may not be good all the time for those things, but whatever you want to do, there's a place to do it and you can make it feel integrated. So I think that app ecosystem is kind of commonplace between what's happening in the industry.

Yeah, I agree. I think one of the things that impresses me the most about Nautobot is… When you have an app, it's a first-class citizen as far as navigation, as far as side views or data integrity. It's a first-class citizen. So it doesn't feel different even for branding purposes, like if you have your own logos. And so I think that's part of what you gentlemen talked about. Out of the box, you get a core set of functions where we think it's important. It's pretty opinionated, but also you could extend it either with custom fields, tags. or a fully feature, Nautobot app, that's a first-class citizen as well. So yeah, we'll talk more about that. And with that complexity, with all that moving parts, that's why we need that book, right? Like that's why we feel– we're jumping ahead ourselves a little bit, but yes, for sure. Right off the bat, I want to also touch the elephant in the room. And this is also covered in Heavy Networking, episode 610. And we'll have the link in the show notes. And I want to go back to Jason on the very beginning of Nautobot and say– Why was Nautobot forked? And how is it different from NetBox? So take us through that Jason.

There's a few things. One, you know, I'll kind of kick us off and it's always great to get, you know, John and Ken's thoughts as well. But I would say I'll call off two or three things. One, you know, I do think if you go back a couple of years, right, it's been almost three and a half years. And so we're kind of talking about all processes that we had, you know, again, three and a half, four years ago. because there's clearly lots of discussions kind of leading up to the date of the actual announcement of Nautobot, right? So yeah, maybe three and a half, four years ago. First, I think for us, it's recognizing the relationship between networking data and network automation. That was critical versus looking at data for data sake or for data for documentation. Now, I think that's a great natural first step, but I think… Given who we were as a business for the prior five or six years, it was seeing that connection between data and automation. I'd probably say, secondly, it's all that we've just heard from both guys on the ecosystem. You look at data's connection to automation, and then realizing the value and building out what we call now an app ecosystem. If we go back a couple of years, the original name, we had plugins and things like that, but now we have a Nautobot app. I think for us, you hit the nail on the head, they're first-class citizens. Users shouldn't care if they're logged into a Nautobot, if that's via an app or something or part of core. It's just added functionality, taking advantage of all this rich data. that's inside a Nautobot because we're modeling Again, John earlier said the word model, you know, probably a dozen times when he was kind of given the pitch, we're modeling more and more data to define, you know, what we call it this intended state of the network. And so if we have all this data, let's take advantage of it to build automation around it. And we'll talk about a Nautobot app could be a lightweight automation or it could be a full blown application, but it's that recognizing. the value of sort of this ecosystem that sits on top of Nautobot. I also think I kind of threw it out there. Well, two more things maybe. So third and four, three, we wrote a blog three and a half years ago. I always bring it up because it does have, you know, a lot of the long form, you know, reasons for what was going on back then. But finally, I would say with where we were then, and even now when we look at, I would say non-technical differences or call them differentiators. Clearly, we're a little biased, but I kind of look at it as like what we're hearing every day, right? From those we engage with on the customer front. It's our people, it's our teams, network to code, right? For 10 years now, we're helping our customers. When I say get into production. And to do that, I think we've learned a lot of what it takes to build solutions, to get into production meaning, yeah, sure, there's installing Nautobot, but then the integrations, there's apps, large enterprises, they all have unique requirements. And it is hard to have that one size fits all solution. So I feel like our team, our people combined with a Nautobot is what differentiates. right us in the market.

to exactly your point, we're primarily a professional services company. So what you see in Nautobot is obviously the wants and desires of our customers in terms of what's needed to deliver solutions for them. But it's also, I think our projection of those needs onto the broader industry trends and wrapping that up into a package that we do open source back into the community. And the other point I'll make is at the end of the day, competition is healthy, right? And competition really drives both

I think about the entire ecosystem and we're talking about apps and that's a huge part of it. But I think beyond that it's things like Helm Charts and pynautobot and Nautobot Ansible and you know, just the developer environment. There's like, we have a Docker compose environment. Like I use this every day. I spun it up and down like 10 times say it was, you know, unique circumstance that most people wouldn't do, but it was within seconds I'm able to kind of spin up, have data, all this other fun stuff there instantly. And it's just kind of that entire ecosystem. It's the looking at it, we are developers, right? We want to make our own processes simpler and we concentrate on that. And we, you know, we tried to build the documentation and everything else and the code to emphasize that. And that is a big part of what we do. The last thing I'll say is just like at being on PyPI, right? Just being pip installable, like made a difference for us for how we can get integrated to customers because they don't want to allow things from, you know, they don't actually have GitHub open. that little difference could save you weeks when it comes to your access concerns with customers, which is very challenging, right? Enterprises, if you don't have that and your satellite server is not configured to check GitHub, well, that's it. All you have is PyPI, right? And these are the types of things that allow us to be more efficient and allow our customers and thus allows the community to be more efficient. And maybe last thing I'll say is just really to echo what John said, which is it's really based on the need. Like what we're seeing is based on what we see and we are integrated into a lot of customers. I think it's safe to say that we're integrated to the most customers for network automation. I don't think anyone would claim otherwhys. So we see a lot. We learned a lot. It's tough. You learn and you pick up these pieces and you understand where are the things that the customers and thereby proxy the community is looking for. I've been saying this a lot lately. You know, sometimes you never get that moment to kind of like just have that high five moment, oh, we solved this problem because it kind of solved it and then it permeates out over time. We don't think about things being pip installable anymore. It's so long ago, but it was a challenge for so long. But you never got to sit there and celebrate that moment of like, okay, we solved this problem. You're just on to the next thing, right? But there has been so many, many challenges like that that have been solved over the years.

Yeah, that's great. And I still hear this question. I'm sure it drives all of you crazy. So I'm going to answer it once and for all. Is Nautobot Open Source? Yes, 100%. Yeah, I know, right? Like, why still here as if we're kind of hoarding or like more commercial focus, but Nautobot is 100% open source. And what I've heard the biggest differentiator is Network to Code actually takes all of the knowledge. and aggregate all the customer needs and feed that back into Nautobot. And that is to me a higher priority than maybe some other different versions to make it. Is that an accurate statement?

Referring to different versions of like enterprise variants?

No, I'm referring to NetBox. Is that the driver for charting your own path for Nautobot is because…

we think that should take a higher priority. The network automation use case being a higher priority is kind of one of the biggest things. And I think one of the things to understand is like configuration management is a first-class citizen for us. That's kind of core to what we're doing. And that changes your philosophy if you think about it differently. And I think taking that ownership of the entire ecosystem helps tremendously because we have pains at times in terms of when we make a change. and affects the ecosystem. We have to deal with that ourselves, but we have to deal with things. So we're responsible for that entirely.

Like I said previously, we're a professional services company first, right? We're not a software product company. We're not structured to be, we don't pretend to be. So moreover, what Nautobot really is to us internally is it's kind of that services delivery platform for our customers, right? We build solutions that are specific to our customers' needs. on top of Nautobot, right? And that gives us a platform to what Ken is talking about in the ease of getting it into environments so far. That gives us a way to really reduce the time to value for our customers for those solutions that we're delivering for them. And it just so happens that a lot of what we build is in the open source space.

Cool. I think we should focus on obviously what Nautobot is and its advantages, but I know the question has been. you know, kind of lingering. And once again, I'll refer the longer version back to episode 610 on heavy networking on the longer answer of the whys. But we could definitely move on to what Nautobot today and why do you feel the need for a book? So, you know, part of what I heard so far is all of these extensibility, all these complications, all these aggregation of knowledge makes Nautobot kind of complex to launch. Right. Is that an accurate statement or do you guys agree? Disagree?

I don't like the word complex. I like the word advanced, it's an advanced system. And yeah, look, it's part of it. I just go back to, you know, I've been fortunate enough to be a co-author of another book that, you know, from O'Reilly that came out a couple of years ago. I honestly, it boils down to a few things. One, yes, there's no doubt it's going to help on the Nautobot journey, the network automation journey. But in general, I look at a lot of the work we've done now over 10 years in the community. and just recognizing the industry needs change and all the different ways to be able to engage in the community, give back and so forth. And just, again, really transform the industry. I think it comes back to that where over the past couple of years, we're seeing the growth in open source. We're seeing the growth in Nautobot and it's saying, well, what else can we do to try to continue to enable that at a global scale? And I think one piece of that as of late and why we're doing this is this latest book on Nautobot.

To that point, I don't think the application itself is any more difficult to install and operate than any other enterprise app these days. But it's more so about once you have it set up, what do you do with it? How do you use it? How does it become useful to you? That's more, I think, what we're concerning ourselves with. Anything to add, Ken?

Yeah, just for the book, I'll say the documentation is very good. It's pretty thorough. But the book is a narrative form, right? It's kind of like taking you through the journey of what you do. It's not like a dictionary form, right? Which is this is the attribute to use for custom buttons. You know, this is, you know, this is the very specific thing. You know, once you know where you're going, you can kind of use just the documentation. It is hard to kind of go through there. It's great to kind of learn from someone else's narrative. Start with the basics, how do you install it? And then how do you populate data? And just kind of go through that entire narrative form.

Yeah, I thought the book was a great idea. And for me, coming in new to the company, to the product, it was a tremendous help as a reviewer, as someone who's new to the project, to go through that narrative in a beginner to more advanced format. Well, thank you guys for giving me the opportunity to be a reviewer. I think that's a great time to end our first episode. I know in the next episode, we're going to go specifically into the book a little bit more. So stay tuned, guys. Thank you for listening to this episode of "Network Automation Nerds." Do you have any feedback for "Network Automation Nerds" or this episode for our guests? Send me some follow-ups at packetpushers.net. That's for a follow-up. I want to hear from you. Check out our website at packetpushers.net to find other Network Engineering focused podcasts, blogs, YouTube videos, or Slack channels. Hey listeners, exciting news. As mentioned before, Network to Code will give away copies of the Network Automation with Nautobot book we discussed in this episode for 10 lucky winners. Please visit Network to Code for details. The URL will be in the show notes. Last but not least, remember that too much network automation will never be enough.