The Team Behind Nautobot, Part 2: Writing Network Automation with Nautobot

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, it's the part two of our conversation with three of the authors from the new release book, Network Automation with Nautobot. Of course, we're talking about Ken, Jason, and John. The first part of our episode, we talked about the origin of their network automation journey a little bit. Also the history for Network to Code, the reason behind the book or the original idea of the book. And in this episode, we will… dive much deeper into the writing process and how the book came from just an idea into the printed copy that hopefully some of you will have in your hands. So welcome back, gentlemen. Thanks, Eric. Also, full disclosure, in case you missed it last time, and I am a reviewer of the book early on, as well as the employee of Network to Code at this time. So I have a totally biased view of the book. I think it's great and everybody should get a copy. Where we end up last time was why we think there should be a book for And in this section, I think we'll start with the question of how is the book structured and how do you came for the idea of pitching that book onto structuring, finding authors. So I think this probably most appropriate for Jason to answer.

Sure. Yeah. I would say the book right now is for one, it's a pretty heavy book, right? It's a lengthy, a lot of content, a lot of screenshots. I will say a lot of code blocks and screenshots kind of add to page count. It's not for the faint of heart. But it's really five main sections where we break it down. Part one is introducing Source of Truth and Nautobot. It covers network automation, one-on-one, what network data means, that relationship I mentioned in the last episode around the connection from network data to network automation. Then we introduce, again, a bit more of what John mentioned in the last episode around the data model around Nautobot. That's kind of, you know, surface level introduction part two. And we have five chapters in part two. It's all about getting started, right? Installing, navigating the UI, diving in, configuring the data models, learning about extensibility features, things like that. And then a bit more about the administration of Nautobot. Part three kind of dives into network automation, right? All the things around APIs, REST APIs, GraphQL, Git integrations, Nautobot jobs. How do you run Python scripts? and offer them via self-service and as a Nautobot Job. And then we kind of close that section with just overall architecture, right? Where does Nautobot fit in in architecture? The final formal section in the book is around Nautobot apps, right? You mentioned that a lot last episode, the ecosystem and the apps and what that means. We talked about the current apps that we've released in the open-source space. and then kind of provide that journey and a tutorial, so to speak, around how people can start to experiment and build their own apps. Then we have three great items in the appendix around doing a deep dive architecture on Nautobot itself, looking at, and then two more of the common apps in Nautobot. One is called SSOT or Single Source of Truth. That's how we kind of… aggregate different data sources to from Nautobot. And then the final appendix is really about how do you perform config compliance and remediation with Nautobot. So all in all, we're at 19 chapters counting an appendix as a chapter. Yeah, it really goes kind of start to finish all things Nautobot. And we probably could have kept writing and added even more.

Was it Twain who said, if I had more time, I would have written a shorter letter? But yeah, exactly. And just back to your point, if I look at Amazon Page, I'm looking at it right now and it still is number one new release in several categories. So congratulations, guys.

But the whole team really, honestly, but I got to shout out to everybody else involved. Really a shout out. It's been a phenomenal time in the last several months. Anyway, shout out to the team.

Yeah, for sure. Shout out to the team. And it's 700 pages. And if I remember correctly, it was like 800 to begin with. after we receive a lot of feedback from the editors and now we're like starting to cut back, but it's still 700 pages. But the good news as to your point, Jason, is they're divided out into, you know, several categories. You don't really have to read end to end. You could just pick and choose your point. To me as a reviewer, I feel it's hard to, you know, having discussed network automation in the abstract form. So this book is meant to talk about network automation using Nautobot and example to offer some guardrails toward that path. So that's what I liked about the book, but I'm interested in what you guys thought about it. And first of all, you know, there are multiple authors. That's why Jason, you said shout out to the team. So which chapter did you write, John?

Yeah. So I helped out with the data model portion and some of the source of truth. And then a lot of the technical reviewing. as well. And, you know, let's say is the product owner of Nautobot, I think what was really interesting through this whole process for me and really unexpected was just kind of learning, here's some gaps, here's some interesting things that we can actually use to influence, you know, Nautobot itself from a development standpoint, because we are writing this book, right? And to Ken's, you know, earlier point, maybe from the last episode, the fact that it's done so in a narrative format, you know, we really had to step back and look at who's the persona that's actually reading this book, you know, what And I think that has helped me kind of take direction from these efforts in the book and kind of get those back into the product as well.

Well, being on Ken's team, if I have a penny every time I heard about persona, be a pretty rich person. So tell us about your path, Ken. What is your approach in writing a chapter? Well, first of all, which chapters did you author and what's your approach?

Yeah. So the chapters I authored were, I want to read it correctly. So diving into the Nautobot accessibility features and data-driven network automation architecture. And then I helped out on the Golden Config, the appendix chapters there. I think from my perspective, what I learned from it is you just got to do it. And to anyone else out there, it's great if you have kind of cleaning up and reviewing your work, Jason Edelman. So I would highly recommend anyone else writing a book or writing chapters of book to have the same. I'm a Jason. Yeah. If you have the same working agreement, you'll be successful. So that was definitely, definitely super helpful. But you know what, honestly, it's really, it's just getting down, letting it flow as much as possible, not overthinking it, and then coming back and iterate through, right? It's just like, while you have something in your mind, just get to it. The second thing which we all don't ever do, we all agree, is just blocking off your time to kind of actually get down to do it. And just don't let anything else distract you and keep a notepad of everything that's going to distract you that you're not going to let get out of your mind. Just write it down a notepad. Every time a little thing comes to your mind and say, "I need to send an email. I need to make this calendar invite…" I know it's going to take 30 seconds, but we all know you're going to get distracted and you're going to… You see a text message on your phone or you're going to like see a YouTube video. You're going to get super distracted. So I think that's something we all know across the board and we never do correctly. But those were the key things for me. Having written quite a bit. Yeah, it's really, it's not just writing. It's anything technical when it comes to this process or anything in this world. You just have to double or triple the time expected. Right. If we think we're doing in three months, it's going to take nine. If it's six, it's going to take 18. and being realistic because of peer review and just sort of blocking the time.

I was going to pick up a comment on John's statement because it's so true where having gone through now the process to create this book, there were a lot of lessons learned in terms of just gaps. I would say one, it could be realizing maybe there's a gap in a few docs that are out there. That's great. Boom. Let's get a bug or feature request open to fix some docs as well. but also recognizing when you have a large team doing some of these operations to build tutorials and walkthroughs. Yes, to John's point, we recognize, yeah, that there's some great things coming out of and maybe doing things differently as the project continues to grow. Even coming out, it's like, wow, I forgot Nautobot can do that. And maybe there was a feature added a year ago. And now we're going in to kind of walk through to explain it and teach it. So yeah, overall great process, but uncovering gaps and being surprised along the way at the same time, just being super proud to release it. And now looking forward to get the feedback when it starts shipping in a few weeks.

Can you give me an example of the things that stood out in your mind when you said, Hey, I didn't even know Nautobot could do that.

I hope for me, export templates as one of those, I always forget kind of exists. It's very useful and it's kind of like innate to how the system works.

Tell us what it is first though, Ken. Like explain a little bit and then what you discovered.

It's kind of used and John will keep me technically accurate in case I'm wrong, but I believe it's used. Like whenever you do, you look at a list of a bunch of objects. So you have a list of devices. A list of locations, whatever it may be. You can export it as like a CSV. I believe that's just using export templates, like the same framework underneath, but you can also sit there and say, export this in a different way. It gives you access to all those objects. You can just kind of just iterate through and generate a markdown report or generate some your Nagios configuration or something to that effect right there with just a simple change of template. So it's nice, easy, effective. And Jinja is just about as powerful as programming language, right? And you can kind of do anything. You have access to all the data, and it's super simple to get going with.

The thing that was most useful for me was actually to realize how applications could be first-class citizens on Nautobot. I mean, I've seen some of this on demos or Nautobot Next or whatnot, but I didn't realize some of it was actually extensions. and not the core. So for me, that was my biggest aha moment and say, okay, well, it is a first-class citizen because it does view and enhance a lot of the core functionality. And that is why they look very, very similar on look and feels. And a lot of thoughts and care have gone into that, I bet. In order for that to happen, it's almost like you spent twice as amount of work just to make it, you know, first-class citizen versus you could have easily just say, well, forget it, you know. this is an extension and they shouldn't look and feel the same. But I caught you off, Jason, go ahead.

No, no, it's similar. I suppose I would say the example that I'll give here is to maybe bring an app to light, which is in the appendix. It's around config, config compliance remediation and kind of in general not being hands on every day, right? Well aware architecturally sort of outcomes of. of what's possible, but when you kind of get your environment spun up and say, hey, let's walk through some of these things and fully understand it from a hands-on level. I would say last year, I think it was last September, October, there was a release of the Golden Config and Nautobot app that does remediation for compliance. Compliance was there for a couple of years. And so, kind of walking through a Nautobot, it's called a config plan. So for years, if you have compliance, that your device is not compliant, then we would show what devices were extra and what was missing. Right. So now there's this newer concept of a config plan that allows you to remediate the configuration on a device. And I would say walking through that. Yeah. I was just like, this is awesome. It was just giving the user flexibility around, well, how do you want to remediate? And there's a few ways, you know, an intended, is it missing? You could do manual override with the embedded Jinja template. on remediation and you can select a device, you can select a platform type, a site, a combination of those. And so I would say for me, it's the last appendix. And it was like, this is pretty cool.

I would second that. I think the first nine chapters was okay for me, for my little puny brain to grasp. But when it gets to chapter 10, that John's chapter, it's like, Oh my God, this is pretty complicated. I got to sit down. I got to grab some coffee and make sure I have a clear mind. But I meant to ask you this earlier, Jason and Ken and John was how long did it take just overall for this whole process take place? Like when did you pitch the idea to Packt? Up until now. How long was that? Is it a year or two years, three years, year and a half?

Yeah, I think the idea was pitched maybe in Q4 of 2022. I remember we did some initial work at the end of 22, but like the bigger starting point was really January of 23. And so I would say start to finish. Yeah, we're probably looking at about 14, 15 months, but I'll admit there was a period in the middle where he didn't do any work because we have day jobs and we're But recognizing there was probably a three month span that was a wash just because we didn't have the time to put cycles on it. And the last four months has really kind of been a race to the finish to kind of get this buttoned up and released over again the next few weeks.

Yeah, that sounds good. I know Ken went over this a little bit on his writing process, what he thought was useful, what he learned from it. And I'm interested to hear your opinion on that, John. Was it everything you imagined it would be? Or if I understand correctly, this is your first book, right?

It is in the non-academic space. Yes.

So what are your thoughts? I mean, I'm interested in kind of your perspective on the whole writing process. Was it too much interference from the editor? Was it like what you would imagine to be or what is it?

Yeah. The reason I say that kind of tongue in cheek is because I am still in academia working on a PhD in computer science. So, oh wow. Good bit of experience in writing academic papers, but this is very different from that. This was fun. Yeah. how can we best help them through this narrative? So I think from that lens, it was really, I think, fun for me to sit down and think about how do I describe the data model in a way that's going to be really consumable for someone coming into this fresh.

Anything you learn from the writing process, I imagine pretty soon you're going to start writing your dissertation and going to work with your advisor on that. So for me, you know, I subscribe to the model where can't describe as well as a lot of famous authors do. They just start writing and they just start, you know, pitching your ideas, taking good notes. And even if you just delete everything you wrote, it's still worth the exercise of just sit down and write. So what was the process like for you? Did you have a system or were you just, you know, kind of where inspiration takes you?

Yeah, I actually use kind of the same model that I have everywhere else, which is I'll start with an outline, right? Where's my idea at right now? And then I'll hand that to my wife and I'll say, does this make sense? And she's a second grade teacher. So doesn't know anything about network automation. Yeah. That's a really good gut check of. Do these words make sense when put together? And then from there, I'll just pick off line items from that outline and just write a paragraph here, write a paragraph there. As Ken says, just set some time aside and knock it out. What's the phrase about the elephant one bite at a time? You can't sit down and write the whole chapter all at once. You've got to do it as it flows. Just set a little bit of time aside here and there.

Yeah, not to boil the ocean at once. What about you, Jason? Do you solicit your little kids' help on reviewing their outline first?

No, no, no. Where we started with the book, it was kind of table of contents driven. We kind of knew what the TOC was going to be and some higher level H1s for every chapter. But clearly once you dive in, you realize we have to restructure things. And yeah, for me, it's sort of just trying to start writing, but not to lose sight of Being the reader, I think for me, that always plays a critical role in just anything I write. It's just sort of knowing the networking audience and really being the network engineer as we write. For me, I'm always thinking about, you know, we live in a world with so many acronyms, so many newer technologies and things like that. And just trying to say, like, as we write, if we're introducing something, I'll define it, let's talk about it, and then kind of use that in the next paragraph or the next chapter. And so just being very mindful. of the order of operations during the writing process.

He wrote, I don't know, like 60 plus book so far, and he only wrote two non-fictions and only one book on writing. And it's just called On Writing. And he would go over his process. And I want to say it's 150 pages, but what surprised me most is his system and his persistence on just writing and rewriting and rewriting again. Your first draft is always junk. So. If anybody who ever asked me about the writing process and that now I have three authors who have basically said the same thing, right? Have a system, go write it, just sit down and write and the flow will come, but you'll fall down to your system. You don't just write on inspiration.

Just to add to that, right? It's like whenever I'm approaching like a deadline for writing, I find I write the worst things possible. when I am saying, I got to get this out. It's got to be this word count. It's got to be done at this time, right? That's when the worst work product comes out, right? You've got to set the time aside up front to say, yeah, I'm going to get two or three sentences per day down. But those are going to be good quality sentences, right? So once again, if we have more time, we'll write like the shorter book. But in any way, it's right. Like same process.

All right. So I'm going to ask one last question regarding the book. So now that the book is out, it's So what is the thing that you feel that was left on the cutting floor? Maybe some of those chapters you have to cut back on, you know, or so other parts of the chapters and other authors. So why don't I start with you first, Jason, on what do you feel that you wish it was included, but it's not.

Yeah, I'll go probably, I guess it's non-technical, but I would say looking back, you know, hindsight is always 20/20, you have 19 chapters, I would say would have probably tried to explore. having one case study use case that every chapter kind of maps back to. Right now, the persona is the same, but I would say having that one storyline, that's the same fake customer, the fake environment, a certain topology that's followed. I think you might have brought stuff into feedback too, right, in the reviews. And given the timing, it was hard, but that would be the one thing probably. to do it again or wait for the V2.

Second edition or like a follow up. So what about you Ken?

Yeah, I totally agree with that. I think that's a great point, but it's somewhat on the opposite side of the spectrum. And I think it's lengthy enough of a book, but more examples. I think sometimes when we do config compliance, I don't remember the details, oftentimes when we're demoing config compliance. It's always the basic NTP, SNMP, like those different things, but just having some of the time to go through and do something more complex like a BGP interfaces and other things like that. And I think about like, how do I learn? How do other people learn? And I know for me, it's tough for me to learn from documentation. I learned from examples and by seeing more examples, it helps me to. Understand like I could see the behaviors without like, you know, touching a piece of code and I kind of know what's going on. So yeah, just that a lot of examples again, like these are two competing forces. I think Jason's point is as well furthering that narrative with a single case study throughout would be great. But if length was not a challenge, I think also having many examples in those same different things and just. to look at things from like the WAN, the campus, the data center, you know, would really help resonate with more people and reiterate things. I use a GitHub desktop to squash commits because it's easy. I had a misunderstanding of the behavior because I always did it in the same way, right? And so I always clicked the first thing, clicked the last thing. To me, it was the thing I clicked last. There was actually a thing I right- clicked against. that changed it. And I think about that often where it's like you show something and the behavior seems one way, but it's actually a different way. You think it's alpha sorted, but it's actually something else that just happens to be alpha sorted in this circumstance. So long winded way around, say, more examples.

Yeah. What about you, John?

I think more of the same, right? You know, I think from the community standpoint, one of the things that comes up very frequently is, Hey, you've got this cool data model. Here's how my network looks in this given use case, right? Like here's how I deploy my, my MPLS network, or here's how the services are broken down in my data center. Right. How do I use the toolset that you've given me to model those things? Right. So yeah, I wish we had more words and more time to spend on that kind of thing.

say maybe second edition. So it will be like a thousand pages, right? But hey, you know, I think just collecting from all three, you know, gentlemen's thoughts, I think now we have an idea for like a separate book. I mean, I love these cookbooks and case studies. I believe there's even a book out that was just composed of interviews for people in the Python community, right? Like the maintainers. And so I think there should be a book out there that's just for use. who's living this day to day. Maybe that's the idea for a second book. I don't know. We'll find out. Yeah, only one way to find out, right? You know, I'm not trying to push you guys. I know this was a big lift and everybody just kind of, you know, wipe away the sweat on their forehead. Just get this pushed out the door. But once you catch your breath, right? Hey, there's another book idea. So I think we could probably geek out on, you know, writing and Nautobot and network source of truth forever. But we do have to end at some point. Last piece, I want to leave it to you guys. And there's two questions and say, if you have any call to action, and where can people find you and follow your work? Let's start with Jason.

Well, I would say from a personal perspective, yeah, on X or Twitter at jedelman8 or LinkedIn, I think that's great for personal interactions. But I would say call to action. Maybe I would say again, we've had a network of code. Slack workspace for years. I think that would be a great call to action. If you're exploring network automation, all facets or Nautobot, yeah, it's all sign up at slack.networktocode.com. And then from there, join the Nautobot channel and have at it, ask questions and engage and our team will be there.

What about you, John? Any call to action and where can people follow you and find your work?

So I guess as the Nautobot product owner, you know, my call to action would be, you know, if you've ever had an idea in a network source of truth product that you'd like to see implemented, go open a GitHub issue, right? It's github.com/nautobot/nautobot. It's where you find the repo and open an issue there and we can start a conversation about it. As far as following me, kind of burn out on social media, but you can find me on LinkedIn.

OK, cool. Yeah, and we'll have your LinkedIn profile. And I just want to say, hey, John, be careful what you wish for. Your inbox is going to–

I love the ideas.

All right, cool. What about you, Ken?

I'll be a corporate shill for the call to action. You know, go get the book. Don't let the large page count sway you like any large amount of content. You have to know how to break that down yourself. What chapters do you care about? Which parts of the chapters, right? You know, I have like the extensibility. If you know what SaaS is and you say, I didn't know what sass is, you know, it's pretty simple. It's active. It makes sense. You don't need to read that part of it. It could be used as a reference as well. And where you can find me, itdependsnet on Twitter slash X and itdependsnetworks on GitHub.

itdependsnetworks. I like that. Somebody will probably pay you a ton of money just to have that, but you're hoarding on that.

Yeah. That was my evil plan was like something that someone always says. And if you follow me in Slack, if someone says it depends, I will trademark it with a little emoji.

Right. Well, you know, it's been a pleasure. Thank you, John. Thank you. And thank you, Jason, for being on the show.

really enjoyed our conversation. Thank you.

And my call to action is actually go to go.networktocode.com/nautobot-book to register so you can win your copy. And I'll end with our normal outro. Thank you for listening to this episode of Network Automation Nerds. Do you have any feedbacks for Network Automation Nerds or this episode or our guest? Send me some follow ups at packetpushers.net/fu. I want to hear from you. And check out our website at packetpushers.net to find other network engineering focus. podcasts, blogs, YouTube videos, and the Slack channels. And again, listeners, exciting news. If you want to win a copy of the book, Network to Code will give away copies of Network Automation with Nautobot book we discussed in this episode for 10 lucky winners. All you have to do is just go visit go.networktocode.com/nautobot-book for details. The URL will be in the show notes. Last but not least, remember that too much network automation will never be enough.