Network automation is a mess. Networks are full of dependencies, the risk of unintended consequences is high, processes are immature or non-existent, there’s a learning curve on tools, and lots of networking teams struggle to get beyond a handful of tried-and-true scripts. While cloud automation isn’t a technological utopia, it’s in a much better state than its counterpart. Can network automation catch up?
On today’s Day Two Cloud we discuss the state of network automation and whether and how it can improve. Our guests are Chris Grundemann and Scott Robohn, co-founders of the Network Automation Forum (NAF). The NAF aims to serve as a gathering place, both online and in the real world, for network engineers, developers, and vendors to advance the state of the art by sharing informaiton and best practices, developing business cases to drive automation, and researching tools and trends.
We discuss:
- A definition of network automation
- Defining boundaries with other parts of the infrastructure stack
- How network automation got into this state
- The impact of cloud and cloud networking on network automation
- How AI and ML might affect network automation
- More
Sponsor: Drata
Automate your security framework compliance with Drata. Drata streamlines your SOC 2, ISO 27001, PCI DSS, GDPR, HIPAA, CCPA, FIEC, NIST Standards, CMMC and other compliance frameworks and provides 24-hour continuous control monitoring so you focus on scaling securely. Drata integrates with your tech stack through applications such as AWS, Azure, Github, Okta and Cloudflare. Say goodbye to manual evidence collection and hello to automated compliance by visiting drata.com/partner/daytwocloud.
Show Notes:
Heavy Networking 658: Using Batfish To Model And Test Your Network – Packet Pushers
@ChrisGrundemann – Chris Grundemann on Twitter
Transcript
Transcripts are provided best effort by an automated service.
Ethan Banks (00:00:00) – Automate your security framework compliance with sponsor Drata. Drata delivers continuous compliance no matter how fast your company is growing. Find out more at drata.com/partner/daytwocloud. That’s d r a t a dot com slash partner slash day two cloud.
Ned Bellavance (00:00:19) – Welcome to day two Cloud. Today’s topic is network automation, and we have two network automation experts who have thought hard about the problem as guests. We’ve got Chris Grundemann and Scott Robohn and they are part of the Network Automation Forum. What is the Network Automation Forum, Ethan?
Ethan Banks (00:00:36) – It is a group that is trying to gather a bunch of different network operators and vendors and so on from the industry to discuss the current state of network automation here in 2023 and going forward for a few years. The network automation net is not what cloud automation and a lot of other infrastructure automation is. It’s a bit of a mess and a lot of companies are struggling to get over the hump. So the network automation was formed to try to figure out where we’re at and how to improve things. And there’s a conference that we’re going to talk about during this recording here.
Ethan Banks (00:01:08) – Auto Con zero put on by the Network Automation Forum.
Ned Bellavance (00:01:11) – Exactly. So if this episode piques your interest, definitely check out the conference and the forum. Enjoy this episode with Chris Gunderman and Scott Robin. Welcome to the show, guys. Before we talk about the topic at hand, I’d like you to introduce yourself and tell the folks a little bit about you. Scott, why don’t you get started?
Scott Robohn (00:01:32) – Hey, thank you, Ned. I’m Scott. Robin. I’ve been in the networking business for over 30 years now. Spent roughly the first 15 years with hands on implementation and kind of the last 15 years in technical sales and leading technical sales teams. And now I’ve got the privilege to do some really fun things in network automation.
Ned Bellavance (00:01:52) – Awesome. And Chris, what about you?
Chris Grundemann (00:01:55) – Yeah, So my name is Chris Gunderman. I have been working mostly in service provider environments, but lately more and more on the enterprise side as well. Well, maybe lately is the last decade. So I guess showing my age a little bit there, but definitely focus now on interconnection and automation, most specifically within networking and doing lots of fun things around those two topics.
Ned Bellavance (00:02:14) – Awesome. Well, that is what we’re here to talk about, network automation. And I think we have to start with a very fundamental question, which those are always fun because they have simple answers, right? Simple and easy answers that won’t take a whole podcast episode to fill. When you say network automation, what do you actually talking about when you say network automation? Chris?
Chris Grundemann (00:02:35) – Yeah, it’s a really good question. So I think in general I think about automation as just delegation, but you’re delegating to a piece of software or a piece of hardware or some kind of mechanistic instrument. So in network automation it covers a lot of ground and I think that’s definitely a big part of the conversation is there is this spectrum of automation of what it can mean, you know, at one point, right? I mean, if you look back over the history of my career anyway, because all advice ends up being autobiographical in some way, you know, we started with scripts, right? It was Perl scripts and expect scripts and that kind of stuff.
Chris Grundemann (00:03:08) – And and you could just, you know, instead of logging into 30 routers and changing the domain name or the pointer to the S&P server or whatever it might be, you’d write a script to do that across all 30 all at once, right? And that still goes on a lot and it’s super helpful. I think these days when I talk about network automation, I’m talking about something fairly different, which is as much as possible getting towards usually a source of truth driven, intent based network, which is kind of end to end automation where I can actually hit a button and a process kicks off and it actually validates itself along the way. Make sure that there’s no problems, you know, spits it out and then checks to make sure it actually was done in production. Right? So you’re talking about like full lifecycle automation for any specific configuration. Task automation also works for troubleshooting and all kinds of things though. So again, lots and lots of ground to cover there. It’s really any kind of software based force multiplier for network engineers, I think.
Ned Bellavance (00:04:04) – Okay. Yeah, that’s still casting a very wide net and I think a network is built up with lots of different components and different layers. So Scott, are you targeting a particular layer or portion of the network when you’re thinking about network automation?
Scott Robohn (00:04:19) – This is the obligatory seven layer model question, right? My my favorite decode is people don’t need these stupid protocols anyway. We’ll leave it as an exercise to the the listeners to decode that. But so the short answer is not really. This does tend to focus on on being a management plane interaction, right? So you either, you know per per Chris’s example, your screen scraping the CLI right. But in more modern approaches you’re using APIs to affect the config of a device, a router, a switch, a firewall, etcetera, and some management focused way. So I would say the the not direct answer to your question is it is a management plane activity, but to get full closed loop automation, you might be doing things at the Ethernet level, you might find a failing optic and even turn off the transmit power for an optic so it can across multiple layers within the devices.
Ethan Banks (00:05:22) – When you guys are talking about automation here, you are talking about primarily affecting the configuration, changing the configuration of network devices to do something. Network automation also. And I want to see if you agree or disagree with this could be more of a read only context where we’re pulling data from devices or is that not an area that you think is overly important or however you want to think about it?
Chris Grundemann (00:05:45) – It’s absolutely important. I would say it’s critical and crucial to automation. You know, I mentioned troubleshooting. That was one kind of allusion towards read-only automation that works really, really well, which is instead of tracing that Vlan through all those switches to try and figure out which one you forgot to add it to, why not have a script do that? Right? That’s a really good case for automation and I think a lot of people will jump straight to configuration based automation and kind of skip over this read only, which is obviously by the nature of being read, only much less risky as a way to kind of dip your toes into automation and kind of start playing with some of these things and these constructs.
Chris Grundemann (00:06:19) – So absolutely, reading the automation is part of this. And I would say in addition to just the active troubleshooting piece, what I see as kind of modern network automation requires a closed feedback loop, right? And so you really need some kind of observability, some kind of validation, whether you’re doing telemetry with NMI or you’re still pulling as an amp or you’re using something like Susy to look at device State over time, whatever it might look like. I think that that piece, that visibility piece, that observability piece is absolutely critical to feed back into your automation machine to ensure that things kind of maintain steady state over time. I mean, ideally we’ll get to the point where, you know, Compel has been talking about the self driving network for a long, long time. You know, in my mind I think of the Boston robotics bipedal robot that’s standing there and you give them a kick and you kind of like, you know, staggers a little bit, but stay standing. That’s how I want my network to operate.
Chris Grundemann (00:07:09) – Now, I’m not saying we’re there yet. Definitely not everywhere. Very, very few places are even close to that. But I think that’s the kind of the goal and it definitely requires Read-only observability as part of that loop.
Scott Robohn (00:07:20) – I would tack on to that too. It is a real confidence builder, you know, for organizations that are new with trying to automate their network. Doing read only lets you get comfortable with the constructs, right? Whether you’re diving into Python or using other tools to do stuff, you are keeping the human and the click okay to continue loop again, it’s it’s good. For starters, you eventually want to remove that human interaction and I know I know part of the rules for this discussion is we’re humans, not robots, but we are trying to use software robots to help run our networks, to make the networks more resilient in our lives. Better.
Ned Bellavance (00:07:55) – Yes, we are humans, Scott. Yes, we.
Scott Robohn (00:07:59) – Are, Ned.
Ned Bellavance (00:08:02) – So I want to compare and contrast network automation and where you draw the line between that and infrastructure automation.
Ned Bellavance (00:08:08) – But I got to back up a moment and say, Chris, you mentioned something called Susie Q, and I can’t tell if you were just making that up or if that’s a real thing.
Chris Grundemann (00:08:16) – No, it’s a real tool. I would say if you don’t know about it and you work in networking, definitely Google and take a look at it. Not to go too far down this rabbit hole, but I think, you know, on the observability plane of kind of looking at networks and understanding what’s going on there, there’s really, I think, two schools of thought, right? One is kind of the packet capture side, which we’ve been doing for a long time, which is like give me flow or give me all the packets and pull that all off, you know, through some kind of, you know, infrastructure to look at all the traffic that’s going on in the network and see what’s actually happening and, and get observability that way, which definitely works. The other way that I think is more proponent of is let me gather all the state of the network.
Chris Grundemann (00:08:52) – Let me look at what’s going on on each interface. Write the counters, the up down status, the OSPF statuses, you know, whatever all that stuff is. Gather all that together and see the state of the network through that lens. Ideally, maybe you use both, but I think there is two pieces there. And yeah, Susie Q basically collects and normalizes all that state information and puts it into a time series database so you can roll back the clock and see was that interface up when the customer said, you know, you had a problem, we can actually look.
Ned Bellavance (00:09:18) – Gotcha. Okay. That’s I just was like, is that a real product or is he just making that up? I can’t tell. Sometimes people pulling my leg when it comes to technology.
Chris Grundemann (00:09:28) – No, it’s an open source project. Yeah. And ish as well. It’s kind of another one in that same space of validation work. So some cool names popping up in there.
Ned Bellavance (00:09:35) – Naming is fun. So when you think about.
Scott Robohn (00:09:37) – And you can you can put some, you know, intro music, some Suzy Q If you do that with a podcast.
Ned Bellavance (00:09:44) – So I feel like we pay out the notes for that. Uh, so when you think about network automation and I think of sort of the impact of cloud and the fact that so much of what I do when it comes to automating infrastructure has to do with network or network adjacent things. Where do you draw that line between infrastructure automation and network automation?
Scott Robohn (00:10:08) – For cloud, you don’t really write. It’s all fungible resource. You know, apps, compute storage and network is there to be the mortar between the bricks, right? So that’s kind of all part of the package in a cloud deployment in the more traditional IT world, you know, those things, those domains are much more discrete managed by different people usually. And there are different physical characteristics that do make network different in the physical world versus the cloud world.
Ned Bellavance (00:10:40) – It reminds me like I’m so used to dealing with the cloud world where every object is addressable by an API.
Ned Bellavance (00:10:45) – So if I want to alter a security group in AWS, that’s just one API call away. But if I’m working in a data center, I a modern firewall would have an API that I could change a rule on pretty easily. But if I’m going old school, I might have to type something into a CLI or go into a gooey. So it’s definitely a change in tools and a change in process and. I’m trying to think of how that impacts the approach of network automation, because you are not you’re not just dealing with APIs. You have to you have to deal with what what the preexisting technology that may not have been modernized yet.
Speaker 5 (00:11:25) – Right.
Chris Grundemann (00:11:26) – That is definitely a huge challenge. I think, you know, as far as where we draw the line, I mean, Scott and I have already been talking about the fact that hopefully at some very soon point. Right. And very soon could be years. It could be decades, I don’t know. But this idea of network automation will be subsumed by just, you know, infrastructure automation.
Chris Grundemann (00:11:42) – Right? It’s all going to be kind of put together. I think you’re right. You know, the line between physical infrastructure and virtualized infrastructure, cloud infrastructure in particular is an interesting one. And the way things operate there are definitely different. I think a big part to me anyway of network automation in some ways. I don’t want to overstate this, but in some ways what we want is the network, the physical network to be operated a lot more like a cloud, right? We want this to be a little bit easier. We don’t want somebody to have to, you know, run around the data center, plugging console ports into devices to make stuff work or driving around the country. Right. If you’re talking about like a Wan network, you know, it could get really crazy. So that’s a big part of this. Right. And those lines, I think, today are drawn mostly along silos, right? Especially in traditional IT. You definitely have like your security team, your network team, a lot of cases at a big enterprise.
Chris Grundemann (00:12:32) – You may even have a network team for each business unit. And that gets really interesting because then they’re actually doing things differently between different teams in the same company. That’s that’s fairly frequently happens. And I think that’s also something that maybe another interesting topic we want to get into, which is, you know, automation works best once you’ve standardized. And usually in a lot of networks, especially if you’re going network to network, standardization is a afterthought at best, if it’s even been thought of ever at all.
Ethan Banks (00:13:00) – And afterthought at best is such a a generous way to put it because it’s usually it’s not even that. I mean, trying to build out a replicable, replicable infrastructure is something that’s like, Oh, well, that year we didn’t have any budgets, so we did the best we could. And you know, and this year, well, we were in this building with these weird constraints. And so we ended up with what we ended up with and we just kind of roll with it as opposed to someone that rolls in later and goes, every remote office shall look the same and this is how it will look.
Ethan Banks (00:13:28) – And behold, these are the rules. And then life gets so much easier trying to manage that network. But, but, but that and you know, and even beyond that, I okay, now I’m going down a rabbit hole. But this is a whole thing that I’ve been passionate about for a long time, that all these networks that as different companies we build differently could really be built modular and more or less the same because we tend to have company to company and org to org similar needs, different constraints maybe, but similar needs and couldn’t. As an industry, we rally around some predictable standards and it’s like, Oh, we need internet access at the edge for this building. It should look like this. And you pull that off of an industry standard template that looks like that, and then we all look the same. And then as an industry, it becomes easier to automate because there’s some predictability from a network business to business and org to org that also would feed into how network engineers are trained.
Ethan Banks (00:14:20) – How as an industry we teach network theory and so on, rather than the I mean, haphazard I think is the best way to to describe the networks that we see out there today. When you compare one to another, it’s.
Scott Robohn (00:14:34) – Still a relatively young industry in the big picture. Right? And so those disciplines that you’re calling out, you know, different companies have been better about standardizing configs for branches, for residential edge routers, for business services, edge routers, for core routers and so forth. But there’s still a lot of room for things to get more disciplined and more more structured right in in a given organization. Like let’s just say, you know, pick a service provider for forget the industry standards. If a service provider can figure out one way to standardize those configs for those different network devices, that’s a win, right? And some are doing some are doing a great job of it. Some are still struggling with it. Right. But if I if I think about the Apollo program. Right.
Scott Robohn (00:15:27) – And all the structure and discipline and overdoing double check, of course, human lives are at risk in the heart of a space program. It’s not necessarily the same level of risk with most networks that are built, not all, but most networks that are built. You know, there’s a proportionality there, the the rigor and the mission. So a longer conversation for another podcast, perhaps.
Ethan Banks (00:15:51) – Well, a place that longer conversations about network automation is going to be happening. It’s going to be starting at the conference that, Chris, you and Scott are well, you’re heading up and making this thing happen. The Network Automation Forum that I think is your fault as well is launching Auto Con zero in Denver in November 13th and 14th. I would appreciate it if you guys would plug that. I’m I’m going to be there. Drew from the pack operators network is going to be there as well. And tell us what the conversation is that’s going to be starting at that conference. Yeah.
Chris Grundemann (00:16:23) – Yeah. Well, we’re hoping to join an ongoing conversation for sure, but maybe put, you know, a point on the map where folks can come together and talk about it.
Chris Grundemann (00:16:31) – That’s why the name Work Automation Forum, it really is designed to be a forum, a place for folks to get together and talk about these things. A salon, if you will, kind of in the traditional, maybe Parisian sense, where we’re going to have an actual physical place at a certain time where people are going to get together and talk about these things. And I think it’s going to be a landmark event for the industry. I think it’s going to be a foundational moment for this progression of network automation, right? We’ve been talking about this for a long, long time. There’s been some progress. I recently did a survey of network operators following in the tradition of of Damian Gross, who had done a couple before that. And, you know, back of the napkin, non statistical math, something like 40% of the networks of the respondents were automated. Right? And so that’s probably self-selecting. I think people who are totally not talking about automation at all probably didn’t respond to the survey at all.
Chris Grundemann (00:17:25) – And it wasn’t 40% of the people who responded, it was 40% of the networks of the people who responded, right? So there’s little bits and patches of network automation here and there. Almost no one. I mean, I’ve been surprised. I don’t want to call anybody out by name, but I have spent the first six months of this year, you know, on the phone, mostly actually on like Zoom or Google meet or whatever. But but doing the rounds and talking to folks at some big companies that I thought would be, you know, all the way along with network automation and trying to get their lessons learned to kind of capture those and then spread those out. And what I found was almost nobody has complete end to end automation everywhere. It’s just it’s just really, really, really rare as a unicorn. And so Scott and I saw the need here. There are vendor specific conferences. There’s more just network operational focus conferences, you know, across the networks in general for different communities. But nobody was really specifically talking about network automation and a vendor neutral platform neutral tool, neutral way.
Chris Grundemann (00:18:18) – And so we said, Hey, we can do this. Let’s pull it together. And as you said, it’ll be Denver November 13th and 14th tickets are on sale now and the earlybird pricing will expire at the end of this month. We may not even make it that far. It may sell out before then. So highly recommend folks jump in there and and get a spot because I think if you’re interested in network automation at all, you’re going to want to be part of the conversation there and then take that home with you.
Ethan Banks (00:18:42) – Is selling out just one of those marketing things you say because you’re supposed to say it, or is there actually a cap on this where you could actually sell out?
Chris Grundemann (00:18:48) – We are going to cap it. Yeah. We want to make sure that this is, like I said, this forum, this salon. We want to enable the hallway track as much as the folks talking on stage. Right. I think there’s going to be a lot of folks who show up who have just as much experience and expertise as anybody we can recruit to to come talk.
Chris Grundemann (00:19:04) – And so we want to make sure that there is, you know, not too many people where it overflows and you can’t have that kind of group conversation. So we want lots of Q&A. We want lots of engagement. We’re trying to find interesting ways to do that at the event and before the event. And anyway, short answer, yes, it’s going to be capped. So we there is a definite possibility of selling out, I think a pretty strong one based on the response we’ve seen so far.
Scott Robohn (00:19:25) – Okay. And the cap will definitely be below the number of people we can squeeze in the meeting space. And that’s very intentional, right? You know, when they get too big, it’s really hard to, you know, feel like more than just one head in a huge crowd. And on the intersection with Cloud. Ned, you should come. Please come join us. Right. You know, we one of the things we’re talking about here is how do we learn from our cloud siblings? Right.
Scott Robohn (00:19:54) – And we’ve got some of that baked in to the agenda as as we’re wrapping that up and getting that out there. Now, the the 90% plus finished agenda is published on Network Automation Forum. So you can go see what we have lined up. But as a conversation there and a continuation, you know, what can we adopt from cloud infrastructure automation that makes sense and what are the lines? What doesn’t make sense for, you know, physical networks from a cloud perspective? But let’s get as much as we can and repurpose things that have been built and built well.
Ethan Banks (00:20:26) – Let’s take a quick sponsor break. Drata, d r a t a, provides compliance automation. That means if you’re working with a security framework such as SOC 2, I-SO-twenty seven zero zero one, PCI DSS, GDPR, HIPAA, CCPA, FIEC, various NIST standards, or CMMC, Drata helps. Over 3,000 companies use Drata, including Lemonade, Notion, & Fivetran. Drata collects information from your tech stack and maps it onto security frameworks using over 80 integrations including AWS, Azure, Github, Okta and Cloudflare. Drata offers automated, dynamic policy templates you implement to become compliant. Drata will continuously monitor your compliance state, so you’ll know if a system becomes non-compliant and can alert the system owner. What if you need advice? Drata has a team of former auditors who have conducted 500+ audits available for your questions, including regular meetings and pre-audit planning. Say goodbye to manual evidence collection and hello to automated compliance by visiting drata.com/partner/daytwocloud. That’s d r a t a dot com/partner/daytwocloud. Bringing automation to compliance at DrataSpeed.
Ned Bellavance (00:21:41) – How would you say that the rise of cloud has impacted network automation from a practices process or just like pragmatic standpoint?
Scott Robohn (00:21:51) – Well, it’s a whole it’s a whole new skill set. That was kind of a clean sheet of paper, Right? You know, as I think about, you know, again, we’re not sharing the video. It’s just audio. But the increasingly gray hear here, my face here. You know, I grew up in a world where there was a very large, dominant networking vendor. You know, we won’t we won’t drop any names here, but it sounds like a city in the Bay Area, at least the end of that, that that was not the case with cloud networking.
Scott Robohn (00:22:25) – Right. And it was this very software first approach. Um. All software runs on hardware, right? So don’t ever forget, you know, there are real CPUs, there are real networking ASICs, there are real SSD drives, you know, beneath all these allegedly fungible cloud resources. But the the underlay does matter and the hardware does matter. So if I were to maybe tack on to the brand new clean approach to networking by cloud provider, by the way, doesn’t do things the same way that Azure does that Oracle does. Et-cetera Yeah, but the obfuscation of the underlay from the overlay poses some interesting issues and you always have to keep in mind there’s real hardware moving these packets. It’s somewhere along the line, right?
Chris Grundemann (00:23:13) – That’s a yeah, that’s a really interesting aspect I think, which is just that nomenclature bit, right? Which is I think when I was first introduced to to cloud stuff with AWS, it took me a little while to fully realize that a VPC was just a network, right? I mean, in networking we just call it a network.
Chris Grundemann (00:23:30) – You put a firewall at the edge of it if you want to, you know, virtual private cloud sounds like sounded like something, but much more grandiose. And then to your point, Scott, Right, not only did we change the names of things in the cloud, but then each cloud created their own names for things, which makes things really interesting. And then I definitely have found this interesting when I talk to either some of the younger folks or folks who have made the jump over into kind of cloud or platform engineering or these kind of things, as you said, right? The level of abstraction is really, really interesting where when they talk about infrastructure, it is something far above what I would consider infrastructure. I have lots of scars on my fingers from rack nuts and things like that. That’s what I think of when I talk about infrastructure. And so an API being knuckles.
Scott Robohn (00:24:09) – Yeah.
Chris Grundemann (00:24:09) – Yes, exactly. But at the same time, right. Even with that confusion and obfuscation, I think it definitely has created a shining light of something to point towards, right? I think in a lot of ways what these cloud providers have done is build infrastructure and the management of infrastructure.
Chris Grundemann (00:24:24) – More importantly, the way that we probably kind of always wanted to all along, but didn’t really know it was possible. Right? Like, like, yes, I want to be able to have this, you know, full orchestration platform that kind of runs over all the infrastructure and makes it all really easy so that applications can kind of provision their own resources and users can get what they need when they need it. And, you know, all the things that happened there are really interesting and to discuss earlier point, right. We want to kind of learn from that as much as possible, I think, and use it as an example to to bring back into physical networking as much as possible. Cloud networking is also made things a lot more complicated, right? Because now instead of running, you know, a network in my office where I can, like, unplug the firewall and lock the door and everything’s secure in the closet, I now have networks that I have no control over whatsoever, sometimes very little visibility into that.
Chris Grundemann (00:25:11) – I have to run as part of my corporate network, right. Or as part of my service, wider network even. Right. And so interconnection and the connection between these networks and how do I make sure that, you know, my Salesforce connection works for my users who are on vacation in Greece while they’re, you know, accessing virtual desktops? You know, there’s a lot of really wild stuff that goes on in networking. Now, that was never a question before.
Ned Bellavance (00:25:31) – Well so that there are a whole bunch of automation tools that have specifically been built up around cloud infrastructure and the assumption of the API, Right? And there are tools that I use what sort of automation platforms and tools for those who are not deeply steeped in the networking world. What sort of automation tools and platforms are there on the networking side and how do they compare to what exists for cloud?
Scott Robohn (00:25:58) – Well. So the way I summarize this conversation, you know, back to the references of bash scripts and screen scraping Perl to Python to platforms, right? You know, Perl, Perl was the scripting language that all the cool kids were using 12 years ago.
Scott Robohn (00:26:17) – 15 years ago, Python came along and became much more usable and there was a bigger community around it. Um, platforms have existed and continue to emerge that are going to make network automation, not going to they do make network automation more accessible to those who don’t have Python and closer to coding skills. We we want to have conversations around both of those streams and the and the the cross of the tube, right? There are a lot of big networks where it’s not just going to be all Python and it may not all just be on some particular vendor platform, but your vendor platform better be able to manage and integrate the scripts that you’ve already developed. Right. That it’s it’s. I see that being a very constructively messy space for a long time. You know, customers that can do their own custom development, will customers that want to use a platform to make it easier depending on their business objectives and their their OpEx constraints, you know, they’re going to make platform decisions.
Chris Grundemann (00:27:24) – Yeah, well, it’s interesting, too.
Chris Grundemann (00:27:25) – I think one of the things that drives some of this is those relationships with those big vendors that have been dominant in the networking industry for such a long time. I think, you know, for instance, you know, you know, the vendors that were biggest earliest are some of the ones who set the standards in some of the protocols that we use today. And they also were the first ones to start looking at automation. Right. And and I think one of the ways to think about this is, you know, in addition to those Perl scripts and expect scripts and whatever else, some of the first automation was in like switch stacking, for example, where now I can manage a stack of 12 switches in the IDF as one switch. That’s a form kind of of automation, right? It’s an adaption of, of operations. Now the problem with that type of automation and those type of platforms is that you have to have the right model of switch from the same vendor with the same OS stacked up there perfectly to make it work.
Chris Grundemann (00:28:12) – And you know, we’re seeing a continuation of that in some places. Right? And this isn’t to, you know, bag on vendors. I think obviously I want to differentiate. I want to make my solution easiest to use. I don’t necessarily want to make my competitor solution as easy to use as mine and remove that differentiation. I mean, there’s some business constraints here and there moving past that, right? We’re seeing more and more vendors come out and do multi-vendor type automation practices. But but inherently you’ve kind of gone to get your vendor certification and then you buy your automation software from your vendor. And the problem is nobody actually built networks with a single vendor very, very rarely anyway. And so seeing these new platforms spring up and kind of spread across the network is really important I think as well. And right now a lot of what’s going on is gluing platforms and devices and stuff together because because of that non standardization we talked about earlier, right? The fact that every network is heterogeneous in a different way and there’s 15 ways to configure OSPF on every switch, you know, multiplied by the number of versions you have in your network, multiplied by the number of switch types you have in your network.
Chris Grundemann (00:29:13) – It’s really, really, really, really hard to just drop in a platform that says automated, right? There’s just too much differentiation there. And so we see a lot of folks coming together to like glue things together to make things work. Um, in the meantime, until we get to Ethan’s, you know, a utopia of of standardized modular networks.
Scott Robohn (00:29:31) – Right. Well, you know, the magic word that’s going to solve all the problems that Chris called out are integrations. Right. Again, one of the most abused words in our industry today, cloud and traditional networking. But it is a real thing, right? And the platform vendors that can do a good job of accommodating different network infrastructure vendors, accommodating different types of scripting and so forth, you know, accommodating different visibility vendors and so forth, they’re going to play a valuable role and they already are. I don’t want to I don’t want to make that just future tense, right? There are people doing good work on that today.
Chris Grundemann (00:30:06) – If I get enough integrations, does it create a single pane of glass?
Scott Robohn (00:30:09) – You get bonus points for two buzzword bingo phrases in the same sentence.
Scott Robohn (00:30:13) – That was really well done.
Ned Bellavance (00:30:16) – That’s quite the synergy. Chris. Yes, Blue sky. Some strategies. My hair is.
Scott Robohn (00:30:20) – Getting pointy as we as we talk.
Ned Bellavance (00:30:24) – Oh, there’s a there’s a Tolstoy quote that I was reminded of when you were describing all these different networks. He said, All family, all happy families are like each unhappy family is unhappy in its own way. And I think you could apply that to networks.
Speaker 5 (00:30:36) – Yeah, that’s very interesting.
Chris Grundemann (00:30:37) – I like that a lot, actually. Yeah. Yeah. I’m going to steal that.
Ned Bellavance (00:30:40) – Unhappy little networks.
Scott Robohn (00:30:42) – Totally raise the bar with a Tolstoy quote. Wow. I was not prepared for this, so.
Ned Bellavance (00:30:46) – Yeah, I’m pretty sure I got it from some trash podcasts, so don’t think too highly of me.
Speaker 5 (00:30:51) – It’s all right.
Ethan Banks (00:30:53) – Are there things you guys think that we shouldn’t be looking to automate or that there’s practical limits to to network automation?
Speaker 5 (00:31:00) – No.
Speaker 6 (00:31:03) – I’d like.
Chris Grundemann (00:31:03) – To find. That said.
Scott Robohn (00:31:04) – Let me clarify and I know Chris will have constructive input on this too.
Scott Robohn (00:31:09) – So you crawl, you walk and you run. Different networks are in different places. Right. And we already talked about the one strategy of read only click okay to continue, get used to it and build from there. Other other networks are are beyond that. I love the idea of a unified field theory of being able to go to my IT dashboard and say express my intent and have a system provisioned that would go and get me the right app, running in the right places on compute with the right storage, with the right network connectivity where I wouldn’t even need to think about, you know, ports and gadgets and atas interfaces. I realize that’s a lofty goal, but I think there’s room for vision to help. If you think about the seven habits, right, begin with the end in mind. You know, are we trying to just automate upgrades or are we really trying to enable self-service it, you know, or somewhere in between?
Ethan Banks (00:32:18) – Yeah. And of course you’re speaking to a lot of what what cloud is really all about that idea of just consuming it and make it just a simple service that you dial up what you want in a more general way without having to do too many specifics.
Ethan Banks (00:32:33) – And the thing just happens. And there’s been startups over the years that have tried something like this. You know, plexi is one that comes to mind when you’re trying to build a network that would be very fit for the application at hand. Oh, you got a lot of big storage flows. Okay, we’re going to carve off a section of the network for you and and so on. And they had a lot of PhDs and so on that were working on the math that would make all that happen. And they made a lot of progress. They got acquired by HP and that’s still a product that you can buy in some form or another. It’s all been rebranded. I think the word plexi is gone, but but there’s just so many challenges to making things happen that again, go back to that standardization challenge with all the vendors differentiated in how they’re doing their automation. Bringing that to bear is is going to be tough and getting all the integrations in place that would enable such a thing I think would be really tough.
Ethan Banks (00:33:24) – But going back to your original point, Scott, it sounds like you think that’s the the utopia that we can eventually get to, which is everything about the network is completely automated where we could maybe even speak at a high level as to what we want the network to do and automation delivers that result for us.
Scott Robohn (00:33:44) – Well, with new tooling like AI for natural language processing, you know, there’s another leap there that could help bridge that part of the problem. You know, you’re not wrong. This is a hard problem. Capital H, capital P, right. And it’s complicated. You don’t solve any large problem without bringing it down into smaller constituent problems. Right. So, you know, again, to my brash no to the most recent question, yeah, we’re going to have to continue to decompose, solve, solve the pieces in ways that make sense for the pieces. But if we can come up with a framework that will enable the, you know, click here to provision my infrastructure that that can give us something aspirational to shoot for.
Scott Robohn (00:34:28) – And I would say just like like you mentioned, cloud does give us that more consumable way of looking at it resources. There’s a lot that can be learned from that right now here. Here’s the problem. Right within AWS, they do it their way. Within Azure, they do it their way. They’ve all solved it within, you know, very strict organizational constructs. How can we expand that and get it to work across different organizations, even different different vendors and so forth?
Ned Bellavance (00:35:02) – It would be lovely if there was some sort of. Standard standards body that was not governing, but, you know, creating standards and concepts that all organizations and enterprises could follow when they’re trying to adopt this sort of internal or private cloud operating model. I would love to see that. And maybe that’s the sort of thing that you could discuss in the salon style environments at Autoconf zero.
Speaker 5 (00:35:32) – I think.
Chris Grundemann (00:35:32) – So. And there may be a need for something like that, you know, ongoing, right? I mean, again, right now I think Scott and I and the, you know, other couple of dozen folks who are involved in pulling off auto zero and getting Network Automation Forum off the ground are really focused on this first event in November in Denver this year.
Chris Grundemann (00:35:50) – But we are also looking at the horizon beyond that. And I think there’s potentially a place for that, right. As we talked about earlier, there’s a bunch of different layers and there’s also already standardization at a lot of these layers, right? So you’ve got the alley, which is laying out a lot of the kind of really physical stuff and the technical engineering stuff. The ITF is doing protocol level work where vendors are kind of looking to that to how to build their software and hardware and build that into routers and switches and more and more cloud functions and things like that as well. Um, the piece that’s I think always been somewhat lacking is this idea of operational standards, right? Whether it’s best current operational practices or just good practices laying this out there. In some industries there have been groups that come together and do this and some of them are doing it really, really well, especially for for very specific industries. But I think if you look at this kind of protocol stack as a layer cake, we may need some icing on top where folks who are actually running these networks and building these networks come together and talk about how we’re going to do things in a standardized way.
Chris Grundemann (00:36:45) – There’s always going to be exceptions. You know, if the network really is a differentiator for your company in some way, right? If you’re running a CDN or doing something really new. Sure. Go break the mold. You know, figure it out on your own, build networks however you want. But I think to Ethan’s earlier point, for most of us, we can probably agree on a lot of things like what interfaces are we going to use, right? Is the standard is Netcom. The standard is a standard is a source of truth a standard for automation, right. Are there ways we’re going to build these things that actually allow us to learn from each other and to move the industry forward and to make collective demands of our vendors, whatever type they might be, whether they’re consultants or hardware vendors or software vendors to say, no, no, no, no, as a, you know, huge body of network engineers and network architects, this is how we want to do things. I think there’s definitely a place for that, and that may be something that automation form can fill in on or just pointing to the other folks who are already doing it and kind of helping to bridge that gap.
Scott Robohn (00:37:40) – This is a great, really important conversation On striking the balance between the right level of standardization and the right level of autonomy of autonomy. And just to throw it out there, there’s this very fundamental construct in the Internet called the autonomous system that’s really heavily used in BGP. And it is just what it sounds like within my autonomous system. I can do things the way I want with my network according to my business needs, according to my opinions of my my chief architect and so forth. But as long as the the standardized interface between the autonomous systems works, you’re good and you’ve got Internet connectivity and that’s BGP, right? So BGP is the glue that lets company ex run what they want in there and company wide run what they want in their ass and still allow them to interconnect. I’m you know that that ability to adapt and do things differently I think has been a significant contributor to the growth and the robustness of the Internet. So we’ve got we’ve got to keep both sides of the equation in mind.
Ned Bellavance (00:38:50) – Gotcha.
Ned Bellavance (00:38:50) – So can you just remind us once more of the details regarding auto con if people are interested in attending?
Scott Robohn (00:38:58) – It’s we’ve done nothing fancy with marketing. Go to network automation forum and forget.com or die. We’re dot forum and it’s working out just fine and right on the main page Go to the upper right corner and click register. Of course, check out other pieces of the website if you want to learn more first. But if you’re ready, if we’ve convinced you, go straight to that registration box and get a spot while it’s still available.
Ned Bellavance (00:39:25) – Yeah. If nothing else, just piqued my curiosity and interest in what the Network Automation Forum’s trying to do. And I look through the the list of presenters and people who are advisors to the forum and I see a lot of familiar faces that are not necessarily networking people. And that was really it was good to see. So intentional.
Scott Robohn (00:39:43) – Very intentional.
Ned Bellavance (00:39:45) – Yeah. So I think even if you’re not a diehard networking person, there might be some real value here to attending or just checking out the forums doing.
Ned Bellavance (00:39:53) – Are either of you social? Do you have, you know, somewhere where you’re posting content or information that you’d like to share with our audience? Chris you go first.
Speaker 5 (00:40:03) – Sure.
Chris Grundemann (00:40:03) – Yeah. I am still on Twitter at Chris Graham and although my use is fading, um, LinkedIn seems to be where the action is these days for me anyway, having lots of great conversations there, both in kind of the messaging side of things as well as on on posts and stuff. So find me on LinkedIn and you can learn more at Chris Grunion as well if you’re interested.
Scott Robohn (00:40:23) – And I agree on LinkedIn 100%. You can find me on LinkedIn, go to the Network Automation Forum page. You’ll see both Chris and I and others having some really interesting dialogue there. I am still Scott Robin, one word on on X that feels weird to say on Twitter. And I’m still I’m still digging Twitter. I don’t I don’t have any issues with it. You’ve got to curate your feed and that’s that’s pretty helpful.
Speaker 5 (00:40:50) – Yeah.
Speaker 5 (00:40:51) – All right.
Ned Bellavance (00:40:52) – Well, we include links to all that information in the show notes. As always, Chris and Scott, thank you so much for being guest today on day two. Cloud and hey listener out there high fives virtual high fives to you for tuning in. If you have suggestions for future shows, we’d really like to hear about them. You can hit either of us up on Twitter or on LinkedIn. You can find the links in our bios and the main page Day two cloud and there is a form on that website as well. You can just put a suggestion there or a helpful comments. We welcome those as well. And hey, vendors out there, if you’ve got a way cool cloud product that you want to share with our audience of IT professionals, you could become a day two cloud sponsor. You’ll reach several thousand listeners, all of whom have problems to solve. Maybe your product fixes their problem, but we’ll never know unless you tell them about your amazing solution. You can find out more at Packet Pushers net Slash sponsorship.
Ned Bellavance (00:41:50) – Until then, just remember cloud is what happens while it is making other plans.
Podcast: Play in new window | Download
