Zero to Hero: A University’s Network Automation Journey, Part 1

Network Automation Nerds podcast. Welcome to Network Automation Nerds podcast, a podcast about network automation, network engineering, Python, and other technology topics. I'm your host, Eric Chou. Today on the show, we'll be talking to Anthony and Christian about going from completely manual network operation to robust, usable, and practical network automation in two years. Why is this relevant to you? Because they have relatively simple formula. that could be reused by other organizations, large and small. I am super excited to be talking to both of these gentlemen. So let's get to it. Hello, guys. Hey, so this is a bit of a interesting episode for me because usually when I have guests on I've always communicated with them before and we've maybe worked together in some kind of capacity but this time this is like the first time I met you guys virtually so it's very cool because it just shows like maybe the show is being mature a little bit. Yeah, I'm very Yeah, so how about this? Let's do a bit of an introduction because, you know, I mean, I've conversed with you for guys a little bit, but, you know, I would like to hear about about you guys. So why don't we start with you, Christian? Can you tell us a little bit about yourself?

Yeah, sure. My name is Christian Bray. I'm 25 years old and I'm currently an automation engineer. I graduated with a bachelor's in computer science where I was mostly doing like software engineering, focus on like application development and that kind of thing. So I kind of expected, you know, after I graduate that I would go in that direction, maybe work on an application team or something like that. But I got referred to a network admin position. And it was an interesting opportunity for me. You know, I hadn't really thought a lot about networking at that time. I'd taken like one intro class, did a little bit of TCP/IP stuff, but mostly was focused on the software engineering things. But I took the network admin opportunity and it was… I was excited, it was an interesting challenge and an opportunity to bring some of the programming skills and knowledge to that position. And then that's where I met Anthony and we kind of got started on this automation journey.

Nice, nice. To be 25, young, and good looking, and smart. That's like a thought to me. It's a distant memory to me. So that's super cool. I like the fact that you're bringing computer science into network engineering. I think I see a mixture of two, but it's kind of like a two to one ratio. Most of the time, it's like network engineering to computer science. But it's that way out. It's always cool. So what about you, Anthony?

So out of school, I actually went into the music industry. Oh, that's the first for me, though. Yeah, it was a lot of fun. I was the bass player for a prominent. Southern Rock Blues Jazz Fusion Band out here in the Southeast. Oh, nice. I did that for a few years and then I met a girl and decided to change careers. That sounds straight from the movie. I met a girl. Oh, it starts with a girl. It happens, you know. I had this interesting opportunity kind of fall into my lap working for an ISP. And I was way under qualified. but they desperately needed people. So, you know, that happens sometimes as well. They needed a warm body and I was, I demonstrated some ability and willingness to learn in the interview and they're like, all right, we'll give them a chance. We need people. And there. I actually developed a love for the field. Like, I think there's something special about getting… packets from point A to point B, right? It's, I don't know, I really enjoy it. So I took the job seriously, learned what I could, I earned a CCNA there. I also had an interesting brush with automation. There was a members who developed really good internal automation tooling. There's an abstraction there between users and devices. So we use this automation to provision services. And it worked so well that when it was unavailable, people, there are people who couldn't. do their jobs.

Wait, wait, wait. OK. So like there are, you know, let's say there's 20 different systems, right? And they all have different interfaces and different procedures to do moves, adds, changes and deletes, for example. Yeah. And this automation tool would sort of streamline that for you as the user.

And so people would really struggle if the tool wasn't available to them. They would know how to log into this thing and they wouldn't know where to click in the value center. So at some point, to implement today– a mandatory quiz or like a test to qualify you as you know. I understand how to do the job, I understand what's happening behind the scenes. what this automation tooling is actually doing. And if you pass the test or the quiz or whatever, then you can use the tool.

So what you meant was they were so used to the abstraction layer, like the clicks and soft buttons that they lose the fact that there's things happening on the back end, which is OK if you're outsourcing your network to the cloud or to the VAR, but not when you're responsible for it.

Exactly. So I thought that was interesting. That's stuck with me for a while because I think that's an issue that– that tends to persist in some organizations, organizations with really… well-constructed automation tooling. What happens when it goes down? So that was interesting. Since then I moved on to, I've worked for a couple higher ed institutions. And I've worked for a utility that was also sort of an ISP out here in Georgia. Currently at Northeastern University where I'm doing network engineering and automation with Christian.

Yeah, so I think Anthony, you touched a little bit on your origin story as well in that intro. What about you, Christian? Have you always been interested in CS and then you just naturally let you into the major at the college? –

Yeah, I think so. I remember my high school actually, I think I was in maybe 10th or 11th grade where they offered a like AP computer science class where you could get a college credit and took their class and the teacher was excellent. And I learned a lot. And I think from that moment on, that was when I decided that I wanted to do CS in college and that set me on this path.

That's really awesome. I think that's, I mean, being a father of two and my, my older one just entered into the, the teenage years. So I got, I really think about exposure a lot and it seems like. Just having such a have and have not, it's like a digital divide right there. Like whether you have the exposure, then it would just kind of jumpstart you. So it's really cool to hear, you know, you kind of have that exposure and then know that's what you want and then kind of pursue that path. Whether that's it or not, whether computer science is your jam or not, you know, having exposure is like step one. So it's really interesting how the education and opportunity

Yeah, definitely. I'm really grateful that that my school was able to offer that for me.

Yeah, yeah. So, um… So you guys, so Anthony, you mentioned a little bit about like the kind of environment you operate in. So in the higher ed. environment, what are some of the unique challenges? Can you trust every switch that user plug in? That's kind of rhetorical, but I'll let you answer that.

Yeah, that's a lot of fun. We get servers under desks unexpectedly. We get switches. I mean, yeah, that's a very common occurrence. So obviously you have some familiarity there. I don't know. So I've been, I worked for two higher wildly different environments. So one thing is geographical distribution. Where we currently are, it's we're working with globally, a globally distributed university, right? So we have graduate campuses all over the States, across the pond. and That's a pretty interesting challenge, network engineering wise. How do we build a topology? How do we connect sides together? Where do we offer services from? I'd say that's a unique challenge for this, you know, northeastern where we currently are. Right. The other area didn't really have that same problem. It was all sort of in the same place. So that element was removed. So it was actually interesting coming from, it was an interesting contrast coming from a small geographical footprint. with a really stable, well-maintained network to where we are now, where things are kind of. It's a little bit all over the place, it's a little bit Yeah. But in our case, geographical distribution is… It's a pretty tough challenge. Yeah. What do you think, Christian?

What are some of the unique challenges facing the, maybe the higher ed in general and your particular university in that environment?

Oh, I think Christian froze. Sorry, Eric.

Yeah, no worries. Yeah, I'll have to work with the air. Can you

Yeah, I can hear you now. No worries. So I think the question we're talking about is some kind of unique challenges within the higher ed environment. And Anthony mentioned, you know, geographic location for your particular university is one. And I'm just wondering if you have any additional thoughts on that.

Yeah, it is interesting. Maybe not so much as on the geographic location thing, but for a while I was a network engineer at a hospital and that was an interesting experience in a very different environment from the university because everything's very secure and we wouldn't expect users to go around like plugging things into random ports. We have lots of protections in place, lots of like more security measures, whereas at the university things are kind of more open. And there are more things that can happen in that environment. So yeah, it's very different from other environments in that way.

Yeah, yeah. I mean, less regulation in the healthcare right now. I'm just kidding. More compliance and for sure. Yeah.

It's interesting that you bring that up because again, the two parts I worked for another interest in contrast was one sort of had an opt in security model. So you could choose to have your traffic firewalled by utilizing a central firewalling service, or you could choose not to. And maybe you can implement your own security or no security at all. And what we currently are, it is, that's not an option. Like we are. so secure that a lot of times, you know, you can't just plug in your machine and get network service. Yeah. Right. You have to go through this bureaucratic process to gain that connectivity or connectivity to a resource. Right. Yeah. So that's an interesting one.

Yeah, I think that's kind of a general kind of mindset change also, right? Like we used to have this thing where. We aggregate everything into the corporate, you know, behind the corporate firewall where it's trusted. And then so it actually spent a lot of resources, you know, firewall and NAT being a bottleneck. But now it's all very distributed. You bring your own device and you have some kind of SaaS model where you subscribe all, you know, every single service that you operate on. And now it's like zero trust. And I don't know if that correlates to your experience as well, Anthony.

I know there are a lot of talk. There's a lot of talk about zero trust where we currently are and yeah I don't know, the biggest obstacle to overcome is we don't want people to be in a broken state when they first come online, right? That's something we're still working through. Like do we do like MACsec or do we do like self service where you put in your MAC address, you say, all right, what resources do I need access to? And then our orchestration system provisions the correct access. Yeah. So it's something we're still working through

Yeah, I think state is really the thing because state is just ephemeral, right? It's always, yeah, I mean, that's why restarting your computer works because it resets everything back into a clean state. But you can't do that when you're managing the network. The state is always changing by nature and by definition. So state, when it gets out of whack, that's really, or keeping a clean state, that's a big task. What are your thoughts on that question? Any kind of security insights there?

Yeah, not something I've really thought a lot about, to be honest. That's an interesting analogy, though, on state. It's a different problem in the networking space that you have to keep in mind is that things have to be up and highly available. We can't just reset things to kind of get a clean slate to work with.

Right. Or it has a larger impact, I think. Just because you're cached, it's not just easy to replenish your cache. It's relearning stuff. and push it down just because we use so much FPGA so it pushes down to the hardware and then you have to do that reprogramming. Anyhow, yeah, so that's very interesting on you guys's background. I'm keen to hear more, but let's get to today's interesting topic of the day, which is network automation, which, you know, I think that's what people come to this podcast for as well. So. You know, I mentioned in the intro that you guys went from zero to hero in the relatively short amount of time. Can you give us a kind of a high level overview of that process, Anthony? Sure.

So when we set out, you know our objective wasn't to necessarily build this toolbox of a collection of power tools, right? Like one of the scripts. this one upgrades devices and then this one configures devices and you know you've got to run the script you got to fill in this data and so on so yeah when it's something that was far more structural and suitable for an operations team, not experienced with running scripts or writing code or filling out structured data in text files. So that was sort of our– our high-level objective. The way it all began is we had really excellent leadership, our director. saw the business value in automation and orchestration, enough so that he opened a new position on the team for a dedicated automation engineer. And that was Christian. And then I was tasked with leading the effort. For a little while, it felt like the blind leading the blind, just because I am not a coder. I don't have programming experience at this point in my career. So Christian comes on and like, all right, let's look at. Let's look at the tools that are available. Right. Yeah. So obviously Ansible is like the de facto standard for a lot of things. They both have rich ecosystems. And I think it was really interesting, kind of the analysis we did between them. We ended up landing on Python, but Christian mostly drove that decision after doing some research. So it was the trade-offs where, you know, ultimately we valued the flexibility and speed of Python. Right, we didn't really love working with Ansible's domain specific language. We just wanted to, you know, let's remove that abstraction layer and go all the way down to Python. and just code things exactly the way we want them to be coded.

Got it. Got it. So you started with the exploratory phase and then you kind of evaluate what's out there and kind of went from there. What about you, Christian? Do you have anything to add on that on that phase or kind of a high level overview?

Yeah, definitely. Just a touch on one thing that Anthony said, he talked about, you know, kind of the blind leading the blind sort of scenario. He's too humble, I'm sure. No, but it was actually great because I was coming in at first with very little networking knowledge, which Anthony had a lot of. Yeah. And I was also bringing in the programming skills and the computer science background, which was something that he was wanting to learn. So it was kind of we both had different skills that we brought to the table and we met in the middle and we're able to kind of marry these things together to to explore these automation solutions.

I'm kind of curious about the communication process. So obviously, you guys both have these domain knowledges that are complementary of each other in this particular project. But how do you guys come to that middle ground? Was it– Anthony starts to learn about coding and Christian learns about networking and then there's this language called Python where both meets are like, how did that work?

That's an interesting question. Early on, I remember the procedure being like… Yeah. All right, so here's a given process in the network. Yeah, it's something that users do. It's a specific workflow. They go from point A to point B. So it's repeatable. It's a consistent thing and people spend a lot of time doing it. So what machinery can we build there that automates that process or streamlines that process for the user? And so I'd talk through the problem and then Christian would like to take in to understand the requirements. And then… Come up with the solution.

Yeah, and I think that Anthony's gotten pretty good with Python now. He's a competent coder. But early on when he wasn't writing much code, what I would generally do is I could take some code that I had wrote or something that I was planning on writing, and I could just express the logic to him in language, or we could whiteboard out maybe pseudo code, kind of what the logic in the process looks like, and he could give feedback on that general– workflow on the general process.

Yeah, I like that very much because this is a relevant question, right? Like you often, when you start automation processing, this is what you end, what you start with. You have people who have domain knowledge in networking, and then you maybe bring somebody outside or somebody in house with coding knowledge. So how do you, how do you get that cross point? And I like the fact that you guys start with users. Right? Like this is an existing process so that this is familiar to everybody and that's our common ground. And from there, that's expand out and then see where the gaps are that we could fill in. I feel like people tune in. Like if they forget everything else, just like remember this part, right? How do they get communicated? How do they get started? And then where's that middle ground to? stand on and expand out.

I would say we're very fortunate to have had leadership who really believed in the value of automation and orchestration. That really kickstarted the whole thing. If it was just me solo, I was really, there were maybe a couple other people who were interested, but didn't really have the skills, like ready to go, let's start automating things, right? The learning curve. you know, it was pretty steep for a while for me. So Christian being there kick-started the whole thing and got us off the ground. fairly quickly.

I think that's a valid and very important point that people may have. overlooked just because they focus so much on the hard skill. Like you got to go learn coding or whatnot, but leadership and culture, right? Do you have any insights? Obviously you can't speak for your leadership, but do you have any insight how they arrived on that? Was it just something that they had confidence in that they heard about or I mean, Rome wasn't built in one day. So how did they come to that? So much confidence that they would allocate budget and human resources to that.

So my best guess is… is that you're right at the decision considering as a result of the environment we're operating in. is a pretty big campus, like 200 or so individual buildings, right? A lot of network infrastructure and a lot of moves, adds, changes and deletes daily. And the way that… you know, the traditional way of hand tackling that issue was. Just hire more people. Let's get really big teams. And as you guys, you know, logging into switches, making changes and logging out like several times a day, all day long. Yeah. and you know, when you come from, when you work in a traditional environment like that, you can ask. And this doesn't sound awesome, but you can you can ask eight different people to generate a config for a new switch. Yeah, right. And there's a solid change. You might end up with eight unique configurations. Right. One guy logged into an existing switch and pulled it down and changed the variables. One guy dug out a. a template text file deep from… his personal archive and updated that one, right? Yeah. So they can all be unique. So. Increase consistency, reduce toil, streamline processes. get done work quicker, right? Increase agility. And we were in the midst of a network refresh, right? So on top of the MACDs, we also had to replace devices, right? So we changed this router to this router, and we're changing vendor syntax, right? So things can get lost in translation there as well. So I think those were all– That's my best guess as to why he was, as to the value he saw in automation and orchestration.

Right. Right. What about you? Question. What do you think that well, you know, maybe even if it's not your current leadership, like where do you think that if you were in the position of an engineer trying to convince the leadership about like the benefits, right? Like what would you do? –

Yeah, well I think Anthony kind of hit the nail on the head with seeing inconsistencies and you have eight engineers who have eight different ways to configure a thing and that sort of stuff. But sometimes, maybe if you don't have the proper skills or tooling available, you might not even know that those things are happening, right? You might not be able to report on things like configuration drift. or those kind of inconsistencies. So it might not even be a problem that you know about until something breaks. So it's something that it's worth putting the time in to think about and try to report on those things, get an idea of what does your environment really look like before it becomes a serious problem.

Right. Right. So it's like, hey, I know we always get Bob to do it, but Bob doesn't scale. Bob doesn't… You know, Bob doesn't work on I don't know, every day of the of the year, he has to sleep, he has to eat. So perhaps we should kind of explore the the in the, you know, alternative universe where Bob doesn't exist. What we do, right? How can we how can we scale this out? I like the fact that you guys focus on data and that you guys have focus on the issue. at hand and also you're right. If you don't have the knowledge of what's available out there, then you can make an accurate decision on how much resources you spend on. So Let's just say you guys went through the exploratory phase. You had the traditional one. You evaluated Ansible versus Python. You guys were great tag team that– you know, obstacle that answer and they say, okay, let's, let's decide on, on Python or Ansible. So what's next? Like what's after that? One wish I would do Anthony.

So we basically, so really early on we put a high value on operational usability. So we discovered Jinja, the Python templating engine. We discover Netmiko and Napalm and all those things. And we see the value of structured data, right, YAML and JSON. So we landed on Jinja and YAML and we start rendering whole configs. Okay, structurally. So we're like, okay, this is what we should work towards. Let's operationalize configuration generation. Like that's of course a small subset of, you know, a broader automation orchestration ecosystem, but. you get a lot of value for the effort if you focus on configuration early. So the first thing we did was build a small web portal. Nice. Right. We're on one side of the portal, one side of the interfaces, you know, put your YAML here and then put your Jinja on the other side. And there's a render button at the bottom. Right. Yeah. So one, we just abstracted the Python away. And that was really the seed that eventually blossomed into like a full featured automating orchestration system. But I'll let Christian go into the details on that and kind of where we went from there. –

Yeah, well just on the on the templating tool that Anthony talked about, there is sort of, I think it's published by Network to Code. There's a publicly available tool that can do, you know, rendering Jinja and YAML and JSON together. Maybe we can put the link in the show notes. Yeah, absolutely. But the thing that was nice about the one that we have locally is it allowed us to save the configuration files and the data locally on the server where the application lived. So I can go back and look at the data for a config that was deployed last week, for example, or I can load our configuration up and make updates to it and then save it so that everyone who goes and generates configs after that now has the new updated version of our standard configuration template. One of the things that we thought about pretty early after we had this tool up is that… maybe it'd be difficult to get everyone working in Jinja and YAML. And then we make this a little bit more usable for day-to-day operations. So the next thing we did is we built a Flask application. to sort of front end the Jinja templates for mainly for the routers that we were gonna be replacing over this network refresh project, right? So we had nearly 200 buildings we need to replace. We're putting in some Arista routers. We have Jinja templates for those and we built a Flask front end with a nice clean form where you can enter all the data into text boxes and their select fields to select your VLANs and input your interface data. and then you can press a button to get your config.

Oh, very nice. Very nice. So if I just paraphrase what you were talking about, so you guys have like kind of a manual script tool that you take from existing repository network to code and so on. You've proven the usefulness of it by just having it maybe like a CLI format. And then then you start gradually chipping away all the other rough edges. The first one would be like the interface that people interact with it. so you have a Flask frontend to it. So a question that people often come up with when we talk about frontends is how much effort do you put into it? Because you could get into this real big thing where you have a database on the back end, you abstract that with some kind of SQL commands or SQL packages, and then you have web servers and nginx and all that stuff. How much effort did you guys put into that front end before releasing it to the wild, I think?

I would say it wasn't a ton of effort. We wanted something that was functional, but it wasn't necessarily like stylish, right? It didn't look sure it wasn't the most beautiful web page, but we wanted something that was functional and easy to use, so it was just some basic HTML front end. Maybe a little bit of JavaScript in there for some dynamic forms, but. pretty by the books and relatively simple.

I see, I see. So you… Yeah, so you but like on the web server part, is it a dedicated server and then you have the price? This wasn't like a development Flask server, right?

Correct. We were using like NGINX and WSGI to forward request to the Flask server. I see. But it was still a single process. It wasn't like a fleet of web servers and it wasn't JavaScript out where you had no offense to JavaScript people. But yeah, I've been through that situation where I just like framework after framework after framework. And it's like, oh, wow, it's Tuesday. There's another framework that came out. Yeah, that's for about Go ahead. Sorry. No, I was going to say that's correct. It was it was pretty lightweight. And, you know, we only were going to have maybe 20 people using it at most really at a time. Maybe one or two people would be using it. So it didn't need to be anything heavy duty and just needed to be functional.

Right. Right. What about you, Anthony? What are you? So we're past the exploratory phase. And you mentioned you do the automatic. automatic config generation. Anything to add to that?

So on your last point, that's really an interesting question as far as like, you know, the infrastructure of it all. One of the lessons learned, I think, was a good framework. should be maintainable over the long term. Right. And the more specialized or customized a given thing is, the more, you know, people you have to dedicate with the correct skills to maintain that thing. Yeah. It was great. And it was a pretty thin abstraction layer. And it had hooks into all these different systems and it was, and it worked really well. But one of the lessons learned was let's make it more maintainable. Let's look for out of the box frameworks. things that a lot of people are using and that have a community around it to help with supporting it. It is So that was one of one of my lessons learned. Right. Like it might have been good to have a database there and to store that data every time we would pull in structured data from a device. Yeah. Right? The user does a little bit of auditing and then they click a button or two and we ship it off into the new syntax into the new system and eventually the device is provisioned. And it was just like. seeing that data come and then watching it go was like, oh, no, we should have like, we should be keeping that data somewhere. We should store it. And then that can be the source of truth for configurations. for day two operations, right? Yeah. 'Cause we took it, translated it into new syntax, and then for day two, we go back into our traditional way of configuring things.

Yeah, I was thinking that was kind of your design choices to begin with. You wanted to be a thin layer. You wanted to not have any database to just kind of eliminate that factor. But you're right. I think all the points you made were very valid. Were you going to ask something, Christian?

Yeah, I was just going to say that Anthony's right. That was one of the limitations, the lack of single source of truth and structured data storage for our configs. We were able to take this tool pretty far. I mean, we were using like Netmiko and TextFSM to pull data from the old routers and populate the form so it could be rendered into a config for a new router. We were integrating with our IPAM system with a rest API to pull like next available IP or when it was pre-provisioned for device. We're hooking into the Arista management platform to onboard the devices. So we were able to take it pretty far, but at a certain point we started to hit up against those limitations of lack of structured data, lack of single source of truth, and the platform was kind of starting to outgrow itself.

Yeah, I think that's an interesting point because you you were able to do some of that because all the other tool sets already have some sort of capabilities within them. Like for example, you mentioned IPAM and API. Imagine if that wasn't the case, then it's a spreadsheet, which is– let's face it, that's a lot of people, a lot of environment out there that still uses a spreadsheet. Then you have to interact with a spreadsheet as opposed to API, which is fine. But I want to just, you know, before we leave the subject of like this current day one and first tool, config generation, I want to hear about like the. the interaction between hardware capability and your tool, right? Because it goes hand in hand. What are some of the hardware capabilities that you have at the time that allows you to launch this tool? You mentioned Arista, so maybe we could start there.

That's interesting. So the method we used– We didn't really run into too many hardware. you know, like lack of features in the hardware we were using. Yeah. We were coming from Brocade into Arista, right? And all we were seeing. Okay. Yeah. So all we were doing is we were pulling that data in. TextFSM parsing the data, getting the structured data and then. rendering it through Arista Jinja templates, shipping it off and configuring the new switch. So that we, there wasn't really anything exotic in there. But maybe the most exotic thing was the integration with CloudVision that was Arista's proprietary device management tool. Sure. We took it to– we'd API call into Arista, or into CloudVision, tell CloudVision how a device should be configured. And then CloudVision would do a config replace on the box. I see. I see. Okay, and so… We're actually running into more limitations with our current solution, but we can talk about that when we get into the next iteration of this thing we're currently talking about.

Got it. Well, I'm also interested in what you have to say, Christian, because that is one of the things when I interact with developers, like developer mindsets in this sort of project, because they always find it so annoying that the box doesn't have APIs. What do you mean I have to use a Pexpect process?

Yeah, I would say that one of the biggest lifts in this in this application that we built was actually taking the old Brocade routers we had and pulling configs from them and getting them into a nice structured data that we could then put in the webpage and render into our new configs. Because these boxes were old, they didn't support NETCONF or they didn't have RESTCONF or even something like Juniper's pipe display JSON is really convenient to be able to get structured data back from your routers and switches. So I would say, Looking forward, if you have the choice available and you can pick a box that has support for those features, for getting structured data back in some way, that's definitely preferable.

Yeah, tell your manager, like it's worth that 10% markup. Whatever it is, you know, don't, you know, no offense to Netgear, but like, you know, whatever. But yeah, get some, at least plan ahead so you have that capability in the future and save yourself hours and hours of work. That's the actual dollar save, right? Like you could have, use that time to do something else. All right, cool. So I think that's a great place to wrap up, you know, kind of the part one of that interview. I want to thank you both for being on part one, but we know we'll continue on to part two. So, you know, next week cover kind of your, your origin story, your introduction. We've gone through the first project that you've just done for automation and we'll continue next week for. other parts, other interesting parts.

Awesome. Thanks, Eric. Thank you.

Thanks for listening to the Network Automation Nerds podcast today. Find us on Apple Podcasts, Google Podcasts, Spotify, and all the other podcast platforms. Until next time, bye bye.