Recently, Senior Editor Kelsey Ziser interviewed our Vice President of Product Marketing, Mike Haugh, for the Light Reading podcast. The discussion focused on Gluware as a thought leader in advanced network automation. Kelsey asked a range of questions related to how Gluware Intelligent Network Automation addresses critical issues for large enterprise companies struggling with network security, agility and business continuity issues.
You can listen to the podcast here or read the transcript below:
Kelsey Ziser:
Welcome to the Light Reading podcast. This is Kelsey Ziser. I’m a Senior Editor here at Light Reading and I’m joined on this podcast by Mike Haugh, who is the VP of Product Marketing at Gluware. On this show we’ll discuss the latest on intent-based networking, how enterprises can approach automating brownfield multi-vendor networks, and if there’s such a thing as too much network automation, and we’ll do that right after this break.
Kelsey Ziser:
So, Mike we’re so glad to have you on the Light Reading podcast today. And I thought before we dive into things, wanted to ask your suggestions for… I imagine that you’re in quarantine as most of us are with this Coronavirus, so do you have any suggestions on what to binge watch right now to get through it?
Mike Haugh:
Well, I’m in a unique situation with a two-year-old and a five-year-old now home from school. So, we’re binge-watching Papa Troll and Peppa Pig and Blippi, so I’m probably not the best person to ask. My wife and I are trying to watch Jack Ryan, not really kid appropriate, so I think we turn our binge-watching voice recordings off when we have dinners. We’re kind of a family-friendly crowd over here at the Haugh household.
Kelsey Ziser:
Yeah, it makes sense. Jack Ryan’s a great show. I binged the Tiger King documentary on Netflix one Friday night. That was pretty wild. So that might be one to check out but also not kid friendly. So just a caveat there. So, getting right into things, I wanted to talk to you a little bit about intent-based networking and I came across that term maybe two or three years ago. Wanted to get your thoughts on how you would define intent based networking and then if you’ve seen any major changes in the conversation around that topic over the past few years.
Mike Haugh:
Yeah, absolutely, Kelsey. It’s an exciting topic and I think everyone in networking is always excited about the next innovation. And when you look at how network automation is progressing and if you follow its industry standard terms, Gartner is one that describes some through the original configuration management products out there were referred to as
NCCM, network configuration change tools. And that approach is very text oriented. You’re kind of treating network configurations as a block of text. And unfortunately, it’s kind of an unintelligent mechanism to deal with the intelligence of the network because the network when you really look at it is made up of all these individual protocols that are individual pieces of code. So, kind of fast forwarding, the technology is like what Gluware
uses to manipulate and perform network automation. We’re really starting to treat the underlying network infrastructure as code and then interact with it programmatically. What intent-based networking is intended to do is be able to provide abstraction to define a business level or policy level desired state. And this is where it kind of gets to a very gray area of how high you abstract. The reality of most network engineers is they don’t want extremely high abstraction. They still want tight policy controls. So right now, I’d say we’re at the policy level of define what is my intended state on the network. You then take that intended state or policy and must translate it. These modern platforms, again include Gluware as an example, translate that desired state into the actual network configuration required for each device or vendor. Oftentimes you’re dealing with multi vendors, so Cisco, Juniper, Arista, and down the list, you have to translate it back to that vendor’s native CLI and semantics to be able to actually tell that device what to do. And then, you have a feedback loop to verify it in the end in the intended state.
Kelsey Ziser:
So, you were explaining, intent-based networking and the level of abstraction that you would want.
Mike Haugh:
For a couple of years, we were trying to go down a path of software defined networking or SDN, and SDN while kind of great in concept, when you really looked at it, trying to fundamentally kind of separate control plane and data plane was such a radical change. It didn’t really get off the ground like everyone maybe thought it could. But the concept of having centralized control using software concepts to control networking has really become popular. And SDN has gone off into very specific solutions like vendor specific software defined WAN and software defined data center. But what about the rest of the network? How do you apply software control? And that’s where intent based networking is the goal. The goal is to provide a software-based control even for things that don’t fall into some net new software defined data center or software defined WAN typed implementation.
Kelsey Ziser:
Okay. That makes sense. And then I know you do a lot with automation for enterprises. Why would you say that network automation is so critical at this time for both enterprises and service providers?
Mike Haugh:
must take personal time to deal with family situations. If your critical resources are human and you can’t get something delivered, that automation becomes a lot more important. I think it’s going to become a time for us where people really look at automation as a very strategic enabler to ensure the network can be managed to keep business continuity during tough times. I think we’ve always felt it’s important, we hear it’s important, but sometimes you need something to kind of cause a little pain, you feel a little pain, and then you’ve got to justify it to take the action.
Kelsey Ziser:
Yeah, very real use case for everyone right now. And that kind of makes me wonder as far as we talked about on another podcast just about some service providers have closed some of their retail shops or are doing kind of curbside assistance. Do you think that maybe some of the automation involved in customer service, not just for service providers, but for several different verticals, is that becoming more important? Cause I imagine more people are probably using call centers and chat support during this time versus maybe going in person to get tech support for their phone or other device.
Mike Haugh:
Absolutely. Prior to pandemic, we’d interact with large organizations and we look at the team to manage a large and complex network. And for us, we’re kind of talking the so-called brownfield, the existing network with a lot of complexity. I think oftentimes people think, well, I can move to something net new and my problems go away. Well, reality is a lot of the old networks never really go away. And even if you have silos of new, you still have old. We had worked with a very large organization with more than 30 people daily managing the network, making changes, and now it’s consolidated down to two or three end regions that can automate with Gluware. So, one is kind of taking the burden off the people. And now what you’re referring to also is when you think automation, it’s not just the tasks and some of the low-level things, but how do you enable self-service? And someone who’s working remote to just go on a portal and request something and have it get implemented. And that’s where it does get to automation systems need to be able to integrate. So that web front end you’re using may open a ticket in ServiceNow or Remedy and that could potentially trigger an action through an API culture automation software. So I think a lot of people in organizations are looking at, not just your task-based automation of how do I push QoS to my network or how do I update SDMP, but even more so around how do I enable self-service and things. Now what we’re talking about around today’s problem with people working remote, everyone has to kind of reconsider their capabilities for VPN access to the network and so a lot of people are talking. The pain points we’re hearing on calls daily now are around VPN concentrators and internet access and the change from maybe 20% remote and 80%, to 99% of people remote. So, this is really changing. I’d say most organizations are moving towards remote worker and enabling remote worker VPN and unified communications and cloud technologies. But it’s even more important now. And those that have leveraged clouds and things like Zoom and WebEx and other mechanisms. The nice thing is when it’s a SaaS, a software as a service, they can kind of just add incrementally as needed in the cloud that the provider can just incrementally ratchet up. But if it’s your own infrastructure, your own VPN, concentrators and your own Internet circuits, those things are being stressed and everyone’s looking at upgrading those now.
Kelsey Ziser:
Yeah, definitely. It is helpful if you already have some of those systems in place versus then. I feel bad for the companies and employees that are just starting from scratch or didn’t have some things like we use Microsoft teams a lot, so having those capabilities. We’ll take a brief break and we’ll be right back on the Light Reading podcast.
Kelsey Ziser:
All right, so we’re back on the Light Reading podcasts and I’m joined by Mike Haugh with Gluware. We’re talking a little bit about automating and brownfield environments, which is probably most networks. What would you say are some of the biggest challenges that enterprises face in automating brownfield bolt type vendor networks?
Mike Haugh:
Yeah, I think the biggest challenge you face is that when you’re looking to program or look at things programmatically and automate them, the more variables you introduce, the harder the problem becomes. And brownfield is kind of like a dirty word, but it is that installed base of your existing router switches, firewalls. It’s referred to as technical debt. And if someone has an issue within your organization, you haven’t been very good about removing old statements in old configurations. Those configurations have bloated with unnecessary access lists command lines and route filters and other things. We’re working with a global pharmaceutical and they still had statements on the routers to deal with Kazaa traffic and Kazaa is a peer-to-peer app that went away a long time ago. The brownfield problem is the mix of vendors or platforms and then it’s the complexity and even the legacy or technical debt built into each configuration. And back when I was talking about the old approach of NCCM tools, a lot of people kind of believe like, “okay, the source of truth is on the network and I’m going to just keep taking the running config because if it’s running it must be good, right?” Some people say, “oh that’s up and running, it must be at a good state and if it doesn’t work tomorrow, I’m going to just put that config back on.” And I think the key around brownfield automation and the problem Gluware helps solve is to transition from current state to deconstruct that monolithic config to make it into individual feature blocks and then manage it from a policy based and an intent-based standpoint. It’s a modernization. I used to joke around about it being like a home remodeling show. It’d be awesome if you could just tear down your house and rebuild it. But reality is that you’ve got to live in it. Gluware enables you to do things like you can automate individual things and move step wise or logically into your pain points. It may start with global like SNMP and AAA and other things, but then you can move into more complexity. So that’s the brownfield problem, which most enterprises have.
Kelsey Ziser:
Yeah, I’d love to have an immediate home remodel.
Mike Haugh:
And in the software world, you just tear down a VM and spin it back up. It’s a little easier in some worlds. In the networking world, it’s a bit more complicated.
Kelsey Ziser:
Right. And so how does an enterprise get started on this automation journey? Is it, as you mentioned, removing some of those old configurations? Is that a good place to start? How do you consult with them on where to get started in their automation journey?
Mike Haugh:
Yeah, that’s a great question. And I think it’s like you can’t boil the ocean overnight. What we often recommend is get started automating the read only components because that’s the lowest risk. It’s essentially zero risk. You’re not making new changes. With Gluware, we start with inventorying the network, so perform an inventory, understand what devices are on the network, understand what operating systems they have, understand if they’re current support contracts. We are always surprised, and the enterprises are always surprised when they go, “oh, I didn’t know we still have those in the network.” Or, “oh, I didn’t know we were running those old operating systems.” An engineering firm we work with who inventoried a thousand devices, 400 were switches, had 70 different operating systems running and they’re like, “oh wow, this is problematic. We can’t have all these different operations. We need to standardize.” So, automating the read only and then when you get beyond your inventory, we enable something called config drift, which is the monitoring of config changes. And so, this gives you a good indicator. Number one, it gives you insight, so you know what changed if there’s a problem. If someone says I can’t get to the server anymore, you can look at the network and say, “oh, someone changed the routing rule or an access list or something, you can correlate it. But it also gives you an indicator of if I know someone has keeps changing GOs policy or ACL rules, or whatever it may be, the things that are changing the most are probably what should be automated first, right? So, it gives you that indicator of that. The second piece of looking at configs is implementing auditing. So often we work with customers and they say we have standards, we have standard configs, we have paper policies. Some engineer took the time to define what should be on the network devices. An audit will enable you to compare that intended state with what is running and tell you how many violations you have. You can audit to company policy, you can audit for third parties’ standards like PCI, DSS, and HIPAA and Sox, and you can audit for security components. Organizations like NIST have very good recommendations on what should be turned on and what should be turned off and router configs and you can audit for things like that. We kind of begin and get started automating the read only and then prioritize what we need to perform in terms of operating system upgrade and then what can we automate from a config standpoint that’s should be done first. And so sometimes you jump right onto a pain point, like oh, I got to get QoS right to fix unified communication. Or you can say, I want to standardize. Maybe you have static passwords and you should be using Tack X or Radius, right? So, implementing standardization from the network configuration.
Kelsey Ziser:
Okay. Is there anything that you would recommend enterprises not automate? Is there such a thing as too much automation?
Mike Haugh:
I think where the challenge lies, and I think one of the most interesting parts of my job is really performing a deep network automation assessment to say what is being automated? What is being done manually? What tools are you currently using, what scripts are you’re relying on? What’s keeping you up at night? What are your pain points? And what we tend to find is that, it’s usually not an issue of too much automation. The problem is more about too many different ways in which automation is happening. And maybe even too many cooks in the kitchen. If you have different organizations, some using vendor tools, some using scripts, some using manual, that is kind of challenging in that you just have too many tools and too many cooks in the kitchen. And when you can really look at ways to consolidate and standardize, again, back to the house analogy, it’s just like cleaning up your house. It feels good once you get through some of that network cleanup.
Kelsey Ziser:
Do you ever have any conversations with your clients about, I imagine some employees might be concerned with, yes, this automation probably makes a lot of things simpler and faster for them, but at the same time, are there concerns about their job security, or do they generally feel like, okay, this opens me up for more time to focus on the tasks that I am really interested in or that would really help move our business forward?
Mike Haugh:
Yeah, I think you have people resistive to change and it’s a natural thing. Generally, when people come to us, they already know they need automation. The apprehension is like, what am I going to have to learn to automate? I think one thing they’re relieved to learn with Gluware is that we are not asking engineers who spent many years of the life becoming protocol experts and CLI experts. We’re not asking them to become programmers. I think that’s probably more of the fear and concern people have is like, “wow, do I need to really dramatically change my skillset to keep my job?” And with Gluware, we take virtually no code or even low code approach to leverage your current skill sets so that, that’s one fear we try to put to rest quickly. The other fear around, you’re talking about job security, that’s generally not as big of a problem as people would think. I’m going to automate myself out of a job. It’s more around giving me the ability to eliminate the mundane tasks that I didn’t enjoy about my job anyway. Let’s say an engineer enjoys building the config and getting it right the first time and working in the lab and they enjoy the building aspect and the protocol work. What they don’t generally enjoy having to manually apply it to a thousand devices at two o’clock in the morning during the maintenance window. I spent years of my life sitting on calls on weekends. It was not fun. And if you can also bring that to them to ensure that you are going to capitalize on your skillset, allow you to automate those mundane things and actually improve the satisfaction and even not burnout your valued employees. I think there’s benefits to the engineer as well as the management on that front. We generally find that there’s plenty of work to go around and that if we enable them to automate their brownfield, they can use resources towards strategic things. And what we like to point people towards is if you were freed up of all this time and effort, what could you be doing? Could you be moving to leveraging cloud resources or other things faster? And generally, they’re very much in agreement of that.
Kelsey Ziser:
Yeah, that definitely makes sense. And getting rid of some of those manual processes probably actually helps with employee retention for them to be able to work on the things that they’re more passionate about and like you said, not have to wake up at ungodly hours to work on things.
Mike Haugh:
One other piece of fear I want to touch on is that people sometimes are fearful of automation. And this is true of a lot of approaches. If you build a script, at some point you have to run that script and it’s a little bit risky when you hit that execute button because older folks who’ve had experience with automation and maybe had a script go wrong, are very gun shy. Like, “oh, I tried it and you know, caused more problems than it creates.” Our approach with Gluware is very methodical in terms of there’s a lot of pre-checks, post-checks and validations that occur, as well as previewing the change. I want to see what’s going to happen before I execute it on a live device and even automating the ability to test it in a lab or a controlled environment before I roll it out. I think the automation that people must get comfortable with is moving into it and building confidence in the platform and then the approach, and I think that’s critical. We were talking about you automate the read only first, but when you start to automate the change of the writing, where you’re actually implementing change, you’ve got to kind of ease into that as well and build confidence in your approach and the system you’re using.
Kelsey Ziser:
And I imagine as well that this process would also give them more visibility into how their network is behaving and more access to analytics. Is that right?
Mike Haugh:
Absolutely. It’s critical to be capturing that information around the network, not just config state and the device inventory. With Gluware, we’re capturing state assessment, so looking at things like BGP neighbors or route counts or LLDP. Oftentimes, you’re running manually through a show command on a CLI. Being able to automate those things and automate troubleshooting, automate the pre-checks and post checks and validation.
Kelsey Ziser:
Well, thanks so much for your time today and for joining us on the Light Reading podcasts. It’s a pleasure and I hope you stay safe and healthy and your family as well during this unusual Coronavirus quarantine situation that we’re under now. All right. That’s it. That’s our show for today. Thanks to Mike Haugh for his time and insights. Thanks also to our amazing producer, Tien Fu, for making a sound good even when we don’t. Thanks to you, our dear listener, because if you weren’t paying attention, we wouldn’t be able to get away with doing all this at work. Please tell a friend to subscribe and thanks again for listening to the Light Reading podcast. We’ll see you next time.
Light Reading is an independent B2B digital media platform providing daily news, analysis and insight for the global communications networking and services industry. It’s the leading resource for telecom, mobile and cable network operators; cloud services players; and all the companies that develop and supply them with technology, applications and professional services. Light Reading disseminates current industry information through its online publications, podcasts and vast social channels.
End