#175: Teaching Python to network engineers Transcript

00:00 Michael Kennedy: Network engineering is quickly moving towards a world where it's as much programming and automation as it is packets and ports. Join Hank Preston and me to discuss what parts of Python are important for network engineers to learn. This is Talk Python To Me, Episode 175 recorded August 8th, 2018. Welcome to Talk Python To Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm and follow the show via Twitter via @talkpython. This episode is brought to you by Linode and Brilliant.org. Check out what they're offering during their segments. It really helps support the show. Hank, welcome to Talk Python.

00:58 Hank Preston: Thanks, Michael, thanks for having me.

00:59 Michael Kennedy: Yeah, it's great to have you here. We're going to delve into a topic that I think is really interesting, and I think it highlights one of the reasons of this explosive growth in Python. We've had people writing web apps in Python for a long time, but now Python is starting to appear in these other domains where programming wasn't necessarily the first thing that people did and we're going to talk about programming for network engineers.

01:24 Hank Preston: Excellent. It's a topic close to my heart, because that's what I talk about most days these days.

01:28 Michael Kennedy: That's awesome. So before we get to that, let's focus on your story, and talk about how you got into programming in Python. Where'd it all start?

01:37 Hank Preston: Yeah, so it's good. My story and my rapid love affair with Python started, I would say, I think it was about five years ago, and I was working at Cisco, which is where I currently am now, as a systems engineer and solutions architect focusing on data-centered topics. And around that same time, the cloud tidal wave was hitting everybody, and so part of our role...

01:59 Michael Kennedy: What year was that?

02:00 Hank Preston: I'd have to go back and look. Somewhere in the 2012, 2013 area is where it kind of... It had been there for a while, but that's where it started to affect my day-to-day job.

02:11 Michael Kennedy: Right, it had kind of left the, hey, all the startups are doing it, but the Fortune 500, they're going to never touch the cloud, ever, ever, right? Until they did.

02:19 Hank Preston: Yeah, that's really what it was going through, is at that point, their customers I was dealing with mostly were the Fortune 500s, enterprise customers in the Midwest, and we were starting to hear from the likes of these large Fortune 500 and Fortune 100 customers that they're starting to experiment, or they've realized that they had been experimenting in the cloud for a long time, it's just nobody told them that they had stuff out there, which is always fun. So as this was going through, I had one of my managers come up and say, Hey, we need to start understanding what this whole cloud thing is. We need to understand what application development is, what a cloud app is, and why it's so different, and how to talk to folks that are in here, and I had the opportunity to go off and spend some time on a program Cisco put together around cloud native development. So it was kind of a boot camp approach to diving into a bunch of different topics and it was from containers to cloud applications, and part of that program was actually two weeks of Python training. I credit Raymond Hettinger with giving me an awesome exposure to Python, diving me in really well. His intensive introduction to Python class is the most aptly named technical class I've ever had.

03:35 Michael Kennedy: That's cool, was this an in-person class? Did he come out to your location?

03:38 Hank Preston: He did. So he actually, I don't know if he's still doing it today, cause I haven't looked in a while, but at that point, he was teaching Python every week for Cisco classes. He would teach a class in San Jose, and then he would go down to Austin, and then he'd go to RTP, and he would be teaching our developers inside of our business units, inside of our services organization, Python fundamental skills, because it was becoming so important to everything that was there. So this was a class focused on our field engineers to go through and start to help us get prepped into it and he actually had, his classes still exist, and I still see it and go through the pieces occasionally, but it's like an intro, and then it was an intermediate, and then an advanced. And I swear, across those three weeks of training classes, it was like a year of intense college study, to go through the level of depth that he took us and how quick we went in.

04:30 Michael Kennedy: That's really interesting. I feel like colleges, for some reason, when they teach programming, it goes incredibly slow. Compared to how fast you can actually learn it if you just put your head down, right?

04:40 Hank Preston: Absolutely. And that was the piece, and normally... Many of us have been used to going to these training classes where you can go in and you can step out for a phone call or you can go take a meeting halfway through, and you really don't miss anything. In this case, it was a very, if you stepped out, you were lost. It was like you lost a week in a college class. So that's where I dove into Python, and within just a couple of days, I realized that programming was different from when I did it originally. Cause I had a background in some development. I had done some Java, and C++, and a bit of .NET development, some database work, and then I made a conscious decision to go over and move more to the infrastructure space and focus on systems, and then eventually, networking as a specific domain. Frankly, because I wasn't a big fan of Java, and I got tired of developing in Java, so I gave up on that, but when I had this exposure to Python, it was such an easy language to get into. The syntax was really readable. I didn't need to be a software developer. I could dabble with it for a little bit and then come back, I didn't feel like I lost anything. I could consume other people's code really easy, and it's a lot of those characteristics about Python which is what's made it so successful in the network engineering, as well as general infrastructure engineering space as a language of choice.

05:57 Michael Kennedy: I think that's a really interesting point, and there've been a lot of languages that are easy to read, like VB is a language you could read pretty easy, right, Visual Basic, but a lot of the ones that are easy to start with have these pretty low ceilings where you can build up to this point, but if you want to build something real... You put that away, and you get out the Java, you get out the C++, and Python doesn't have that ceiling quite nearly as low, and I think that's partly one of the things that makes it really special.

06:24 Hank Preston: Yeah, and that's been one of the huge elements for me. I've been doing Python daily for several years now going through, and I still go back to some of the fundamental skills that I learned in those early classes, but the programs I'm building are much more sophisticated than some of the early ones they go through, and when I look at some of the new features that come into the language, there are really exciting things that are coming after it, but they're being put in a way that you don't have to use those, right? It still gives you this ability to work your way into Python, absorb the capabilities when it makes sense for you, and there's a challenge there. It's not like... With Javascript, it feels like you have to... Immediately you're embedded inside all sorts of promise statements and multiple levels of embedded, and you can't do anything. With Python, you can start really simple, and then when the time calls for it, there's all of this other stuff that you can pull out and become very sophisticated, as far as the language goes.

07:18 Michael Kennedy: Yeah, that's part of its sort of elasticity up and down the experience scale, like you said, you don't have to be an expert in all of Python to build interesting things, like you maybe don't even know what a function is, but you could still do some pretty interesting stuff straight down along, you know. You don't need to...

07:32 Hank Preston: Exactly.

07:34 Michael Kennedy: Care about code reuse or whatever, right?

07:35 Hank Preston: Yep, yeah. It's object-oriented under the hood, but you can completely ignore objects. And so you realize that there's value in it. And hell, half my codes still ignores objects, it seems like these days, so.

07:45 Michael Kennedy: Yeah, that's quite an interesting point. So speaking about these days, what are you doing day-to-day? You're a developer evangelist at Cisco, is that right?

07:52 Hank Preston: Correct.

07:52 Michael Kennedy: A dev evangelist?

07:53 Hank Preston: Yep, yep, so I'm a network programmability evangelist with Cisco inside of our DevNet organization. DevNet's the developer enablement program for Cisco, so it's where people that are looking for our API documentation and SDKs and sample code and sandboxes and resources, all of that's available on DevNet. And my team of evangelists are like you would find at any of the developer enablement programs is we go out and we help people better make use of and understand what's possible with the tools. Cisco has a huge portfolio of products from networking to security and collaboration. I focus really, really fully in the network automation and network programmability space, so there's tons to keep us busy, and there's tons of work out there, helping all of these enterprises and network engineers inside of the enterprises figure out what automation means and how they can start to automate their deployments, and what does it take to skill up and make changes. And these are the types of things resources we build as well as events that we hold and discussions we give.

08:57 Michael Kennedy: So you might be going out and visiting a group of network engineers who maybe haven't done a lot of programmability automation of networks...

09:06 Hank Preston: Mm hmm.

09:08 Michael Kennedy: And you help bring them along, or maybe help them design how that applies to their infrastructure, or something like that?

09:13 Hank Preston: Exactly, yeah. I frame in two cases where it goes through. Most days, these days, organizations are recognizing they need network automation, and so they're going to their networking teams and saying, Okay, we need to figure this out. What resources are available? I go into some of those organizations and I'll spend a couple of days helping them and leading Introduction to Programmability classes. Just last week, I actually spent an entire day with one of my customers. We had about 20 engineers in the room, and we were going through basics of Python. So, what is a Python script? How do you create variables? What are libraries, and what libraries are interesting for the network engineer? How do you parse data that comes back, because that's a big part of dealing with clear text versus JSON and all these other tools.

09:59 Michael Kennedy: What is JSON, how do you process it? What is XML?

10:02 Hank Preston: Yes.

10:03 Michael Kennedy: What's a Yaml file?

10:04 Hank Preston: All of that goes through, and that's a big part of this bringing Python into the network engineering field, is network engineers have been in IT for years, and many of them took CompSci classes way back when and they may have been similar cases like I did, and didn't like Java a whole lot, and so went into networking.

10:21 Michael Kennedy: Programming's not fun, I'm out of here.

10:23 Hank Preston: Yeah, yeah, enough of that, I'm going to go make packets go across the network. So, what we're doing now is trying to help remind them some of these skills that are there. They start to knock the cobwebs off some of the fundamental programming stuff they had from maybe 20, 30 years ago when they went to school, and then start to add these new elements that are there. XML didn't exist for some of these guys when they went through it, and Yaml certainly didn't. So showing them the value, showing them how to use it, how to connect to a device through Python using one of these APIs that are available. And why is that better than doing it the way that they're doing it today? 'Cause that's a big part of the discussion, often is showing them that there is value in making this journey.

11:01 Michael Kennedy: Right, because a lot of them probably didn't decide to be programmers. I mean, maybe that's a good way to segue into what is the background of a typical network engineer. You said maybe they have some programming experience, some techno experience, but they probably didn't choose networking because they wanted to be a programmer, so what's the story there? What do you experience.

11:19 Hank Preston: Yeah. Yeah, they absolutely didn't choose networking because they wanted to be a programmer. In fact, one of the things I hear an awful lot when we start to have these discussions is, in some cases, they're coming kicking and screaming because they really don't want to be a programmer, and they don't want to learn these new skills, and it's helping them recognize that just because you're going to do some automation, you're going to learn some Python doesn't mean that you're now a software developer, because these skills are becoming relevant to data scientists, to engineers, to everybody. There's this blurring in the gap. A typical network engineer has a foundation in network theory and connectivity areas that are there, so there's the typical OSA model of Layer 1, 2, 3, all the way up to 7, so they understand the fundamentals of how network traffic works. They spend their days dealing with networking concepts, like IP space and ports and firewalls and load balancers, all of these elements, these foundational elements that make applications function that the cloud relies on to go through. The network engineer is coming in these discussions with this understanding of how this foundation goes through, and despite the fact that, in many cases, they don't think that they've done a lot of automation or they've done a lot of programming or scripting in their previous life, let's say, many of them have, because every network engineer I've ever known has been a problem solver, and is always looking for ways to do things a little bit better. So for the longest time, and in some cases, still today, is a CLI interface, a command line interface, is how we configure a network.

12:53 Michael Kennedy: Maybe a bash script or something like that that'll process, you know, automate that in that sense, right?

12:58 Hank Preston: Exactly. There's expect scripting, right? So send this, and expect to get this back, and then send this other one away, because every network engineer I've known really hates having to repeat themselves over and over again. So they've figured out ways to make their jobs better. So that's the big thing I'm trying to show them, this movement to using Python is actually going to make what they've done in the past simpler, and actually a little bit more pleasurable because we can take away some of the challenges that were there. There is a bit of that, I want to say hurdle, but a plateau to get people over it, and that first aha moment, that's one of my favorite things to see when I'm working with somebody, is when they get it. They understand the value. They understand that it's not this thing to be dreaded.

13:40 Michael Kennedy: Right, they're like, "I don't want to do this. This is not my job, this is not what I signed up for. Wait a minute, that's pretty awesome."

13:43 Hank Preston: Yup.

13:43 Michael Kennedy: "Okay, maybe it's worth it." Something like that, right?

13:44 Hank Preston: Exactly, exactly.

13:47 Michael Kennedy: So you talked about getting into Python almost because of the cloud.

13:53 Hank Preston: Mm hmm.

13:53 Michael Kennedy: And things like that. It seems to me the cloud movement itself has probably dramatically changed what it means to be a network engineer in the first place, right? There used to be these physical things, you could log into 'em and mess with them, and now, it's APIs and VMs and data centers far away from you.

14:14 Hank Preston: Yeah, that's completely accurate. It comes back on network engineers ourselves to some extent that we got so far away from what a network really was and we started to see a network as these physical routers and switches and firewalls that we touched rather than the act of connecting together the pieces that are there. So I talk a lot, one of the conversations I get is this evolution to networking in the programmable age and I go back in time to when the network really was just routers and switches and servers.

14:43 Michael Kennedy: Yeah, you referred to that as the four ages of networking, you want to take us through it?

14:47 Hank Preston: Yeah, exactly. So originally, right, in what I often call the Stone Age of networking, things were simple. We had servers and work stations and printers, and they connected into switches and then maybe we had a router to communicate with them. And the biggest thing network engineers were focused on was making sure that spanning tree didn't cause issues in the network and that if they were going to have to use some of UNs to carve computers and printers off. Because at that point, the network was, you could walk into any closet, and you could reach out and touch it. It was usually teal green and had Cisco written on it, and that was the net, there were cables, and it was really easy. But over time, the first hint of the changes to networking that I started to see, and many of us did, was virtualization. X86 virtualization with VMWare and these other things, and the concept of the vSwitch came out. And it wasn't even that long ago, I would have heated discussions with networking and server teams about whose responsibility it was for the network inside of Hypervisor because the network guys didn't want to do it because it wasn't a physical switch and the server guys had no idea what a VLAN was or what a tag was, and so there was this huge challenge that went through. And sadly, in many of those cases, the networking guys just stuck their head in the sand, and said, you know what, I'm just going to let the server guys deal with it, 'cause it doesn't really matter. And then as we moved from that Stone Age, that early piece that went in into the .com era, and all of these other pieces, new things went after us, after x86 virtualization. We got blade switches, and so we had these new physical pieces, but rather than buying a blade switch from a networking vendor, maybe it's being bought from a server company. So networking guys were, once again, saying, you know what, that's not my stuff. I'm not going to deal with it. And then, what was it, two years ago we started to see the container explosion. So now we've got networking inside of Linux servers that are behind virtual switches that are running embedded inside of a blade server someplace. And the networking guys were finally realizing that there is a lot of networking that is happening outside of their physical switches, and that's been a big aha moment. And then we can bring in the cloud elements, because when we talk about the cloud, if we're talking public cloud, in these cases, now we're sending workloads and resources up there and we don't even have the luxury, as a network engineer, to know that at some point, that traffic will go through my physical switch. Because you don't own those physical switches.

17:18 Michael Kennedy: Yeah, the one final bastion of thing they claimed as theirs has now been virtualized and moved out, so now it's all the other stuff They're like, well, it's not really my problem. That's what's left that they now need to work with, right?

17:32 Hank Preston: Exactly, exactly. So as the evolution from virtualization to containers to cloud and I love the fact that cloud is now starting to turn into this, rather than people thinking of the cloud as a place, like eight of you asked, is the cloud, or Google, or Azure, or one of these other cloud providers, this idea of cloud as just an approach, a fully-programmable approach to infrastructure. So I've got customers today that consider their data centers their cloud on that side as well, and they want to manage their clouds the same way that the consume and manage their other ones. This has put this huge pressure.

18:08 Michael Kennedy: Yeah, I think it is, and I think what's really interesting is there's this joke or, I don't know, sarcasm or whatever, that says the cloud is really just somebody else's computer. Right? Which I think that's a little bit disingenuous. Technically it's true, someone owns the computer, but I think fundamentally, the cloud is a programmable set of infrastructure that you don't have to go touch, right. And that programmability could be within your data center. It could be AWS, it could be somewhere else like Linode or something, right? It's the ability to write some code and servers and switches and networks come into existence. I think, in my mind, at least.

18:47 Hank Preston: I think that's accurate. The idea that the cloud, you don't have to worry about the infrastructure is true, if you're consuming cloud, but there's also this other group of engineers that are building clouds.

18:57 Michael Kennedy: Sure. A whole different level.

18:59 Hank Preston: And somebody has to do that, and it's been interesting to watch the pendulum swing from 100% public cloud strategies to 100% hybrid cloud, and then some people coming back to fully private cloud. If any part of an organization and enterprise strategy involves some element of private cloud, be that for data sovereignty or security or cost, because that does come up occasionally, well now, the people that are writing and deploying apps want to consume the cloud inside of your data center the same way they did it in the public cloud. You have to have the team that can build the infrastructure that can offer that service, and that I think is the huge pressure.

19:40 Michael Kennedy: And that maybe means programming API, creating APIs for them to consume and stuff like that right?

19:45 Hank Preston: Exactly it hasn't come up a lot, but I've had two cases specifically with enterprises, where they had taken on, they had done some automation of their own, they were doing a lot of work in the networking space, but they were starting to get requests from application teams in systems and services teams to offer the network services through an API interface, so they were starting to build an API that their application teams could consume, and their operation teams could consume, to make general connectivity or logging requests for information, and so it was a really fun project we did this we got to show, let's talk about API design, how do you build an API what makes an API good so that your developers who are used to consuming APIs from Google and Azure and all these other folks will be happy about consuming your API.

20:34 Michael Kennedy: All of a sudden you're put into the place where you have to compete on API design with Google and Amazon, which just a while ago maybe you weren't even really interested in writing APIs, and you're kind of in the deep end at that point, right?

20:48 Hank Preston: Exactly, and those of the interesting pieces that are coming out of it, and organizations are getting these changes and these adjustments so fast these days, and I think that's a big challenge that every industry has, but certainly the network engineers have, is trying to figure out how do they keep up, there is always that analogy of your laying the track as the train is approaching, and I think that's never going to change in the IT space, and that's been a big struggle, because for better or worse the networking industry didn't have a lot of adjustments for several years, let's say decades in some cases, and this adjustment to cloud and programmability and automation is this massive pivot, so now we've got a lot of network engineers out there just trying to figure out how do I keep up, what do I learn next, where do I go to on this area, and then that sense of overwhelming nature, and my advice to them is okay yes there's a lot, but remember this is an exciting time, we were talking about how bored we were two years ago, now you've got cool stuff to work with, let's look at the value with all this new stuff asked for us.

21:52 Michael Kennedy: This portion of Talk Python To Me is brought to you by Linode. Are you looking for bullet-proof hosting that's fast, simple and incredibly affordable? Look past that bookstore and check out Linode at talkpython.fm/linode, that's L-I-N-O-D-E, plans start at just five dollars a month for a dedicated server with a gig of RAM, they have 10 data centers across the globe, so no matter where you are there's a data center near you. Whether you want to run your Python web app, host a private git server or file server, you'll get native SSD's on all the machines a newly updated 200 gigabit network, 24/7 friendly support even on holidays and a seven day money back guarantee. Do you need a little help with your infrastructure? They even offer you professional services to help you get started with architecture migrations and more, get a dedicated server for free for the next four months, just visit talkpython.fm/linode. Yeah it's going to be interesting to be in that position, because I feel like network engineers were fairly, they didn't feel the full pressure of all this stuff, the changes that we feel constantly in software development. Imagine you're a JavaScript developer, you just learned one framework, and it's now ridiculous to use it, there's a new one right, that's like three weeks ago, is just constantly like that. Python is a little less bad, but it's just sort of hit them out of the blue, but I think it's a tidal wave type thing, I think also sys admins probably had a similar experience as well.

23:23 Hank Preston: I've seen it, the insulation I think the further you get from the end product, and the end product for most of these cases is some piece of software someplace, and so the further you are from the end product the longer it took for some of this pressure to go through, because software developers solve a lot of things on their own, and then eventually it kind of overflowed into the system's teams, so now the server team is trying to figure out how to deal with the capacity and the agility, and then eventually that overwhelmed the storage, we're getting into security networking now, and that's where this insulation is breaking down. Because it was this tidal wave that was just pushing and pushing and pushing, and eventually it's just knocked the wall over and all this demand is coming at network engineers to be agile, to be secure, to offer segmentation, to be able to implement, we're getting requests for machine learning in artificial intelligence inside of the network now to make network decisions, and I'm still teaching Python 101 to folks, and they are also asking where does blockchain fit in, all of these topics are coming in at the same time, which is good and bad, it certainly keeps the job interesting.

24:31 Michael Kennedy: Yeah you've got to have the right mindset but it definitely sounds like a fun and exciting time. So that some of the ways that automation and Python have changed the role for a network engineer, what else is changing for them, what else is Python changing that I don't even know to ask about?

24:49 Hank Preston: Yeah I think that's the interest when it comes through, one of the impacts of using Python to automate your network is all of the things that come along with that, because now they are writing some code someplace, so there's all these new strategies around where to be put code, so with the same time we're teaching Python we're teaching source control strategies, we're showing folks how to deal with branches, and how to use issue logs and pull requests to go through which then gets to take us a Python path and go in, one of the interesting pieces that often comes quickly is how fast an engineer goes from thinking Python is going to be their answer, and then reaching out to some other management tool like Ansible which is written in Python. But they say, no I don't have to learn Python I can just go learn Ansible and fix all these issues and I'll just go down that path. And when that goes for a little while, and then all of the challenges that potentially come out of that come through, and then eventually they're back to okay maybe I do need to understand Python under the hood, I can't just absorb some new open source tool to make everything better.

25:53 Michael Kennedy: Yeah for sure of course that the whole software carpentry side of things has got to come in, as soon as you start to depend upon Python scripts to do your job, it's like well you should actually version control this, how do we share this together how do we test it, and just all those layers to start to come crashing in, it's pretty interesting.

26:11 Hank Preston: I had a question came into me over LinkedIn, it was two days ago and it was from a network engineer I had been talking with for a while, he said alright here's the challenge we have, is I've got people across my organization writing automation scripts to do really interesting things, and we've made a lot of progress, but now we've got islands of automation, and everybody's automation looks different so nobody can use everybody else's automation, so how do we bring these things together. So we started to talk about things like coding style guides, you have to come up with some approach, and style is not syntax, which means there is no right or wrong way, it's kind of a consensus, somebody has to say this is how we do things, and then making sure that people aren't hoarding their code and their scripts on their machine and start to collaborate through repositories and go down that path, and that's an interesting piece that goes in, moving network engineers away from the days where they would store their information in text files where their version control was .v1., .v2, .v3

27:14 Michael Kennedy: You got to save it and zip it up.

27:16 Hank Preston: Yeah, and then just teaching them just the magic that's offered and available instead of using some source control and version control system goes through, we spent probably just as much time trying to teach fundamentals of storage control as fundamentals of Python in some of these early workshops, because that's what it takes to be successful in these areas, and having approached this myself, and kind of stumbled my way through it, there's things that I wish I would have started doing sooner, but I'm trying to help network engineers today learn from the mistakes that I made, rather than having to go make the mistakes themselves.

27:51 Michael Kennedy: Yeah, coming through this path it sounds like many of them do, I'm sure they go through the experience of creating what you would think of as a script that does a very specific thing that you can run to, well there is actually this algorithm in here, and these are the inputs to the algorithm, how do I turn this into say a library or a project someone else could consume and how do we start to build these building blocks, I think that's probably an interesting transition as well.

28:19 Hank Preston: Yeah it's interesting to go through, one of the strategies we use to try to break down the learning of automation and the value profits there, is we sit down and we say, okay well what are the five things that you spend almost every day doing, or maybe we take a trouble ticket, every trouble ticket comes through, every organization usually has these are the information you need to gather before you ever start working on a trouble ticket, well let's figure out how we can automate that, and then we break these up into these little pockets, and so maybe we've got a team of a dozen engineers and three of them work on step one, three of them work on step two, the rest of them will go through, and then the goal is to show them how they can then consume everyone else's work, and say okay will be can pull in this other person's piece of code, so you don't have to redo that yourself, as long as you are abiding by these ideas of how these libraries work, or inputs and outputs that go through, you don't care, it doesn't matter what happens inside of their function, you just know what you need to send it and what to expect to come back, and if we all agree on that, well you saved yourself two hours worth of work.

29:24 Michael Kennedy: Every day.

29:26 Hank Preston: Absolutely.

29:27 Michael Kennedy: Yeah that's pretty awesome, so maybe now is a good time to talk about some of the major packages that people might use in this programmability space, so probably a lot of these devices have direct APIs, and you can create a JSON request, send a POST or something over, but it's probably better to use some higher level library right?

29:48 Hank Preston: Yes so there's a bunch of them that go through, so we mentioned Ansible already, Ansible is written in Python, most people just use it as a program rather than a library, but we do have some folks writing Ansible program modules to extend out the capabilities that are there.

30:03 Michael Kennedy: Most of the time programming in Ansible is constructing Yaml files.

30:08 Hank Preston: Yeah exactly until the module you need isn't there, or it's not working exactly right, and so those go through. But for folks building the raw Python and they want to go down that path, I always start with the fundamental toolkits, you mentioned the APIs, so the key networking APIs today are basic REST fundamentals, and so REST APIs we're going to consume them the same way that anybody else is using requests library is going to go through, so that's another one we teach. Inside the networking space the long lauded and also disparaged API of SNMP still exists, and so occasionally we work with pySNMP to work through and bring SNMP details in, but frankly the newest interfaces, and these are new standards that were developed by the ITF for network programmability specifically, are netconf and restconf, which are model driven programmability interfaces based on data models that are agreed upon and well understood, and then these interfaces return data either in XML or JSON, so now you're getting into true programmability interfaces, so the NC client libraries will be used to communicate with netconf, with the netconf protocol, and then after we get the hammers, the screwdrivers, the nuts and bolts, kind of understanding those pieces, then we can step up to some of the libraries that have been developed to consume those and offer an easier way to go through, so in the netconf model driven programmability space there is actually an open source project called the YDK, it's Yang Development Kit that was spearheaded most of the development actually comes out of Cisco, which aims to wrap up the data models in a Pythonic library, so that you don't native API calls, you can just work with them through a Pythonic library. Then there's the configuration management tooling that's out there, so the good folks over at Spotify started out the Napalm project, which is all about multi vendor network configuration pushes, so that's a library that is often used by a lot of organizations, trying to actually push out and maintain true configuration standards across, and then there's newer ones that are popping up here and there, as new challenges are being designed and extended out.

32:23 Michael Kennedy: Yet Napalm looks pretty interesting, I had David Barroso on Episode 128 to talk about that, the idea there is that you have a unified API regardless of the underlying devices, so it handles the inconsistencies across the different providers and such right?

32:39 Hank Preston: Yeah Napalm is one of a handful of libraries aim to do that same thing, as many organizations and engineers have to deal with different network platforms from multiple vendors, or even if you're just Cisco, you've got multiple platforms that are there, and then there's another tool called Nico, that tries to say let's have standard ways through Python to write the code, and then the libraries themselves, understand the intricacies of interfacing with specific platforms and a specific software version, and you can focus on a very consistent commands and capabilities.

33:13 Michael Kennedy: I feel like the cloud is the new lock in, if you're on AWS and you deeply use their APIs, it's extremely hard to move along right, and the same thing for Azure, they're all different APIs and they all have different capabilities, I'm not thinking just VM's, I'm thinking their cloud storage, database offering, all these different things, I think that's why we see Microsoft just go yeah we don't actually care if you use Windows or not, or Office because we've got something better thanks.

33:41 Hank Preston: Well I think that's the piece that goes through, there's the nasty term of lock in, nobody wants to be locked in, and I think the dirty secret is, you're always locked into something, you just have to pick where you want your flexibility to be, what you're willing to be locked into, and then know that you made a commitment there, I had an interesting conversation with a Director of Cloud, one of the customers I was talking to, and he said look, and this was an organization that had been around for a hundred years, we made a decision decades ago that we were going to go into the mainframe, and we were locked into the mainframe and it served us well, and there are ups and downs, but that worked well for us, and at this point they were making the decision to lock themselves in to a cloud provider, because they knew if they jumped in and they took advantage of all the value-added services that the cloud provider had and embedded those into their applications, they knew full well there was no way that they were going to be able to move without some significant costs, it was like the days when they had to transition from a mainframe or a Itanium on the x86, that was a big project, it was a huge thing, there had to be some massive controlling event. The cloud is doing the same thing, organizations that want to take advantage and accelerate their development by taking advantage of all the services that AWS or Google or Azure offer, they do that hopefully knowing at the price and at the cost, and with luck the person that made that decision for the organization kind of had the right to make that decision for the organization.

35:09 Michael Kennedy: Yeah that's an interesting point, But I definitely do see that as if you're willing to commit you get full advantage of it, but you are committed. But locking themselves into mainframes that was a good idea for many years for a lot of these companies, so it's a choice, it is interesting I think. This portion of Talk Python To Me is brought to you by Brilliant.org, many of you have come to software development and data science through paths that did not include a full on computer science, or mathematics degree, yet in our technical field you may find you need to learn exactly these topics, you could go back to university, but then again this is the 21st century and we do have the Internet, why not take some engaging online courses to quickly get just the skills that you need, that's where Brilliant.org comes in, they believe that effective learning is active, so master the concepts you need by solving fun and challenging problems yourself. Get started today, just visit talkpython.fm/brilliant, and signup for free, and don't wait either, if you decide to upgrade to a paid account for guided courses and more practice exercises, the first 200 people that sign up from Talk Python will get an extra 20% off an annual premium subscription, that's talkpython.fm/brilliant. So I guess the reason I bring that up is Napalm having the ability to have this unified API lessens that lock in just a little bit.

36:34 Hank Preston: And I think that's something that a lot of customers and engineers are looking at network programmability to give them that feature set to go through. So it used to be you are locked into a networking platform, because that's what you built your automation around, you knew how to configure, that was a tool that you had, so today if you say my locking choice is going to use Napalm or we are going to use Ansible, or we are going to use Puppet or Solve, or Cisco's NSO platform, or one of these tools that's going to be our point of interaction, as long as you work with those were happy with it. So that's the thing were starting to see, its organizations saying this is our tooling choice, how do you fit into this tooling choice, because they want the ability to Lego block and swap in and out underneath the tooling choice, because that's their entry point.

37:23 Michael Kennedy: That's really interesting, another one that you brought out was Nornir, I'm not sure that pronouncing that right, but that seems to go very Pythonic one, they're deeply embracing Python is the way, do you want to talk about that a bit?

37:36 Hank Preston: Yeah, so I'm not super familiar with it, I'm just starting to learn it myself, and it's a new one that came through, David from Napalm as well as Kirk Byres who did the net nico program and some other pieces have joined forces to build up this new automation framework for Python, and it's very much designed to be a Pythonic mechanism to go, a lot of the stuff that it talks about is rather than working in some domain specific language, where you're limited by what that domain specific language is capable of, what you are able to describe, with Nornir the idea is we want to give people the full power of Python, let's not rewrite programming, let's not shackle what's possible, let's say here's how will go through, and Nornir is a library like I said, and what's been interesting is we talked a little bit about the levels of abstracting and consumption, is as I looked at Nornir under the hood it's leveraging tools like Napalm to actually do the interface configuration, so it seems like we're getting these Russian nesting dolls of libraries.

38:38 Michael Kennedy: It's turtles all the way down.

38:38 Hank Preston: You just pick up, we're going to use this one and then when you look under the hood and you do pip freeze, you realize all of the other things under the hood it's using, and this new fancy library is actually not doing all that much on its own, not to limit or minimize what these libraries do, but that's the idea I think one of the values of these offer is that they're building on top of a foundation that's already been laid. And so we see that inside of all of these tools that go through. I think what is really interesting about Nornir is the fact that they have fully embraced Python, because one of the comments we see over and over, and you'll see the Twitter debates on this one, is don't use Ansible as a programming language, and people are like why not, I can program in it it's not a big deal, it's like but you can't really do it and then there's the debates that go back and forth, and it seems like in the networking space, there is starting to see this push for some of the early adopters, the folks that have got tons of battle scars from trying to do things in an interesting way, saying you know what we need to go back, we need to make sure that we've got more control over what's possible. Network engineers at our heart have always really enjoyed toying with nerd knobs, having access to all the features, understanding what's going on, and I think we're starting to get that maturity level across in areas of the industry to say, we need to dive into this a little bit harder, have a little bit more control, have a little bit more flexibility to what's there, because despite the fact that they don't want to be locked into a platform, they also want to be able to do whatever they can with those platforms that they've chosen, and if you're limited by what you're allowed to do inside your infrastructure, because some automation tool doesn't support it, now we have to extend our automation tool and make some other choice.

40:22 Michael Kennedy: Right, they highlight a lot of interesting, what they call benefits of the Nornir project, like a domain specific language, DSL can get complex when you get into advanced stuff, so avoiding the complexity code might not be avoided anyway, code is easier to debug, you can actually just set a breakpoint and debug it, you might write code anyway, you can leverage your IDE for linting, and I think the final one is pretty interesting that they list here, it says a side benefit of using this is it'll also teach you Python, which are found to be a lot more useful than just knowing a DSL. For example you might learn Nornir, but now you know Python, and if you need to get another job, it's not well I can program Ansible, I can actually program full stop right?

41:08 Hank Preston: Exactly, and that's the piece that comes through, a lot of folks ask me should I learn Python or should I learn Ansible to automate a network, and my answer to most folks is you need to learn both probably, Ansible is a great tool, it's super popular in the network automation space today for a variety of reasons, and I don't see that popularity going away, but one of the things that comes up time and time again, is engineers and enterprises will get to a point with a tool like Ansible, and then figure out okay I can't go any further, and it's one of the points that you call out, is they need an advanced feature, or you need some piece of logic element, or the need to do something, and they just can't do it with a tool like Ansible that's there, so now they're either writing their own Python code, to consume as Ansible, or they revert back and start doing something else with a tool like Napalm or Nornir, and I think it's going to be this pendulum swing that goes back and forth, as we start a little bit with Python, we get frustrated because it seems like we're doing a lot of stuff that should be easier, you move to a higher level tool, you get frustrated 'cause now you're limited with what you can do, but now you've learned a little bit more, and you go back and forth, and I think every organization and every engineer will find this sweet spot of what to consume and what to build yourself.

42:24 Michael Kennedy: Yeah I think it's only going to get better, there's only more stuff on PyPI that you can pip install.

42:31 Hank Preston: Absolutely, absolutely.

42:33 Michael Kennedy: I think last time I looked it was like 147,000, but I haven't been counting for a few weeks, so it's probably even higher, it's insane, it's great.

42:40 Hank Preston: It's getting to a point now where you got to be careful, the number of times the pluralization of a package has thrown me off, where I swear I installed the package I wanted, and then come to find out instead of installing requests I installed request which is a completely different library and works in a completely different way.

42:56 Michael Kennedy: What do you mean this function is not here, I don't get is on requests.

42:59 Hank Preston: I know it's...

42:59 Michael Kennedy: No, that's plural, that's right.

43:01 Hank Preston: Those come up time and time again as it goes in, and I love the fact that anybody can build something and post it to PiPI, that's awesome, the barrier to entry is so low, I think that's part of what makes Python kind of Python, but there's also that piece I have to remind folks, is just because you can pip install something, doesn't mean that you should necessarily trust it with what's going to go on, do a little bit of research, go figure out what's there, is this a mature library, are there other people using it, is it maintained. And that's another skill set out of programming that network engineers need to start to learn, is that it's very easy to grab something and not understand what it is, and the skill set of not just copy and pasting from Stack Overflow is one that we have to remind people over and over again.

43:45 Michael Kennedy: Yeah that's a super interesting thing to evaluate an open source project, whether you want to take it as a dependency, because if you have a billion company that depends upon this thing but it's actually some freshmen student's little project that they threw out there that has four stars on GitHub, and they've since moved on to some other language and they don't even care about it any more, that's a shaky foundation.

44:10 Hank Preston: Exactly.

44:11 Michael Kennedy: But you've got to know to look?

44:12 Hank Preston: Audio blew out there for second, the other piece that comes in that's very related to just the reliability and the upkeep for it, is the impact of open source licensing goes in to some of these areas, we are starting to get more and more conversations with lawyers getting involved to say what is the impact of using that open source library, is there something in there that says that they have a portion of our company now because we happen to use their library to configure the network, those are interesting discussions as we start code and just use community delivered applications, I think it's not limited just to network engineers, but because we are new to the programmability space, and we didn't cut our teeth on some of these other areas, I've seen several folks be very surprised to find out what the impact of some of these choices they've made has been.

45:02 Michael Kennedy: Yeah it definitely can catch you off guard, so while we're talking about learning these new things and stuff you have to learn, maybe it's worth highlighting this project, would you call it a proper course that you created called Learn Network Programmability Basics?

45:14 Hank Preston: Yeah it's a great one that goes through, and so the Network Programmability Basics video course was designed very specifically to help network engineers jumpstart into programmability and automation. The question we get more often than not is how do we get started, because there's this overwhelming nature, there are so many topics that are out there, so what I did inside the course was say okay, let's break down the basic fundamental information that you should know. So we talk about programming basics, so we go through some Python fundamentals, we go through what are APIs, we talk about those elements, and then we walk up the network structure tree starting with device level APIs and then going into SDN controllers and network controllers, we talk about capabilities around hosting applications at the edge, there's some cloud computing pieces, and then even get our way into this net dev ops space, where we're starting to treat the network as code, and we're adopting things like configuration management strategies, an CIC in the network, the Network Programmability Basic video course is definitely not designed to turn somebody into an expert, my goal when I put it together was to give enough background knowledge, define enough terms, expose people to some concepts and give them a chance to run code themselves against infrastructure in a controlled fashion. And so that they are more prepared to take that next step to say okay I've seen a little bit of Python I know what these APIs are, I know what the library does, now I am a little bit more comfortable to go do a little bit of googling and research to take a class on Udemy, or go grab something of an area or sign up for another piece. That's really the focus of the material we have there is to do that jumpstart, I like to joke, my goal is to speed people up somewhere in the two to four month range, let's cut two months off of your journey to understanding network automation, if I can help you do that I've been successful inside of that course.

47:11 Michael Kennedy: Yeah that's really awesome, and I think one of the jobs of the most powerful courses is not to teach you all the way down through the stack of what they're doing, but to expose you to just enough of all the things so you're like, I know there's this thing that solved my problem, and I know a little bit about it and I now know where to go to look to learn it, it's almost like this paradox of choice, or this overabundance, is not a scarcity of things you can use, there's so many things I can use I don't even know where to start, so having that first step in the right direction for all these different things is really powerful.

47:45 Hank Preston: Exactly, it's easy to be overwhelmed in any topic today, the Internet just makes it ridiculous, for how much information that goes through, so that's been the purpose of the video course, as well as the other research that we put together, and we curate on devnet, let's give a network engineer, let's give a collaboration engineer, or a server engineer, a somewhat curated entry point so we can start to define those terms and expose them to the art of the possible. I like to say my job is an evangelist, the evangelism side of my job is to show people what's possible, give them a glimpse of the future and get them excited for it, so they're willing to invest more time, and to go figure it out themselves and put the time in.

48:27 Michael Kennedy: Yeah I think that really sums it up perfectly, so I think maybe we should leave it there for the networking, but I did want to ask you a question about PyCon, because you're in Ohio and you were just at PyCon, it was in Cleveland this year, which was a great experience. I feel like a lot of people don't go to PyCon, because they're like that's for the hard-core developers, maybe speak to the people who are somewhat in your space who feel like PyCon isn't for them, what was your experience there?

48:55 Hank Preston: I love my experience of PyCon, this is my first year going to PyCon, I'm looking forward to next year and going back, it's back in Cleveland again, so it's going to be super easy for me to get to, so I'll definitely be there. The organizers were super friendly, all of the presenters were amazing and going through, and it's one of the things I really loved about the Python community in general, and it certainly showed at PyCon, was the inclusive nature of where everybody's at. It doesn't matter if you have written a library that 150,000 people are using on a daily basis, or if you've just written your first hello world app, you will have a good time at a conference like PyCon. Then what was interesting for me from the network programmability perspective, is I was just there as an audience member, I was going through I was attending talks, and then at open spaces where anybody could sign up for a topic, grab a room, and then people could go talk about stuff, and I noticed that somebody signed up, Python for Network Automation open space, and I was like wow, there's other people here doing this, and so I went and sat through it and talk with a whole bunch of other people and I was excited to see that there was probably 30 or 40 people there just at the open-space part of it that were interested in using Python for network automation, and these ranged from engineers from companies like Facebook and Netflix and Amazon, all the way down to small mom and pop shops there are just using a little bit for their own automation, as well as students that are just interested in networking, and trying to figure out where Python fits in. I encourage everybody if you have the opportunity to go to PyCon, whether it's the big global one or regional one, or even one of the regional conferences, we just had PyOhio here in Ohio, go and become part of the community, it's a wonderfully inclusive and welcoming community, and you'll meet some really good people.

50:42 Michael Kennedy: Yeah that's great I'm glad you brought up the open spaces, because from the outside the conference probably feels a lot like, there's these talks and the talks are on YouTube so I don't really need to go, I find the talks to be interesting and powerful, but actually it's all the other stuff that makes it worth going, it's really amazing.

50:58 Hank Preston: I think they call that the hallway track, you can't do the hallway track on YouTube after the event you can only get that while you're there.

51:05 Michael Kennedy: Not unless you get a friend to stream it live.

51:06 Hank Preston: That would be interesting.

51:09 Michael Kennedy: Actually it would wouldn't it, but the open spaces are not recorded, you don't have to have any particular skills to run an open space, you have to have the willingness to put it on the board, and a willingness to kick off the topic, you don't even have to lead it, you just have to say I want a bunch of people who were interested in network programming to get together, and that's it you could be I have no idea but I wanted to talk to you all, so here we are, it's awesome.

51:31 Hank Preston: It's great to go through, so it's an awesome conference, so I encourage everybody to go, if you're on the fence sign up.

51:36 Michael Kennedy: Yeah I'm definitely looking forward to going, I'll get my ticket as soon as it opens up.

51:40 Hank Preston: Exactly

51:41 Michael Kennedy: I think I'll leave it there for the topics, so now we're down to the final two questions, if you're going to write some Python code what editor do you use?

51:48 Hank Preston: Yes so I go back and forth depending on what I'm writing, if I'm writing Python code and it's focused on sample or demo or just proof of concepts, I go pretty lightweight these days and I use Atom. It open's quick, it has exactly what I'm after, no more no less, when I sit down to work on an actual Python project, there's a couple of libraries I work on there's a couple of programs I go through, I always go back to the first editor that I fell in love with which was PyCharm. I always find myself back into PyCharm, I love the integration capabilities that are there, I love being able to work in the interface and go through, and so I bounce between the two of those depending on which project I'm working at any point in time.

52:28 Michael Kennedy: Yeah that's cool, I do that with VS Code and the Python plugin and PyCharm of course, so if it's something really really quick I just want to open up and look at it, probably throw it in VS Code, but otherwise PyCharm as well.

52:38 Hank Preston: It seems that there is a big debate in my team there's half of us like Atom and the other half of us are big VS Code folks, and for me it's one of those, if I've got something that works for me I'm perfectly happy to use it, I don't need to go explore other tools that are there.

52:52 Michael Kennedy: Yes, sure, well you guys can at least rest assured that they're owned by the same company.

52:57 Hank Preston: That is true, that is kind of funny, I'm interested to see if they end up merging as products.

53:01 Michael Kennedy: I don't know if they will, Nate Friedman the guy who's going to be the CEO, maybe is the CEO of GitHub, I don't know when he officially starts, he came out and said we're not dropping Atom we're going to keep working on it, people love it, we're going to do these things at least in parallel now.

53:16 Hank Preston: That's great, excellent.

53:17 Michael Kennedy: Yeah good to hear right, alright last question, notable PyPI package?

53:20 Hank Preston: I'm going to call out NC Client for me, NC Client is the Netconf client for Python, and I go back to it time and time again for my automation these days, because as much as I love the higher order packages that we talked about like Napalm and Nornir, I'm still at the tinker level and I like to get right down into it, so that's always one that I go back to.

53:41 Michael Kennedy: That's awesome, alright well Hank, thanks for being on the show, it's been really great to talk to you about all the stuff and I think there's a lot of interesting lessons people can take away from learning how network engineers are moving this programmability, because so many different disciplines are.

53:56 Hank Preston: Absolutely, thanks for having me Michael, I appreciated the opportunity.

53:59 Michael Kennedy: Yeah you bet, talk to you later. This has being another episode of Talk Python To Me, my guest on this episode has been Hank Preston, and it's been brought to you by Linode and Brilliant.org. Linode is bullet-proof hosting for whatever you're building with Python, get four months free talkpython.fm/linode, that's Linode. Brilliant.org wants to help you level up your math and science through fun, guided problem solving, get started for free at talkpython.fm/brilliant. want to level up your Python? If you're just getting started try my Python Jumpstart by Building 10 Apps, or our brand-new 100 Days of Code in Python, and if you're interested in more than one course be sure to check out the Everything Bundle, it's like a subscription that never expires, be sure to subscribe to the show, open your favorite podcast chart and search for Python, we should be right at the top, you can also find iTunes feed at /itunes, Google play feed at /play, and direct RSS feed at /rss on talkpython.fm, this is your host Michael Kennedy, thanks so much for listening I really appreciate it. Now get out there and write some Python code.