#175: Teaching Python to network engineers Transcript

00:00 Network engineering is quickly moving towards a world where it's as much programming and automation

00:04 as it is packets and ports. Join Hank Preston and me to discuss what parts of Python are

00:09 important for network engineers to learn. This is Talk Python to Me, episode 175, recorded August 8th, 2018.

00:16 Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.

00:36 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

00:44 and follow the show on Twitter via at talkpython. This episode is brought to you by Linode and Brilliant.org.

00:51 Check out what they're offering during their segments. It really helps support the show.

00:55 Hank, welcome to Talk Python. Thanks, Michael. Thanks for having me. Yeah, it's great to have you here.

01:00 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.

01:11 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.

01:21 And we're going to talk about programming for network engineers.

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

01:28 Yeah, that's awesome. So before we get to that, let's focus on your story and just talk about how you got into programming in Python.

01:36 Where did it all start?

01:37 Yeah, so it's good. So my story and my rapid love affair with Python started, I would say, I think it was about five years ago.

01:44 And I was working at Cisco, which is where I currently am now, as a systems engineer and solutions architect focusing on data center topics.

01:51 And around that same time, the cloud kind of tidal wave was hitting everybody.

01:57 And so part of our role...

01:59 What year was that?

02:00 Yeah, I'd have to go back and look.

02:01 I mean, somewhere in the 2012, 2013 area is where it kind of...

02:07 It'd been there for a while, but that's where it started to affect my day-to-day job.

02:11 Right. It kind of left the, hey, all the startups are doing it.

02:14 But the Fortune 500, they're going to never touch the cloud ever, ever, right?

02:19 Until they did.

02:20 Yeah, no. And that's really what it was going through.

02:22 At that point, the customers I was dealing with mostly were like the Fortune 500s, enterprise customers in the Midwest.

02:29 And we were starting to hear from the likes of these large kind of Fortune 500 and Fortune 100 customers that they're starting to experiment.

02:37 Or they've realized that they had been experimenting in the cloud for a long time.

02:41 It's just nobody told them that they had stuff that was out there, which was always fun.

02:45 So as this was going through, I had one of my managers came up and said, hey, we need to start understanding what this whole cloud thing is.

02:53 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.

03:02 And I had the opportunity to kind of go off and spend some time on a program that Cisco put together around cloud native development.

03:09 And so it was kind of a boot camp approach to diving into a bunch of different topics.

03:13 And it was from containers to cloud applications.

03:16 And part of that program was actually two weeks of Python training.

03:21 I credit Raymond Hedinger with giving me an awesome kind of exposure to Python, diving me in really well.

03:28 His intensive introduction to Python class is the most aptly named technical class I've ever had.

03:34 That's cool.

03:35 Was this an in-person class?

03:36 Did he come out to your equation?

03:38 He did.

03:38 So he actually, I don't know if he's still doing it today because I haven't looked in a while.

03:42 But at that point, he was teaching Python every week for Cisco classes.

03:47 And so he would teach a class in San Jose, and then he'd go down to Austin, and then he'd go to RTP.

03:53 And he would just 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.

04:03 And so this was a class focused on our field engineers to go through and start to help us get prepped into it.

04:10 And he actually had, his classes still exist.

04:14 And I still see them go through the pieces occasionally.

04:16 But it's like an intro, and then it was an intermediate, and then an advanced.

04:19 And I swear, across those three weeks of training classes, it was like a year of intense college study to go through.

04:26 Just the level of kind of depth that he took us and how quick we went in.

04:30 That's really interesting.

04:30 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 Absolutely.

04:41 And that was the piece.

04:42 And normally, many of us have been used to go into 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.

04:52 In this case, it was a very kind of, if you stepped out, you were like lost.

04:57 It was like you lost a week of a college class.

04:59 And so that's where I dove into Python.

05:01 And I mean, within just a couple of days, I realized that programming was different from when I did it originally.

05:08 Because I had a background in some development.

05:10 I had done some Java and C++ and a bit of .NET development, some database work.

05:15 And then I made a conscious decision to kind of go over and move more into the infrastructure space and focus on kind of systems and then eventually networking as kind of a specific domain.

05:24 Frankly, because I wasn't a big fan of Java.

05:26 And I got tired of developing in Java.

05:29 So I gave up on that.

05:30 But when I had this exposure to Python, it was such an easy language to get into.

05:34 The syntax was really kind of readable.

05:37 I didn't need to be a software developer.

05:40 I could kind of dabble with it for a little bit and then come back.

05:42 And I didn't feel like I lost anything.

05:44 I could consume other people's code really easy.

05:47 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 kind of general infrastructure engineering space as kind of a language of choice.

05:57 I think that's a really interesting point.

05:58 And there have been a lot of languages that are easy to read, like VB is a language you could read pretty easy, right?

06:04 Visual Basic.

06:05 But a lot of the ones that are easy to start with have these pretty low ceilings.

06:10 It's like, well, you can build up to this point, but you want to build something real.

06:14 You put that away and you get out the Java, you get out the C++.

06:17 And Python doesn't have really that ceiling quite nearly as low.

06:21 And I think that's partly one of the things that makes it really special.

06:24 Yeah.

06:24 And that's been one of the huge elements for me.

06:27 I mean, I've been doing Python daily for several years now going through.

06:32 And I still go back to some of the fundamental skills that I learned in those early classes.

06:35 But the programs I'm building are much more sophisticated than some of the early ones that go through.

06:40 And when I look at some of the new features that come into the language, they're really exciting things that are coming after it.

06:46 But they're being put in a way that you don't have to use those, right?

06:49 It still gives you this ability to kind of work your way into Python, absorb the capabilities when it makes sense for you.

06:55 And there's a challenge there.

06:56 It's not like with JavaScript.

06:57 It feels like you have to like immediately you're embedded inside of all sorts of promise statements and multiple levels of like embedded.

07:05 And you can't do anything.

07:07 With Python, you can start really simple.

07:10 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:17 Yeah.

07:17 That's part of its sort of elasticity up and down the experience scale, right?

07:22 You don't have, like you said, you don't have to be an expert in all of Python to build interesting things.

07:26 Like you maybe don't even know what a function is, but you could still do some pretty interesting stuff in straight down.

07:32 You know, you don't need to care about code reused or whatever, right?

07:35 Yep.

07:36 It's object oriented under the hood, but you can completely ignore objects.

07:39 Until you realize that there's value in it.

07:42 And hell, half my code still ignores objects, it seems like these days.

07:45 Yeah, that's quite an interesting point.

07:47 So speaking about these days, what are you doing day to day?

07:50 You're a developer evangelist at Cisco, is that right?

07:52 Correct.

07:52 Dev evangelist.

07:53 Yep.

07:53 Yep.

07:54 So I'm a network programmability evangelist with Cisco inside of our DevNet organization.

07:59 So DevNet's the developer enablement program for Cisco.

08:02 And so it's where people that are looking for our API documentation and SDKs and sample code and sandboxes and resources.

08:10 That's all of that's available up on DevNet.

08:12 And my team of evangelists are like you would find in any of the developer enablement programs.

08:18 As we go out and we help people better make use of and understand what's possible with the tools.

08:23 Cisco has a huge portfolio of products from networking to security and collaboration.

08:28 I focus really, really fully in the network automation, network programmability space.

08:34 And so there's tons to keep us busy and there's tons of work out there helping all of these enterprises and the network engineers inside of the enterprises figure out what automation means and how they can start to automate their deployments.

08:48 And what does it take to skill up and make changes?

08:50 And these are the types of things, resources we build, as well as kind of events that we hold and discussions we give.

08:57 So you might be going out and visiting like a group of network engineers who maybe haven't done a lot of programmability automation of networks and you help sort of bring them along or maybe help them design how that applies to their infrastructure or something like that.

09:13 Exactly.

09:13 Yeah, there's there's I usually I frame it in two two cases where it goes through most days these days organizations are recognizing they need network automation.

09:22 And so they're going to their networking teams and saying, OK, we need to figure this out.

09:25 What resources are available?

09:26 And so I can I go into some of those organizations and I'll spend a couple of days helping them and kind of leading introduction to programmability classes.

09:35 And so just last week, I actually spent an entire day with one of my customers.

09:39 We had about 20 engineers in the room and we were going through basics of Python.

09:44 And so what is a Python script?

09:45 How do you create variables?

09:47 What are libraries and what libraries are interesting for the network engineer?

09:51 How do you parse data that comes back?

09:53 Because that's a big part of dealing with clear text versus JSON and all these other.

09:58 Yeah.

09:59 What is JSON?

10:00 How do you process it?

10:01 What is XML and what's a YAML file?

10:04 All of that goes through.

10:05 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 comp sci classes way back when.

10:15 And they may have done similar cases like I did.

10:17 Didn't like Java a whole lot.

10:19 And so went into networking.

10:20 Program is not fun.

10:21 I'm out of here.

10:22 Yeah.

10:22 Yeah.

10:22 Enough of that.

10:23 I'm going to go make packets go across the network.

10:25 So what we're doing now is trying to help remind them kind of some of these skills that are there.

10:29 They start to like knock the cobwebs off some of the fundamental programming stuff they had for maybe 20, 30 years ago when they went to school.

10:36 And then start to add these new elements that are there.

10:39 XML didn't exist for some of these guys when they went through it.

10:42 And YAML certainly didn't.

10:43 And so showing them the value.

10:44 And 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.

10:51 And why is that better than doing it the way that they're doing it today?

10:55 Because that's a big part of the discussion often is showing them that there is value in making this journey.

11:01 Right. Because a lot of them probably didn't decide to be programmers.

11:04 I mean, maybe that's a good way to segue into like what is the background of a typical network engineer?

11:10 Like you said, maybe they have some programming experience, some technical experience, but they probably didn't choose networking because they wanted to be a programmer.

11:17 So what's the story there?

11:19 What do you experience?

11:20 Yeah, they absolutely didn't choose networking because they wanted to be a programmer.

11:24 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.

11:36 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.

11:48 And so there's this blurring and the gap.

11:51 A typical network engineer has a foundation in kind of network theory and connectivity areas that are there.

11:58 So there's the typical kind of OSA model of layer one, two, three, all the way up to seven.

12:03 So they understand the fundamentals of how network traffic works.

12:07 They spend their days dealing with networking concepts like IP space and ports and firewalls and load balancers.

12:15 So all of these elements, these foundational elements that help make applications function that the cloud relies on to go through.

12:22 The network engineer is coming in these discussions with this understanding of how kind of this foundation goes through.

12:28 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,

12:37 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.

12:45 And so for the longest time, and in some cases still today, it's a CLI interface.

12:51 A command line interface is how we configure a network.

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

12:59 Exactly.

12:59 There's there's expect scripting, right?

13:01 So send this and expect to get this back and then send this other one away because there's network.

13:07 Every network engineer I've known really hates having to repeat themselves over and over again.

13:11 And so they've figured out ways to make their jobs better.

13:14 And so that's the big thing I'm trying to show them is this move into 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.

13:26 There is a bit of that, I don't want to say hurdle, but like a plateau to get people over.

13:29 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.

13:35 They understand the value.

13:37 They understand that it's not this thing to be dreaded.

13:39 Right.

13:39 They're like, I don't want to do this.

13:40 This is not my job.

13:41 This is not what I signed up for.

13:42 Wait a minute.

13:42 That's pretty awesome.

13:43 Yeah.

13:43 Okay.

13:44 Maybe it's worth it.

13:44 Something like that, right?

13:45 Exactly.

13:46 Exactly.

13:46 So you talked about getting into Python almost because of the cloud and things like that.

13:54 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?

14:05 Like there used to be these physical things.

14:07 You could log into them and mess with them.

14:09 And now it's APIs and VMs and data centers far away from you.

14:14 Yeah.

14:15 It's completely accurate.

14:16 I mean, it comes back on network engineers ourselves to some extent that it seemed that we got so far away from what a network really was.

14:23 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.

14:32 And so I talk a lot.

14:34 One of the conversations I give is this evolution to networking in the programmable age.

14:38 And I go back in time to when the network really was just routers and switches and servers.

14:43 Yeah.

14:44 You refer to that as the four ages of networking.

14:46 Do you want to take us through it?

14:47 Yeah, exactly.

14:48 And so originally, right, in what I often call kind of like the stone age of networking, things were simple.

14:56 We had servers and workstations and printers, and they connected into switches, and then maybe we had a router to communicate with them.

15:02 And the biggest thing network engineers were focused on is kind of like making sure that spanning tree didn't cause issues in the network and that if they were going to have to use some VLANs to carve computers and printers off.

15:13 Because at that point, the network was you could walk into any closet and you could reach out and touch it.

15:18 It was usually like teal green and had Cisco written on it, and that was the network.

15:23 And there were cables, and it was really easy.

15:26 But over time, the first hint of the kind 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.

15:36 And the concept of a V switch came out.

15:39 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 a hypervisor.

15:50 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.

15:58 And so there was this huge challenge that went through.

16:01 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 because it doesn't really matter.

16:11 And then as we moved from kind of that stone age, that early piece that went in into the dot-com era and all of these other pieces, new things went after us.

16:20 After x86 virtualization, we got blade switches.

16:24 And so we had these new physical pieces.

16:26 But rather than buying a blade switch from a networking vendor, maybe it's being bought from a server company.

16:33 And so networking guys were once again saying, you know what, that's not my stuff.

16:37 I'm not going to deal with it.

16:38 And then what was it, two years ago, we started to see kind of the container explosion.

16:42 And 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.

16:51 And the networking guys are finally realizing that there is a lot of networking that is happening outside of their physical switches.

16:59 And that's been a big kind of aha moment.

17:01 And then we can bring in the cloud elements.

17:04 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.

17:11 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.

17:17 Because you don't own those physical switches.

17:18 Yeah, the one final bastion of thing they claimed is theirs has now been virtualized and moved out.

17:25 And so now it's all the other stuff.

17:27 They're like, well, that's not really my problem.

17:29 Like, that's like what's left that they now need to work with, right?

17:32 Exactly, exactly.

17:33 And 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 AWS is the cloud or Google or Azure or one of these other cloud providers.

17:51 This idea of cloud is just kind of an approach, a fully programmable approach to infrastructure.

17:56 And so I've got customers today that consider their data centers their cloud on that side as well.

18:01 And they want to manage their clouds the same way that they consume and manage their other ones.

18:06 This is with this huge pressure.

18:08 Yeah, I think it is.

18:09 And I think what's really interesting is, you know, there's this joke or, I don't know, sarcasm or whatever that says, you know, the cloud is really just somebody else's computer.

18:19 Yeah.

18:19 Right.

18:20 Which I think that's a little bit disingenuous.

18:22 Technically, it's true.

18:23 Someone owns the computer.

18:24 But I think fundamentally, the cloud is a programmable set of infrastructure that you don't have to go touch, right?

18:32 And that programmability could be within your data center.

18:34 It could be AWS.

18:35 It could be somewhere else like Linode or something, right?

18:38 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:46 Yeah, I think that's accurate.

18:48 The idea that the cloud, you don't have to worry about the infrastructure is true if you're consuming cloud.

18:54 But there's also this other group of engineers that are building clouds, right?

18:59 Right.

18:59 And somebody has to do that.

19:01 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.

19:12 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.

19:23 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.

19:32 But now you have to have a team that can build the infrastructure that can offer that service.

19:38 And that, I think, is the huge pressure.

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

19:45 Exactly.

19:45 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.

19:53 They were doing a lot of work in the networking space.

19:55 But they were starting to get requests from application teams and systems and services teams to offer the network services through an API interface.

20:06 And so they were starting to build an API that their application teams could consume and their operations teams could consume to make general connectivity or logging requests or information.

20:17 And so we got to actually, it was a really fun project we did because we got to show, okay, well, let's talk about API design.

20:23 How do you build an API?

20:24 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 All of a sudden you're put into the place where like you have to compete on API design with Google and Amazon, which, you know, just a while ago, maybe you were even really interested in writing APIs and you're kind of in the deep end at that point, right?

20:48 Exactly.

20:49 And those are the interesting pieces that are coming at it.

20:51 And organizations are getting these changes and these adjustments so fast these days.

20:56 And I think that's a big challenge that every industry has, but certainly the network engineers have.

21:02 It's trying to figure out how do they keep up?

21:04 How do they, it's, there's always that analogy of you're laying the track as the train is kind of approaching.

21:09 And I think that that's never going to change in the IT space.

21:12 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.

21:21 And this adjustment to cloud and programmability and automation is this massive pivot.

21:26 And so now we've got a lot of engineers and network engineers out there just trying to figure out how do I keep up, right?

21:31 What do I learn next?

21:32 Where do I go through on this area?

21:34 And that, that sense of overwhelming nature.

21:36 And my, my advice to them is, okay, yes, there's a lot, but remember this is an exciting time, right?

21:42 We were talking about how bored we were two years ago.

21:44 Now you've got cool stuff to work with.

21:46 Let's look at the value of what all of this new stuff has for us.

21:49 This portion of Talk Python to me is brought to you by Linode.

21:54 Are you looking for bulletproof hosting that's fast, simple, and incredibly affordable?

21:58 Look past that bookstore and check out Linode at talkpython.fm/Linode.

22:03 That's L-I-N-O-D-E.

22:05 Plans start at just $5 a month for a dedicated server with a gig of RAM.

22:10 They have 10 data centers across the globe.

22:12 So no matter where you are, there's a data center near you.

22:15 Whether you want to run your Python web app, host a private Git server, or file server, you'll get native SSDs on all the machines,

22:23 a newly upgraded 200 gigabit network, 24-7 friendly support, even on holidays, and a seven-day money-back guarantee.

22:30 Do you need a little help with your infrastructure?

22:32 They even offer professional services to help you get started with architecture,

22:37 migrations, and more.

22:38 Get a dedicated server for free for the next four months.

22:42 Just visit talkpython.fm/Linode.

22:47 Yeah, that's got to be interesting to be in that position.

22:50 Because I feel like network engineers were fairly, they didn't feel the full pressure of all this stuff.

22:57 Like the changes that we feel constantly in software development.

23:00 Like, I mean, imagine you're a JavaScript developer.

23:03 Like, you just learned one front-end framework.

23:05 And it's like now ridiculous to use it.

23:08 There's a new one, right?

23:08 Yeah.

23:09 That's like three weeks together.

23:10 It's just constantly like that.

23:11 Python's a little less bad.

23:13 But this does sort of hit them, not out of the blue, but I think it's kind of a wave, a tidal wave type thing.

23:18 I think also like sysadmins probably had a similar experience as well.

23:23 I've seen it in the same, I mean, the installation, I think the farther you get from the end product, and the end product for most of these cases is some piece of software someplace.

23:33 And so the farther you are from the end product, the longer it took for some of this pressure to kind of go through.

23:38 Because software developers solved a lot of the things on their own, and then eventually it kind of overflowed into the systems teams.

23:45 And so now the server teams had to figure out how to deal with the capacity and the agility.

23:50 And then eventually that overwhelmed them to storage.

23:53 And we're getting it into security now, security and networking now.

23:57 And that's where this insulation is breaking down, because it was this like tidal wave that was just pushing and pushing and pushing.

24:03 And eventually it just kind of knocked the wall over.

24:06 And all this demand is coming at network engineers to be agile, to be secure, to offer segmentation, to be able to implement.

24:13 We're getting requests for machine learning and artificial intelligence inside of the network now to make network decisions.

24:19 And I'm still teaching Python 101 to folks.

24:22 And they're also asking, well, where does blockchain fit in?

24:25 It's all of these topics that are coming in at the same time, which is good and bad.

24:30 Certainly keeps the job interesting.

24:31 Yeah, you've got to have the right mindset.

24:33 But it definitely sounds like a fun and exciting time.

24:36 So that's some of the ways that automation and Python have sort of changed the role for network engineers.

24:43 What else is changing for them?

24:45 What else is Python sort of changing that I don't even know to ask about?

24:49 Yeah, I mean, I think that's the interesting one that goes through.

24:51 One of the impacts of using Python to automate your network is kind of all of the things that come along with that.

24:58 Because now they are writing some code someplace.

25:01 And so there's all these new strategies around kind of where do we put code?

25:05 And so at the same time we're teaching Python, we're teaching source control strategies.

25:09 Of course.

25:09 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 down kind of a pipeline path and go in.

25:20 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.

25:33 But they say, you know, I don't have to learn Python.

25:35 I can just go learn Ansible and fix all these issues and I'll just go down that path.

25:39 And 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 really need to understand the Python under the hood.

25:49 I can't just kind of absorb some new open source tool to make everything better.

25:53 Yeah, for sure.

25:54 Of course, that whole software carpentry side of things has got to come in, right?

25:58 Like as soon as you start to depend upon Python scripts to do your job, it's like, well, we should actually version control this and how do we share this together and how do we test it?

26:07 And just, you know, all those layers just start to come crashing in.

26:10 It's pretty interesting.

26:11 I had a question came in to me over LinkedIn.

26:14 It was two days ago and it was from a network engineer who I've been talking with for a while.

26:18 And he's like, all right, here's the challenge we have is I've got people across my organization writing automation scripts to do really interesting things.

26:26 And we've made a lot of progress, but now we've got islands of automation and everybody's automation looks different and nobody can use everybody else's automation.

26:34 So how do we, how do we bring these things together?

26:37 And so we started to talk about things like coding style guides, right?

26:41 You have to come up with some, some approach and styles, not syntax, which means there's no right or wrong way.

26:47 It's, it's kind of a consensus.

26:49 Somebody has to say, this is how we do things.

26:52 And then kind of making sure that people aren't porting their code and their scripts kind of on their machine and start to collaborate through repositories and go down that path.

27:02 And, and that's an interesting piece that goes in.

27:04 Moving network engineers away from the days where they, they would store their information in text files that were their version control was .v1, .v2, .v3.

27:13 You really got to save it and zip it up.

27:16 Yeah.

27:16 Yeah.

27:16 Yeah.

27:17 And then teaching them just the magic that's offered and available inside using some sort of source control and version control system goes through.

27:25 We spend probably just as much time trying to teach fundamentals of source control as fundamentals of Python and some of these early workshops, because that's what it takes to be successful in these areas.

27:36 And having, having, having approached this myself and kind of stumbled my way through it, there's, there's things that I wish I would have started doing sooner that I'm trying to help network engineers today kind of learn from the mistakes that I made rather than having to go make the mistakes themselves.

27:50 Yeah.

27:51 Coming through this path, it sounds like many of them do.

27:54 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.

28:04 Well, there's actually this algorithm in here and these are the inputs of the algorithm.

28:08 How do I turn this actually into say a library or a project someone else could consume?

28:13 And how do we start to build these building blocks?

28:16 I think that's probably an interesting transition as well.

28:19 Yeah.

28:19 It's interesting to go through.

28:20 I mean, one of the, one of the strategies we use to try to break down the learning of automation and the value, the value prop that's there is, is we sit down and we say, okay, well, what are, what are like the five things that you spend almost every day doing?

28:33 Or maybe we take a trouble ticket.

28:35 What every trouble ticket comes through.

28:37 Every organization usually has like, these are the information you need to gather before you ever start working on a trouble ticket.

28:43 Well, let's, let's figure out how we can automate that.

28:46 And then we break those up into these little pockets.

28:49 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 that go through.

28:57 And then the goal is by, is to show them how they can then consume everybody else's work and say, okay, well, we can pull in this other person's piece of code.

29:05 And so you don't have to do that.

29:06 And so you don't have to redo that yourself as long as you're kind of abiding by these kind of ideas of how these libraries work or inputs and outputs that go through it.

29:13 You don't care.

29:15 Like, it doesn't matter what happened inside of their function.

29:17 You just know what you need to send it and what to expect to come back.

29:20 And if we all agree on that, well, you saved yourself two hours worth of work.

29:24 Every day.

29:25 Yeah.

29:25 Or something like that, right?

29:26 Absolutely.

29:26 Yeah.

29:27 That's pretty awesome.

29:29 So maybe now's a good time to talk about some of the major packages that people might use for in this programmability space.

29:36 So, of course, probably a lot of these devices have direct APIs and you could, you know, create a JSON request and like send a post or something over.

29:45 But it's probably better to use some higher level library, right?

29:48 Yeah.

29:48 So there's a bunch of them that go through.

29:50 And so we've mentioned Ansible already.

29:52 Ansible is written in Python.

29:53 Most people just use it as a program rather than as a library.

29:57 But we do have some folks writing Ansible modules to extend out the capabilities that are there.

30:03 Right.

30:03 Most of the time, programming Ansible is like constructing YAML files, right?

30:07 Exactly.

30:08 And until the module you need isn't there or it's not working exactly right.

30:13 And so those go through.

30:14 But for folks building kind of the raw Python and they want to go down that path, I always start with the fundamental toolkits, right?

30:22 You mentioned the APIs.

30:24 And so the key networking APIs today are basic REST fundamentals.

30:28 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.

30:34 So that's an early one we teach.

30:35 Inside of the networking space, the long-lauded and also kind of disparaged API of SNMP still exists.

30:44 And so occasionally we work with PI SNMP to work through and bring SNMP details in.

30:49 But frankly, the newest interfaces, and these are new standards that were developed by the IETF 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.

31:06 And then these interfaces return data either in XML and JSON.

31:10 So now we're getting into kind of true programmability interfaces.

31:13 And so the NC client library is what we use to communicate with netconf at their, with the netconf protocol.

31:20 And then after we get kind of, let's say, 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 kind of consume those and offer an easier way to go through.

31:35 And so in the netconf model-driven programmability space, there's actually an open source project called YDK.

31:41 It's Yang Development Kit that was spearheaded, and 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 have to make native API calls.

31:54 You can just work with them through a Pythonic library.

31:57 Then there's the configuration management tooling that's out there.

32:00 And so the good folks over at Spotify started out the Napalm project, which is all about multi-vendor kind of network configuration pushes.

32:08 So that's a library that's often used by a lot of organizations trying to actually push out and maintain true configuration standards across.

32:16 And then there's some newer ones that are popping up here and there, kind of as new challenges are being designed and extended out.

32:22 Yeah, Napalm looks pretty interesting.

32:24 I had David Barroso on episode 128 to talk about that.

32:28 The idea is there that you have a unified API regardless of the underlying devices, right?

32:34 So it kind of handles the inconsistencies across the different providers and such, right?

32:39 Yeah, Napalm is one of a handful of libraries that aim to do that same thing.

32:44 As many organizations and engineers have to deal with different network platforms from multiple vendors.

32:50 Or even if you're just Cisco, we've got multiple platforms that are there.

32:53 And so within Napalm, and then there's another tool called NetMiko that tries to kind of say, okay, let's have standard ways through Python to write the code.

33:01 And then the libraries themselves understand the intricacies of interfacing with a specific platform or specific software version.

33:08 And you can focus on kind of very consistent commands and capabilities.

33:13 Yeah, I feel like the cloud is the new lock-in.

33:16 If you're on AWS and you deeply use their APIs, it's extremely hard to move along, right?

33:23 And same thing for Azure, right?

33:25 They're all different APIs and they all have different capabilities.

33:28 And I'm not thinking just VMs.

33:30 I'm thinking like their cloud storage, their database offering, all these different things, right?

33:35 I think that's why we see Microsoft just go, yeah, we don't actually care if he's Windows or not or Office because we got something better.

33:40 Thanks.

33:41 Well, I think that's the piece that goes through.

33:43 I mean, everybody's always, there's this, the nasty term of lock-in.

33:47 Nobody wants to be locked in.

33:48 And I think the dirty secret is you're always locked into something.

33:52 You just have to pick where you want your flexibility to be, what you're willing to be locked into.

33:57 And then know that you've made a commitment there.

33:59 I had an interesting conversation with one of the, a director of cloud and one of the customers I was talking through.

34:05 And he said, look, we made, and this was an organization that had been around for a hundred years.

34:09 We made the decision decades ago that we were going to go into the mainframe and we were locked into the mainframe and it served us well.

34:16 And there were ups and downs, but, but that worked well for us.

34:18 And at this point they were making the decision to lock themselves into a cloud provider because they knew if they jumped in and they took advantage of all of the,

34:27 the value added services that the cloud provider had, and they 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 cost.

34:37 It was like when the days when they had to transition from a mainframe or Itanium onto x86, right?

34:43 That was a big project.

34:44 It was, it was a huge thing.

34:46 There had to be some massive component event.

34:48 The cloud is doing the same thing.

34:50 Organizations that want to take advantage and accelerate their development by taking advantage of all of the services that AWS or Google or Azure offer.

34:58 They do that hopefully knowingly at the price and at the cost.

35:02 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:08 Yeah, that's an interesting point.

35:10 But I definitely do see that as like, if you're willing to commit, you get full advantage of it, but you are committed.

35:17 Yeah.

35:17 Yeah.

35:17 You're there.

35:18 Yeah.

35:18 But locking themselves into mainframes, that was a good idea for many years for a lot of these companies.

35:23 Right.

35:23 So it's just, that's a choice, but it is interesting, I think.

35:27 This portion of Talk Python to Me is brought to you by Brilliant.org.

35:33 Many of you have come to software development and data science through paths that did not include a full-on computer science or mathematic degree.

35:40 Yet, in our technical field, you may find you need to learn exactly these topics.

35:45 You could go back to university.

35:47 But then again, this is the 21st century and we do have the internet.

35:51 Why not take some engaging online courses to quickly get just the skills that you need?

35:55 That's where Brilliant.org comes in.

35:57 They believe that effective learning is active.

36:00 So master the concepts you need by solving fun, challenging problems yourself.

36:05 Get started today.

36:06 Just visit talkpython.fm/brilliant and sign up for free.

36:10 And don't wait either.

36:11 If you decide to upgrade to a paid account for guided courses and more practice exercises,

36:16 the first 200 people that sign up from Talk Python will get an extra 20% off an annual premium subscription.

36:22 That's talkpython.fm/brilliant.

36:27 So I guess the reason I bring that up is like Napalm having the ability to have this unified API kind of lessons that lock in just a little bit.

36:35 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.

36:41 And so it used to be that you were locked into a networking platform because that's what you built your automation around.

36:48 Or that's what you knew how to configure.

36:50 That was the tooling that you had.

36:51 So today, if you say, okay, my lock-in choice is we're going to use Napalm.

36:56 We're going to use Ansible.

36:57 We're going to use Puppet or Solved or Cisco's NSO platform.

37:01 One of these tools, that's going to be our point of interaction.

37:04 As long as you work with those, then we're happy with it.

37:08 And so that's the thing we're starting to see is organizations say, this is our tooling choice.

37:12 How do you fit into this tooling choice as it goes through?

37:16 Because they want the ability to kind of Lego block and swap in and out underneath the tooling choice because that's their entry point.

37:23 That's really interesting.

37:23 Another one that you brought out was Nornir.

37:27 I'm not sure if I'm pronouncing that right.

37:29 But that seems like a very Pythonic one.

37:31 They're like, they're deeply embracing Python as the way.

37:34 Do you want to talk about that a bit?

37:36 Yeah.

37:36 So I'm not super familiar with it.

37:38 I'm just starting to learn it myself.

37:39 And it's a new one that came through.

37:41 David from Napalm, as well as Kirk Byers, who did the NET NICO program and some other pieces,

37:46 have kind of joined forces to build up this new automation framework for Python.

37:51 And it's very much designed to be a Pythonic mechanism to go.

37:56 A lot of the stuff that it talks about is rather than working in some domain-specific language

38:01 where you're limited by what that domain-specific language is capable of, what you're able to describe.

38:07 With Nornir, the idea is we want to give people the full power of Python, right?

38:12 Let's not rewrite programming.

38:14 Let's not shackle what's possible.

38:16 Let's say, here's how we'll go through.

38:18 And Nornir is a library that goes in.

38:20 And what's been interesting is we talked a little bit about the levels of abstraction

38:23 and consumption.

38:24 As I looked at Nornir, under the hood, it's leveraging tools like Napalm to actually do

38:30 the interface configuration.

38:31 And so it seems like we're getting these kind of rushing, nesting dolls of libraries.

38:36 It's turtles all the way down.

38:38 Yeah.

38:38 You just pick up, okay, we're going to use this one.

38:41 And then when you look under the hood and you do like a pip freeze, you realize all of

38:45 the other things under the hood it's using.

38:47 And this new fancy library is actually not doing all that much on its own, not to limit

38:52 or minimize what these libraries do.

38:54 But that's the idea.

38:56 And I think one of the values that these offer is they're building on top of the foundation

39:00 that's already been laid.

39:01 And so we see that inside of all of these tools that go through.

39:05 What I think is really interesting about Nornir is the fact that they have fully embraced

39:10 Python.

39:10 Because one of the comments we see kind of over and over, and you'll see the Twitter

39:15 debates on these one, is don't use Ansible as a programming language.

39:19 And then people are like, why not?

39:20 I can program in it.

39:21 It's not a big deal.

39:22 It's like, but you can't really do it.

39:24 And then there's the debates that go back and forth.

39:26 And it seems like in the networking space, there is starting to see this push for some

39:30 of the early adopters, the folks that have kind of got tons of battle scars from trying

39:35 to do things in an interesting way, saying, you know what, we need to go back.

39:39 We need to make sure that we've got more control over what's possible.

39:42 Network engineers at our heart have always really enjoyed toying with nerd knobs, having

39:48 access to all the features, understanding what's going on.

39:51 And I think we're starting to kind of get that maturity level across areas of the industry

39:57 to say, okay, we need to really, we need to dive into this a little bit hard, have a little

40:01 bit more control, have a little bit more flexibility with what's there.

40:03 Because despite the fact that they don't want to be locked into a platform, they also want

40:08 to be able to do whatever they can with those platforms that they've chosen.

40:11 And if you're limited by what you're allowed to do inside of your infrastructure, because

40:16 some automation tool doesn't support it, well, that's now we have to extend our

40:21 automation tool and make some other choice.

40:22 Right.

40:23 They highlight a lot of interesting, what they call benefits on the Nornio project, like

40:28 a domain-specific language.

40:30 A DSL can get complex when you've got to do advanced stuff.

40:33 So avoiding the complexity of code might not be avoided anyway, right?

40:37 Code is easier to debug.

40:39 Like you can actually just set a breakpoint and debug it.

40:42 You might write code anyway.

40:44 You can leverage your IDE for linting.

40:47 And I think the final one is like a pretty interesting that they list here.

40:51 And it says a side benefit of using this is it'll also teach you Python, which you'll find

40:55 to be a lot more useful than just knowing like a DSL.

40:58 So for example, like you might learn Nornio, but now you know Python.

41:02 And if you need to get another job, it's not, well, I can program Ansible.

41:05 I can actually program full stop, right?

41:08 Exactly.

41:08 Exactly.

41:09 And that's the piece that comes through.

41:11 I'll have folks ask me, should I learn Python or should I learn Ansible to automate my network?

41:15 And my answer to most folks is you need to learn both, probably.

41:18 Ansible is a great tool.

41:20 It's super popular in the network automation space today for a variety of reasons.

41:25 And I don't see that popularity going away.

41:27 But one of the things that comes up time and time again is engineers and enterprises will

41:33 get to a point with a tool like Ansible and then figure out, okay, I can't go any farther.

41:39 And it's one of the points that you call out is they need an advanced feature or they need

41:44 some piece of logic element or they need to do something.

41:46 And they just can't do it with a tool like Ansible that's there.

41:50 And so now they're either writing their own Python code to consume it as Ansible or they

41:56 revert back and they start doing something else with a tool like Napalm or Dornier as it goes in.

42:01 And I think it's going to be this pendulum swing that goes back and forth.

42:05 As we start a little bit with Python, we get frustrated because it seems like we're doing

42:09 a lot of stuff that should be easier.

42:10 You move to a higher level tool.

42:13 You get frustrated because now you're limited with what you can do.

42:16 But now you've learned a little bit more and you go back and forth.

42:19 I think every organization and every engineer will find this sweet spot of what to consume

42:23 and what to build yourself.

42:24 Yeah.

42:24 I don't think it's only going to get better, right?

42:26 Like there's only more stuff on PyPI that you can pip install.

42:30 Absolutely.

42:32 Absolutely.

42:33 I think last time I looked, it was like 147,000, but I haven't been counting for a few weeks.

42:38 So it's probably even higher.

42:39 It's insane.

42:40 It's great.

42:40 It's getting to the point now where you've got to be careful.

42:42 The number of times the pluralization of a package has thrown me off where I swear I installed

42:47 the package I wanted and then come to find out I, instead of installing requests, I installed

42:52 request, which is a completely different library and works completely differently.

42:55 What do you mean this function's not here?

42:57 I know get is on request.

42:58 No, that's plural.

43:00 That's right.

43:00 Yeah.

43:01 Yeah.

43:01 Those come up time and time again as it goes in.

43:03 And I love the fact that anybody can build something and post it to PyPI.

43:08 That's awesome.

43:09 The barrier of entry is so low.

43:11 I think that's what's part of what makes Python kind of Python.

43:14 But there's also that piece that I have to remind folks is just because you can pip install

43:19 something doesn't mean that you should necessarily trust it with what's going to go on.

43:23 Do a little bit of research.

43:24 Go figure out what's there.

43:26 Is this a mature library?

43:27 Are there other people using it?

43:29 Is it maintained?

43:30 And that's another skill set out of programming that network engineers need to start to learn

43:35 is that it's very easy to grab something and not understand what it is.

43:40 And the skill set of not just copying and pasting from Stack Overflow is one that we have to

43:44 remind people over and over again.

43:45 Yeah.

43:46 That's a super interesting thing to evaluate an open source project, whether you want to

43:50 take it as dependency, right?

43:52 Because if you have a billion dollar company that depends upon this thing, but it's actually

43:57 some freshman students' little project that they threw up there that has four stars on

44:03 GitHub and they've since moved on to some other language and they don't even care about

44:07 it anymore.

44:08 Like that's a shaky foundation.

44:10 Exactly.

44:11 But you got to know to look, right?

44:12 Audio bloop there for a second.

44:14 The other piece that comes in that's very related to just like the reliability and the

44:18 upkeep for it is the impact of open source licensing that goes in at some of these areas.

44:23 We're starting to get more and more conversations with lawyers getting involved to say, okay,

44:28 well, what is the impact of using that open source library?

44:31 Is there something in there that says that they have a portion of our company now because

44:36 we happen to use their library to configure our network?

44:38 And those are interesting discussions that as we start to code and just use community delivered

44:44 applications that I think it's not limited just to network engineers.

44:48 But because we're new to the programmability space and we didn't cut our teeth through some

44:53 of these other areas, I've seen several folks kind of be very surprised to find out like

44:58 what the impact of some of these choices they've made has been.

45:02 Yeah, it definitely can catch you off guard.

45:03 So while we're talking about learning these new things and stuff you have to learn, maybe

45:08 it's worth highlighting this project.

45:10 I don't know.

45:10 Would you call it a proper course that you created called Learn Network Programmability Basic?

45:14 Yeah, it's a great one that goes through.

45:16 And so the Network Programmability Basics video course was designed very specifically to help

45:22 network engineers jumpstart into programmability and automation.

45:27 The question we get more often than not is how do I get started?

45:30 Because there's this overwhelming nature.

45:32 There's so many topics that are out there.

45:34 And so what I did inside the course was kind of say, okay, let's break down the basic fundamental

45:40 information that you should know.

45:41 So we talk about programming basics.

45:43 So we go through some Python fundamentals.

45:45 We go through what are APIs.

45:47 We talk about those elements.

45:48 And then we walk up the network structure tree, starting with device level APIs and then going

45:55 into like SDN controllers and network controllers.

45:59 We talk about capabilities around hosting applications at the edge, so some five computing pieces, and

46:05 then even get our way into kind of this net DevOps space where we're starting to treat the

46:09 network as code.

46:10 And we're adopting things like configuration management strategies and CICD in the network.

46:15 The Programmability Basics video course is definitely not designed to turn someone into an expert.

46:20 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, kind of in a controlled fashion.

46:34 And so that they can, they're more prepared to take that next step.

46:37 To say, okay, I've seen a little bit of Python.

46:39 I know what these APIs are.

46:41 I know what the library does.

46:42 Now I'm a little bit more comfortable to go kind of do a little bit of Googling and research to take a class on Udemy or go grab something off of another area or sign up for another piece.

46:52 And that's really the focus of the material we have there is to do that jumpstart.

46:57 I like to joke, my goal is to speed people up somewhere in the two to four months range, right?

47:03 Let's cut two months off of your journey to understanding network automation.

47:08 If I can help you do that, I've been successful inside of that course.

47:12 Yeah, that's really awesome.

47:12 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 that you're like, I know there's this thing that solves my problem.

47:26 And I know a little bit about it.

47:28 And I now know where to go to look to learn it because it's almost like this paradox of choice or like this overabundance, right?

47:35 There's not a scarcity of things you can use.

47:37 It's there's so many things I could use.

47:39 I don't even know where to start.

47:40 And so having that like first step in the right direction for all these different things is really powerful.

47:45 Exactly.

47:45 And it's so easy to be overwhelmed in any topic today.

47:49 I mean, the Internet just makes it ridiculous for how much information that goes through.

47:53 And so that's been the purpose of the video course, as well as the other resources that we put together and we kind of curate up on DevNet to say, OK, let's give you let's give a network engineer.

48:02 Let's give a collaboration engineer or a server engineer kind of a somewhat curated entry point so that we can start to define those terms and expose them to what the art of the possible.

48:12 Right.

48:13 I like to say my my job is an evangelist.

48:16 The evangelism side of my job is to kind of show people what's possible, give them a glimpse of the future and get them excited for it.

48:22 And so they're willing to invest more time and to go figure it out themselves and put the time.

48:26 Yeah, I think that really sums it up perfectly.

48:28 So I think maybe maybe we should leave it there for the networking.

48:32 But I did want to ask you a question about PyCon because you're you're in Ohio and you were just at PyCon.

48:38 It was in Cleveland this year, which is a great experience.

48:42 I feel like a lot of people don't go to PyCon because they're like, oh, that's for the hardcore developers that only like maybe speak to the people who are somewhat in your space who feel like PyCon isn't for them.

48:54 What was your experience there?

48:55 I love my experience of PyCon.

48:56 This was my first year going to PyCon.

48:58 I'm looking forward to next year and going back.

49:01 It's back in Cleveland again.

49:02 So it's going to be super easy for me to get to.

49:03 So I'll definitely be there.

49:04 The organizers were super friendly.

49:07 All of the presenters were amazing and going through.

49:10 And that's one of the things I've really loved about the Python community in general.

49:14 And it certainly showed at PyCon was the inclusive nature of where everybody's at.

49:19 It doesn't matter if you have written a library that that 150,000 people are using on a daily basis.

49:26 Or if you you've just written your first Hello World app, you will have a good time at a conference like PyCon.

49:33 And then what was interesting for me from the network programmability perspective is I was just there kind of as an audience member.

49:39 I was going through.

49:40 I was attending talks.

49:41 And then they had open spaces where people could anybody could sign up for a topic, grab a room, and then people could go talk about stuff.

49:47 And I noticed that somebody signed up a Python for network automation open space.

49:51 And I was like, wow, there's other people here doing this.

49:54 And so I went and kind of sat through it and talked with a whole bunch of other people.

49:58 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.

50:08 And these range from engineers from companies like Facebook and Netflix and Amazon, all the way down to small mom and pop shops that 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 a kind of where Python fits in.

50:24 And so I encourage everybody, if you have the opportunity to go to Python, whether it's the big global one, a regional one, or even one of the regional conferences that we just had, PyOhio here in Ohio, go become part of the community.

50:38 It's a wonderfully inclusive and welcoming community.

50:41 And you'll meet some really good people.

50:42 Yeah, that's great.

50:43 I'm glad you brought up the open spaces because from the outside, the conference probably feels a lot like, well, there's these talks and the talks are on YouTube, so I don't really need to go.

50:51 But I find the talks to be interesting and powerful, but actually, it's all the other stuff that makes it worth going.

50:56 Like, it's really amazing.

50:58 I think they called it the hallway track.

51:00 You can't do the hallway track on YouTube after the event.

51:02 You can only get that while you're there.

51:04 Not unless you get a friend to stream it live or something.

51:06 That'd be interesting.

51:08 Yeah, actually, it would, wouldn't it?

51:10 But like the open spaces are not recorded.

51:11 And you don't have to have any particular skill to run an open space.

51:16 You have to have the willingness to put it on the board and the willingness to kick off the topic.

51:21 But you don't even have to lead it.

51:22 You just have to say, I want a bunch of people who are interested in network programming to get together.

51:26 And that's it.

51:27 You could be like, I have no idea, but I wanted to talk to you all.

51:29 So here we are.

51:30 Yeah, yeah.

51:30 Yeah, that's awesome.

51:31 It's great to go through.

51:32 So it's an awesome conference.

51:34 So I encourage everybody to go.

51:35 If you're on the fence, sign up.

51:36 Yeah, I'm definitely looking forward to going.

51:38 I'll get my ticket soon as it opens up.

51:40 Exactly.

51:40 All right.

51:41 Well, I think we'll leave it there for the topics.

51:43 So now we're down to the final two questions.

51:45 If you're going to write some Python code, what editor do you use?

51:48 Yes.

51:49 So I go back and forth depending on what I'm writing.

51:51 If I'm writing Python code and it's focused on kind of a sample or demo or just kind of proof of concept,

51:57 I go pretty lightweight these days.

51:59 And I use Adam because it opens quick.

52:02 It has exactly what I'm after.

52:03 And no more, no less.

52:05 When I sit down to work on an actual Python project, there's a couple of libraries I work on.

52:10 There's a couple of programs that I go through.

52:11 I always go back to kind of the first editor that I fell in love with, which was PyCharm.

52:16 And so I always find myself back into PyCharm.

52:18 I love the integration capabilities that are there.

52:21 I love being able to work just within the interface and go through.

52:24 And so I bounce between the two of those depending on which project I'm working on at a given point in time.

52:27 Yeah, that's cool.

52:28 I do that with VS Code and the Python plugin and PyCharm, of course.

52:31 So something really, really quick.

52:33 I just want to open it up and look at it, probably throw it in VS Code.

52:36 But otherwise, PyCharm as well.

52:37 Nice.

52:38 It seems like there's a big debate in my team.

52:41 There's half of us that like Adam and the other half of us are big VS Code folks.

52:45 And for me, it's one of those like, if I've got something that works for me, I'm perfectly happy to use it.

52:50 I don't need to go explore other tools that are there.

52:52 Yeah, sure.

52:53 Well, you guys can at least now rest assured that they're owned by the same company.

52:57 That is true.

52:57 That is kind of funny.

52:58 I'll be interested to see if they end up merging as products.

53:01 I don't know if they will, but Nate Friedman, Nat Friedman, the guy who's going to be the CEO, maybe is the CEO of GitHub.

53:07 Now, I don't know when he officially starts, but he came out and said, we're not dropping Adam.

53:12 We're going to keep working on it.

53:13 People love it.

53:13 We're going to do these things at least in parallel now.

53:16 That's good.

53:16 Excellent.

53:17 Yeah, good to hear, right?

53:18 All right.

53:18 Last question.

53:19 Notable PyPI package.

53:20 I'm going to call out NC Client for me.

53:23 NC Client's the NetConf client for Python.

53:26 And I go back to it time and time again for my automation these days.

53:30 Because as much as I love the higher order packages that we talked about, like Napalm and Nornier, I'm still kind of at the tinker level.

53:37 And I like being able to get right down into it.

53:39 So that's always one that I go back to.

53:40 Okay.

53:41 That's awesome.

53:41 All right.

53:42 Well, Hank, thanks for being on the show.

53:44 It's been really great to talk to you about all the stuff.

53:46 And I think there's a lot of interesting lessons people can take away from learning how network engineers are moving into this programmability because so many different disciplines are.

53:55 Absolutely.

53:56 Absolutely.

53:57 Well, thanks for having me, Michael.

53:58 I appreciated the opportunity.

53:59 Yeah.

53:59 You bet.

53:59 Talk to you later.

54:01 This has been another episode of Talk Python to Me.

54:04 Our guest on this episode has been Hank Preston.

54:06 And it's been brought to you by Linode and Brilliant.org.

54:09 Linode is bulletproof hosting for whatever you're building with Python.

54:13 Get four months free at talkpython.fm/Linode.

54:17 That's L-I-N-O-D-E.

54:19 Brilliant.org wants to help you level up your math and science through fun, guided problem solving.

54:25 Get started for free at talkpython.fm/brilliant.

54:29 Want to level up your Python?

54:31 If you're just getting started, try my Python jumpstart by building 10 apps or our brand new 100 days of code in Python.

54:38 And if you're interested in more than one course, be sure to check out the Everything Bundle.

54:42 It's like a subscription that never expires.

54:45 Be sure to subscribe to the show.

54:46 Open your favorite podcatcher and search for Python.

54:48 We should be right at the top.

54:49 You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.

54:59 This is your host, Michael Kennedy.

55:01 Thanks so much for listening.

55:02 I really appreciate it.

55:03 Now get out there and write some Python code.

55:05 I really appreciate it.

55:26 Thank you.