Nautobot and the Network Source of Truth

And we're back. And folks, a lot of times as we get to talking about kind of all things cloud native and all sorts of the new stuff that we're talking about, so much of what we dive into is just kind of this general trend of as we're building newer applications, as we're dealing with stuff in the cloud, we're just dealing with things that tend to change and move and evolve more quickly than they ever did before. And while we dive into all sorts of interesting stuff about how do we develop stuff and what languages and frameworks, a lot of times we forget that in order to make all this work, at the end of the day, you've got to get the network right. You've got to be able to sort of match the speed and velocity at which you're building applications or deploying things with the speed and the ability of your infrastructure team to be able to keep up with those things. And today we thought, well, that'd be a good topic for us to really dig into. No better person to help us do that than long time friend of the show, Jason Edelman, who is founder and CTO of Network to Code. Jason, it's been a long time since you've been on the podcast, man. Great to have you back. How you been?

Yeah. Thanks for having me, Brian. It's been a long time coming, I guess it's been almost 10 years and about to be back. Yeah.

you know, we, we first got to know you, we knew you, way back in sort of when everybody was, was doing virtualization you were somebody we had met through the community and you were doing a lot of at the time, again, it's been, yeah, eight, nine, 10 years. A lot of independent consulting work around Ansible at the time, it was really early, but give us a sense of your journey over the last five, six years, and then more importantly, kind of where you've evolved network to code from what was kind of initial to sort of a side project to you to what's become a really robust business.

Sure, no, that'd be great. Yeah, I'll try to give the fast version over the past several years. But looking back at the dates of the shows that I was on in 2013 and 14, those were the years that were really the root of really where I went in my career and what became sort of the nucleus or the root of network to code. And in that timeframe, even on the show, I remember talking about this new Cisco release something called onePK. It was Cisco's first SDK of programming against the router or switch. And at the time it was just eye-opening to see what could be done. And then I think around the same time, I had my first demo of sort of Ansible plus networking. And it was the aha moment of operational models are going to change. And then a few months later, I was on the show in June of '14 and then ended up starting the business in August of 14. So it was really the, the days leading up to it. I kind of look at the last several years and three different phases for, for the business. And really it kind of maps probably to industry maturity too. The first one is sort of like network to code, you know, 1.0, 2.0, 3.0, network to code 1.0 kind of look at it as a 2014 to 2017, very much market exploration. We were doing some early things in open source. Some first customers were large vendors, manufacturers like Cisco. We helped them build. Some of their first Ansible modules for networking, Cisco ACI, Nexus, to name those looking back at it, those years really became like the first few years of NetDevOps, really that intersection of open source, DevOps networking. Now it's more commonplace, but like these were the first three or four years. And in the first couple years of the business, we were probably still shy of of 10 people, right? It was small. But in January of '18, we brought on John Marchese, who is our current CEO. And this sort of takes us to like, Network to Code 2.0, probably for about four years or so, 2018, 2021. And it was just a lot of expansion. I think for us, we were always community driven, still are. But in this sort of 2018 timeframe, what really changed was our confidence and our approach to solving problems at a larger scale. We were helping clients with one-off network automation tasks, even one-off training classes, selling a three-day class, five-day class, doing some task-based automation. And it really shifted to, instead of being more tactical, really looking at things more holistic and strategically to looking at, you know, six, 12, 24 months of services to really help our clients solve outcomes and solve problems. And even looking at curriculums of training, right? Instead of a three-day class, five-day class how do we help transform network engineers over the course of that 12 months timeframe, which might include a few different classes, lunch and learns, labs, homework assignments, really all these things like that.

Yeah, no, it's, it's again, it's, it's, it's incredible to see like how much you guys have grown. I think back to, you know, when I was doing networking stuff and, and, you know, CCIE stuff back in the nineties and all sorts of things. And I look at kind of what networking looks like these days. And it's, you know, it's a combination of probably, you know, a certain amount of Cisco and Juniper and kind of, you know, hardware based stuff you've got software based things that are either, you know, SDNs or other types of tools. You've got networking that's in the cloud. You've got, and then you've got security and a million other things like give us a sense, you know, as you go talk to, I don't know, a large bank or, you know, any, any sort of larger organization, like what is the scope that those guys are dealing with from networking these days? Like how, what does the skillset look like? What's the, what's the scope that they're trying to wrap their head around?

Yeah, you'd be surprised, I would say, even.. even looking back over the last. 10 plus years. Looking back 10 years ago, I thought it was going to change overnight. Lesson learned, I'll always say, being young and naive. Things take time, enterprise space, even mentioning large financials. Things take so long to– get go from lab to production, like the amount of testing, the amount of different application owners, all the different areas of business to really get something new in. So I would say current state. It's still network engineers, so largely focused on network engineering. I think there's been a tremendous maturity in evolving skill sets. And I always equate it back to DevOps, looking back over what DevOps has done over the last decade or more. And networking is still kind of ramping up in terms of that intersection point of Net DevOps. So overall skill sets still evolving. I think there's maturity in controllers and tools. You mentioned SDN. Several years ago, we were in the thick of it, venture backed startups launching by the day. Now, we know the controller model, the SDN model. It is the more common path forward these days, right? In terms of just simplifying the overall management of networks, right? Instead of managing end nodes, you can manage a controller. It's probably one of the more common pervasive trends is as tech refreshes are happening in the networking space, by and large, there's a lot of those controller platforms being– being looked at. And so I do think it's helping overall operation. I would say even with where we're focused and network automation, it's still about thinking about the root of the workflow, meaning what's causing somebody to log in and perform an operation. Because over the past decade, there's been a lot of talk around things like the death of the CLI and things like that. And the way we think about it is if you're in the CLI or even the UI, There's probably a different way or a better way to be doing things, right? In terms of understanding why somebody is logging into a device or controller and thinking about the larger workflow at hand and just bubble it up to see what makes sense. Is it a self-service portal? Is it a GitOps workflow? and really just try to marry it to the culture, but skills, yeah, still evolving quite a bit. I don't think we're anywhere near where we need to be as an industry for the mass adoption of NetDevOps, if you will.

Yeah. You and I were talking not too, too long ago, maybe a couple of months ago, and you were kind of introducing me to this newer sort of concept. Maybe not, it's not really a new concept in terms of IT, right? We've always had.. various sort of single sources of truth. Some people will call them CMDBs. We had them for applications and asset management, but there's kind of becoming this evolution of like a network source of truth. Give us a sense of like, what does that mean? What all is in that source of truth? And how's it figuring out how to give a much bigger picture for people of what their networks look like and how to manage them and stuff?

Yeah, no, it's a good question. I think, you know, based on, you know, somebody's journey in IT, there could be a different perspective of when you mentioned even CMDB. But I would say given the trends that we're seeing around network data and really thinking about the concepts of a network source of truth, it's about defining the intended state of the network. Focus on data. I'll go back to if you look at a system configuration or a network device in Cisco or Juniper Again, a lot of engineers are still in the CLI at some point and you're looking at CLI syntax and commands, but really separate the two in terms of syntax could be API calls and the data itself. And the data ideally should be vendor neutral, right? It could be, when you think about data, easy ones could be VLAN IDs, IP addresses, BGP ASN all this data that is used to drive policy configuration typically a store today, right on spreadsheets. You might have some CMDB deployed, ServiceNow, Remedy and so forth. But the general trend right now is to really.. get a hold of your data, of the network data to be able to define it in a source of truth that could later drive automation. And so I look at it in terms of like the overall probably steps to get there going from zero automation to, if I even use the phrase fully automated, typically it's a matter of, hey, let's get rid of these spreadsheets. Let's get a hold of our data. Let's have a place to document the network of what it should be. And it can start with inventory, it can wrap up from there, it could be configuration data as an example and then get to the point where it's trusted. And then it becomes really valuable to then use that data to actually drive automation, take it to the next level.

Yeah. Yeah. One of the things that you introduced me to was, was a project, that, that you're heavily involved with. And I know you guys have been, kind of shepherding through an open source community called Nautobot talk a little bit about that. Where did it. Kind of where did it get started? How's it evolved? How are people using it today? What all can it do? Yes

The history here is probably just over two years old. We launched Nautobot in February of 2021. It was actually a fork of another open source project that we were working with back then, like anything else in open source. There's divergent, visions and strategies. A fork is always an option. We had a hard fork in another project. And so, Nautobot at its core is a source of truth. And so the goal is to store the intended state of the network inside Nautobot. Give the analogy of almost like a smartphone sometimes in the sense that a phone, a phone or a smartphone at its core. It's a phone, but you have these highly productive apps on top of your phone. And so back to Nautobot is its core is a source of truth or a data store to store the intended state of the network. And through the accessibility that we built into the platform, we now could build what we call, Nautobot apps old terminology is Nautobot plugins on top of Nautobot to really use it as an overall automation platform itself. So you kind of get best of both worlds in the sense that. You know, we have users, you know, fairly large in nature that might opt to use Nautobot as a data store to drive network automation, right? They might deploy other tools to drive automation. And then you're going to essentially fetch data from Nautobot, use its APIs, you know, build them to configurations and then push them to your device as an example. That's primarily.. the source of truth use case. And even in that use case, there's integrations and things like that to be able to synchronize data from other data sources. So it's not about being the authoritative source for everything. If you already have a circuit database, if you already have inventory in ServiceNow, let's say, or Infoblox IPAM, there's ways to streamline the aggregation of data. But the other use case I was mentioning around the smartphone analogy is around, you know, we've really made it streamlined to build apps on top of Nautobot within the platform. And I would say from like a UX point of view first is if you were looking at the UI of Nautobot Apps and plugins allow users to really inject dropdowns, menu items, build build APIs, add data models to the database and in effect, then the apps that you build could also drive automation. So we have, I think right now we probably have a couple dozen open source apps as well. One of the more common ones is the compliance. Again, all of these open source to get started with and can take advantage of it really as fast as you can kind of get it installed. And but customers though, you know, there are.. community users, they're building apps for a variety of use cases, right? Just to tailor automation to meet their needs. Even if they're adopting other tools to do automation you know, by and large, what's happened, had the thought is you buy you purchased a tool, there could be a gap in it. And how do you get around the gap? And again, open source extensibility really helps users own their destiny and take control. And so apps can really do whatever might be needed, data models only, APIs only, UI views only, or really building a full fledged app like the compliance as just one example.

Yeah, no, and it makes a ton of sense. I mean, it's as much as… It's sort of the classic example of you go into a lot of environments and 80% of them will be similar. They're following certain best practices and so forth, but it's always that other 20% or so that allows the business to either do something really unique or match what they want to do. So yeah, the fact that not only is it open source that allows people to do kind of whatever they want, but the fact that it's built as a platform is really, really important. What are some of the things that, when people come to you with problems that are kind of immediately solved, like how do I match the problems that people are having now with today's scale, complexity, compliance and stuff? What are some of those immediate things that Nautobot typically.. you know, kind of attaches itself to.

Yeah, as far as I was looking at earlier, I think some of the more basic problems and even being on this podcast, I think you're usually talking about cloud scale, cloud scale problems and probably oftentimes being on the cutting edge of a lot of things. So I would say in the networking space problem number one is just inventory management, right? There's still so many tools from just network monitoring events and just vendor-based tools that just have a different source of inventory. So number one is really just getting controlled inventory because it's so important and we can go down this path to automate the network. You need to have the trusted source of data that's going to ultimately drive automation. I would say hopefully it doesn't take so long to get to a point. You can eliminate some spreadsheets, have a trusted data source. And from there, I would say common use cases. No doubt, number one for us over the past year or two, thinking about in Nautobot was config compliance, right? Again, open source apps. I would say for us, we try to always keep in mind. Net DevOps and DevOps principles and being loosely coupled, work better together, and even that one app that I'll call out. It allows users to do things like backups from Nautobot, but at the same time, if the user already has backups and a Git repo, great, point to the repo and we'll pull them in. Same sort of thing, even generate configurations. A lot of users already have things like Jinja templates, create configs. It's so great, use them and then just sort of punch in the repo and pull in those configs any layering on top, right? In the UI to be able to build compliance per feature. It could be BGP, it could be interfaces, triple A NTP, all these things that that might seem overly basic, I would say the most common environment, the networking space are still trying to solve these, these challenges after that, you know, things like firewalls and load balancers, even tracking things like support contracts, device lifecycle, all of these things are, you know, still problematic across the enterprise space and networking.

Yeah. Yeah. I'm, I'm curious cause it's, it's one of these topics that sort of top of mind for folks. It feels like, you know, we're starting to see some of these, these modern AI tools kind of build or have the ability to sort of build some code for people, you know, give people, you know, kind of best practices. Are you, as you're thinking about what it can do and the fact that it touches all these things, like, is there potentially an AI opportunity at some point to build some models that help people or is that sort of. You gotta see where the AI stuff shakes out before you start thinking about where this falls in.

Yeah, no doubt. We're thinking about it. We're talking about trying to see what could be done. But I would say for us, When you look at all this data that is in the enterprise today, and clearly you have a lot of focus on Nautobot, being able to.. conversationally understand that data, it would be. It would be a tremendous value add for the users, meaning looking at general trends. The way I like to think about it is you might have dozens of dashboards, you're trying to trend certain data, look at growth rates. And I would say for us, it would be, I would say over the next several years looking at the impact of AI, it would be, can we make that a conversational? interface are no different than we're all seeing, I'm sure, in our daily lives with ChatGPT.

Yeah. One last question before I let you go, because I know you're busy. As you guys engage with companies, we talked– you've mentioned a couple times– Net DevOps. What's the group? What's the organization that you're engaging with? I mean, is it– I mean, is there a net sort of DevOps team? Is it platform engineering? Is it sort of the network and infrastructure team? I'm curious, who are you guys typically engaged with? And then who ends up being the user of the platform and maybe like who they think of their customers are? What's the typical kind of structure and who's doing what?

It probably varies if we're looking at mid-market, mid-market enterprise, large enterprise and so forth. But by and large, still largely within the networking organization for what we're engaging with. The larger ones have teams or a subset focused on network automation. And even within that group the ones that are doing it right has teams that are focused on platform development or all the tools that the other teams can consume, meaning if it's operations or security or wireless, what have you, whatever team, even cloud networking as an example, it's just really trying to build out a platform that's holistic. That's really, you know, team, team one. And then their stakeholders become the different pillars or verticals within the networking organization. And again, we've had engagements where things go really well and then they want to bring to the table other domains. Again, if it's more traditional security or even compute or storage, I would say for us as a business, we're best known in the networking space. Typically, if we build a trust with a given client and they want to see what we can help with in other parts of the business. But yeah, in any case, still very, very much falling in that networking umbrella. And as things grow within the cloud space, there's some intersection, right? But I would say, again, main stakeholders still very much in that networking organization within the large enterprise space.

Yeah, good stuff. Good stuff. If folks want to come, you know, want to pick your brain, want to follow up with you, kind of want to engage with the network to code team, what are some of the best ways to go about doing that or even just engaging with the Nautobot community and kind of learning about these technologies?

Yeah, from Nautobot, I'll give nautobot.com as a redirect to the website. It's a great place to kind of get familiar with it. Otherwise, Nautobot has its own GitHub organization as well. Again, everything that I talked about today is it's all free and open source. Read the docs are great. Also have a newer landing page docs.nautobot.com, really just an easy way to navigate open source docs. And I guess the plug for Network to Code: any interest in getting help, we would love to chat.

Yeah, good stuff. Good stuff. Jason, it's been it's been way too long getting you back on the show. Hopefully we can do this more frequently. But folks, on behalf of Aaron myself want to thank Jason for his time today. A lot of cool stuff that that he's been working on for for a long time. Really, really good stuff, especially if you're in this space of having to manage networks, having to manage security and automation and all this stuff around that to make your application teams happy. So Jason, thanks again for the time folks. With that, I'm gonna wrap it up and we will talk to you next week.