Hello, and welcome to another episode of the community fabric podcast, where we bring the networking community to the table to talk about things that matter to them most in their day to day. I'm Darren Forewell, your host for today's conversation, and I wanted to introduce a fellow networking veteran. I'm sure he won't mind me calling him that, and a real thought leader in the space advising CXOs and network engineers alike. And he's taught here to talk about his thoughts on the realities of network operations. Now, Stephen, we've been kicking around in this networking space for a few years.

Do you wanna give us, and the people who are listening, a sense of your background? Yeah. Sure. And, yeah, thanks for the invite, John. So Stephen Hampton, I've been in the networking space for about 20 years, as a network architect.

I spent a lot of time early in that sort of certifying CCIE for about 15 years now. But I've made my way around, various different industries, including sort of, finance, insurance, higher education, retail, etcetera. So I've done the whole lot. Spent some time as a CTO with a reseller, and, now have, worked with a, network professional services business where we focus on design implementation support and see all sorts of problems, and challenges from our customers. I was just gonna say, so so you're working obviously with people, every day looking at their their operations, their you know, what it is that's important to them in the working space.

So what are the the the biggest kind of challenges that you're seeing people come to you with at the moment? So I guess there's a number and and, you know, we'll do everything from consultancy down to some coalface implementation. Mhmm. For the, for the coalface implementation, it's really dealing with organic growth of their networks over the years. So, in a lot of cases, we've got legacy designs, end of life kit, and a willingness to move to, something a little bit more modern such as SDN.

At the other end of the scale, you've got sort of organizations who are looking to transform. In a lot of cases, it's navigating their way through a lot of vendor speed to try and identify, what is the actual thing they want to achieve and and and the the right tool to do that. There's a couple of other, maybe more unique things as well. So, obviously, it's a it's an ever changing market from a security point of view. There's an ever changing threat landscape.

One of the big changes that we are kinda seeing as well is, many organizations when I started working in wide area networks, it would be about, connecting together their offices, you know, for file shares and sort of local exchange. These days, most of their applications are either SaaS or Internet or in the cloud or in their data center. So the the wide area network isn't really a wide area network anymore. It's just the, it's just the most elegant way of of trying to connect your resources in in in the cloud, be it private or public. I was gonna say wherever wherever they are, I guess.

Yeah. And so and so we're just just breaking that one down a little bit more, actually. I mean, always interesting because obviously, yeah, it's similarly that whole thing when when, I was working in as a network engineer, it was all about getting to an MPLS network together, being able to connect to that and connect all my sites to it and do all the all the stuff. I guess we need a bit more flexibility now. Right?

It's more of a kind of a hybrid model, I suppose, as to how we reach the resources we're looking for. What do you see in there? Yeah. Well, I I think there's, there there's a couple of things. Just just you mentioned MPLS, and, you know, it's a technology that I've I've done a lot of, a lot of work with.

But, again, at the time, you know, there was a need for, private reliable and secure links, and reliability of the Internet has increased dramatically since then. So we're seeing a lot of organizations, not necessarily SDN sorry, SD WAN. I think a lot of people saw initially as being a an MPLS killer. I'm not quite sure it's it's it's really like that, But what there definitely is is, is is a keenness to just rely on Internet, because you can obviously buy greater bandwidth, for, for for equivalent cost and then maybe run, Internet over top of that. And a lot of that's about some simplicity as well because, you know, as organizations sort of move offices or, sort of downsize sort of post COVID, then Internet is more, is is a little bit more flexible.

And and and actually and like I said, there's there's less devices or less services run on-site. And we're even sort of speaking to a number of different customers who are considering turning their their office space or their enterprise campus into just purely, Wi Fi hubs. So they have, zero trust network access tools, that give the same user experience, for, for individuals who are working, at home remotely or in the office. So rather than provide that local LAN, you just go in, you connect to Wi Fi, and you take Internet. So so there's no campus effectively anymore.

It's just a question of giving people effectively remote access from a location that just happens to be the office as well. Right? Exactly. Yeah. And and we to to be honest, you know, this is a a sample set of of of customers that we see.

There's still kind of many cases where, where where where that's not applicable or possibly possible, particularly when you when you get into your industry and manufacturing and utilities and transport and things like that. You still need that physical connectivity. But, you know, I've spoken to organizations who are, one organization who's divesting from a parent company and want to do everything from scratch, everything was in the cloud. Right. You know?

So the need for anything like MPLS is, it it it was just purely into that set to an angle from there. Sure. I I I guess this is a brownfield brownfield greenfield argument to a point as well here, isn't it? I mean, we've put together enough environments over the years to have built up a level of, I don't know, technical debt, I suppose, in and and what you're you're talking about here is an opportunity where people are taking the opportunity to sweep away that tech debt, I suppose, and and start again almost. No.

Absolutely. Okay. I and I guess we've been maybe lucky enough to be involved in some projects where we've had, where it's either it's it's either greenfield or it's parallel transformation where we're gonna build on something and do and move into that. But, yes, of course, if you're, you know, if you're running a live environment and trying to fix the plane while it's in the air, then that's a little bit more difficult. However, what I would say is I am a big sort of fan of, identifying your appropriate target architecture, state, and then trying to plot away to it.

I don't like working from a situation where you compromise the final solution because getting there is difficult because that's that's where you end up somewhere somewhere in the middle where it doesn't quite fulfill the requirements with a lot of technical debt and a lot of so it's just one of those design principles I like to stick to that this is this is ultimately where we wanna be. Now let's try and figure out how to get there. And and that might be a a longer journey for some because it's complicated, but, you know, I haven't come across a situation yet where it hasn't been possible. No. So it's a good it's a good point.

And I think something that that you learn over time, I guess, when you're when you're building networks, when you're when you're going through this this this pragmatism, approach of of saying, well, look. Yes. You know, I'm not gonna be able to get there right now, but I can set a direction that's where I wanna be, and let's let's take the steps to get there. Whether they're the steps that the vendor expects us to take or not. I mean, there's there's also that that aspect to the pragmatism as well.

Right? Well, yeah. So this is I think I kind of maybe touched on this right at the beginning around navigating your way around the sort of the the vendor marketing. We're lucky enough to work in a position where we don't have to be, vendor specific. We can be quite agnostic.

And, I think it's it's important not to just go where the vendor wants you to go because the vendor wants you to go there. You know, the the we we have customers who've been sort of, stunned by, not just end of life, but end of product, or sort of, you know, heading down a a development cul de sac and what and and investing in that. And that that can be that can be quite difficult for customers. So I think it it is important to really, you know, I I spend a lot of time quizzing vendors on where they're going with a particular technology before investing in in a in a longer term strategy on it. And so, yeah, I think that that's something that's quite important.

Which is, again, that feels like an approach that's born out of experience. Right? Because we've seen it happen often oftentimes, before, right, where products just cease rather, rather rather abruptly sometimes. But No. No.

Indeed. And, look, I mean, that's just the the industry we're working because you can't you know, vendors can't, if if they have a product line that isn't that isn't doing well, then they have to make a they have to make a difficult decision on that. And, but I I think it's just a kind of case of, you know, customers doing their the the the diligence on it and making sure that they ask the right questions. Yeah. That's a good point.

I I mean, we're talking about those those challenges, and we're talking about obviously the changing face of of of networks. And and we've got a whole bunch of categories of things that that are, you know, the vendors are trying to sell to us at the moment or people are trying to help guide us in a particular direction. We're seeing more SDN. You've touched on that already. We're seeing the cloud networking.

We're seeing more automation. Are these things that are playing a big part in in your conversations at the moment? Yeah. So I I think, you know, taking those in the order of, probably SDN, cloud networking automation, for SDN, I I think there's been a lot of interest in that for a number of years. There's maybe been a little bit of skepticism, but I've always seen a lot of value in it.

I mean, most of the SDN solutions that we've looked at have been, in data center or when. And I think in both cases, you you think all the obvious things the centralized controller programmability. But for me, in the data center, it was about having that layer 2, layer 3 overlay and across multiple data centers. As a network engineer, there's so many problems that solves. It takes away spanning tree.

It allows you to have a single layer 2 domain, layer 3 domain, policy domain. And that's across multiple vendors without getting specific on it. I think those things are I think I think that's always been the case, though, in the in the data centers. There were always those additional challenges that we were set as network engineers by the infrastructure folks who said, look Yeah. In order for me to deliver infrastructures and applications the way I know how, I need this capability.

And that would be I mean, the classic was always the stretch layer 2, right, between 2 locations and those kinds of things. The the yeah. The the stretch layer 2 is is absolutely the classic problem. But back in the back in the day, it used to be, you know, stretch layer 2 was bad for networks but good for infrastructure. And and ultimately, I mean, we we have to realize that networking is a it's a foundational technology.

It doesn't actually give anything in itself. It just acts as the foundation for the things. So you can't really expect infrastructure or the, I guess, the compute and storage guys to to accept that because the application that sits on top of that needs needs those. So we we had to find a way around it and just be very careful with our spanning tree. So, you know, the idea of, you know, I guess, underlays, and then overlays on top of those, I think, solved a lot of problems.

And so so we, you know, been implementing SDN solutions in the data center for maybe about sort of 7 or 8 years now, more recently than, SD WAN solutions for the last kind of 3 or 4. And I think, again, you've got the programmability. You've got the centralized controller, but the real big thing for me, was transport independence. The idea that, you know, we we can have MPLS over here because these sites really need that performance, and we can have Internet everywhere else, and we can just add it all in, and we don't have to do anything crazy with policy based routing. You know, that that was, I I think that those those are sort of big items.

Yeah. I think things like, as well for me, it was always, being able to have that that continuous sort of segment segmentation of network regardless of of, whatever transport. You know? You can see it the the solution there, you know, effectively that that multisite VPN type approach. It just just made complete sense to me.

All of a sudden, you've you've got this this ability to to get that segmentation because you're keeping it separate from from other other segments, but also, commonality regardless of which access you're using. I think there's a there's a whole bunch of good use cases there. Right? Mhmm. Yeah.

No. Absolutely. So and and I I guess the other thing there is is things like analytics as well. I think I think that's that's useful in both cases, but but but but the certainly, the the network functions across SD WAN and data center were the were definitely the big things. Yeah.

No. That's that's, that's a good point. So I guess as well I mean, I don't know how you how much you're seeing of this. So do you find SD WAN is helping the problem of cloud connectivity as well, or are you using other other ways of of managing that? Yeah.

Absolutely. I think because, like I mentioned earlier, to me, the the WAN isn't really the WAN anymore. Yeah. You know, it's the the the SD WAN is your means of connecting to where your resources are, private data center, SaaS, public cloud, etcetera. So, and and and I think a lot of that innovation is now built into SD WAN.

And you see, you know, it was starting to see architectures for, you know, peering across different regions and sort of cloud providers. So it's all about accelerating that. But then I think kind of cloud networking in itself is is then also becoming, its its own little area, or not little really, actually quite considerable area. Yeah. I think I think I know it's a challenge that we see regularly is is networking folk really having to grapple with, I suppose, the differences and the challenges of of the different cloud providers and the and their networking capabilities and be able to make sense of them all in in in one way so so that they're able to to understand it because it's it can be tricky.

Right? I I know I've done plenty of study of the different cloud, environments, and they're all they're all different and nuanced than whatever. Yeah. Yeah. Well, I think that there's there's there's a couple of challenges that our our customers sort of look at.

One is getting to cloud in the first place. So, you know, so you can obviously, you've got, Internet connectivity, or you can take the Direct Connect Express Route and, etcetera. Or then you've also got middle mile providers, who will give you one connection, and then you take connections into each of them. So that's the first one to, I guess, wrap your head around and think about how you're gonna get there. And, usually, as well, you're going to need presence in a data center to do that.

So so so so that's a that that's a challenge. Then once you get inside the cloud environment again, you've got different architectures across the different cloud providers for how you do it. You're looking at, you know, one of the the networking vendors sort of approved designs on this. They talk a lot about, say, transit VPCs and VNets that it uses ways of hooking them together. And then you've obviously got routing constructs within the different cloud providers yourself as well as all of the networking vendors giving you virtual machines that you can drop in there.

So there's so many different options and things to look at, and then there's a lot of restrictions around performance as well, things like, you know, the support for support for NASS, support for a number of different routes. You know, so there's there's there's many things in there to to think of, but it's a fascinating area. Yeah. When you've just walked through all of those those things, and I'm there thinking, yeah, things aren't getting any simpler, are they? I mean, it's this is automation was always so you know, it's supposed to be this big sort of simplification of of network operations.

Well, well, even before we get to the automation part, and and maybe it actually leads into one of one of the other challenges is where you've got your developers like AWS and they like Azure because everything's API based and that's what they're used to. You know, but, and this comes back to the organic environment that I mentioned previously. So there's maybe a tendency there to have a go at your at your transit gateway or what whatever it is because, and and then you don't have a sort of a network view on on on how that that's implemented. So I think we're reversing, reversing some of that out. But, yeah, I guess that kind of brings us on to, on onto automation.

And and even aside from cloud, there's, I think that there's a lot going on in that space as well. I think for a lot of the people that we work directly with, it's not the reality at the moment, because we tend to work with organizations who've organic growth, so they've got a very heterogeneous, environment. Yeah. They don't have standardized configuration. They don't have standardized designs.

If they had it all nice and simple, then they probably wouldn't need to engage with us in the first place. So I think you really struggle towards to to do network automation, that kind of environment where we've kinda seen it, where we've seen it go really well, and people are getting a lot out of it is, either larger organizations who can afford to do that standardization or service providers, who who, and particularly some of the the the the newer ones, who standardize products, homogeneous vendors, can do everything the same way every time. Yeah. I I think that's been valuable for them. I think I I mean, we find again, you know, having those conversations that people tend to to look very carefully at how they scope their automation ambitions and say, well, look, you know, I I just wanna focus on one part of the network or I just wanna focus on on one particular technology and and and zoom in on that.

I guess, ultimately, you know, at some stage, we we're gonna need to consider what that looks like in the bigger picture. But I suppose as the shape of networks changes, you've already mentioned, for example, you know, perhaps not having a a private WAN environment anymore. And as the maybe the dependency on SDN, you've got a controller which is now API driven, so you've you've got more more opportunity. Yeah. Look.

I think there's a couple of things. I guess it depends on how you define automation. Is making a couple of API calls to get some analytics information. Is that really automation, or is automation where, you know, you do all of your your your initial deployment sort of, you know, straight. And and actually sort of setting your organization up for automate automation is difficult as well.

You need people with the right skills. You need the processes. You know, you need the development pipelines. But then you raise a sort of a very good point because, if you're working in a cloud environment or an SDN environment, then you already have a GUI, that's doing a lot of the underlying configuration program for you. So maybe you don't you don't need that, so much.

But but then it becomes a story of orchestration, right, rather than than automation. And you're you're leaving the automation to the to the controller. But what you're having to do is build the workflow, which hang on a minute. That sounds pretty much like building idle processes and putting putting that stuff together. We've been there before.

Yeah. Well, I I think you you still have, obviously, the sort of the technology piece to it. So I was involved in the build of a sort of public cloud infrastructure service a couple of years ago, and a lot of work had to go into we we had all the underlying technology was was SDN array API based, and that was a sort of a deliberate choice so that we could actually do that automation. But but then creating a flow to do anything sort of useful for a for a customer was, you know, you've got an abstraction layer. You've got a sort of a layer that keeps needs to keep all this information.

Then you need, sort of scripts and flows for not only building, but, well, for also tearing it down afterwards. So there's kind of so many things in there that are that are difficult, and I think a lot of organizations are looking kind of thinking to themselves, well, you know, what am I gonna get from this? Am I gonna if I'm gonna put a huge amount of work into developing this, am I gonna get a return on investment, you know, for maybe for for an average enterprise, that isn't going to change so much then, you know, maybe that network automation is is isn't going to give you, a return. And and then, of course, like you mentioned, you've got all the idle stuff on top of it because now if you're automating a piece of configuration, how do you know that that's got the appropriate control around it and whether you want to just hit a button and let that loose on your network? And that takes, you know, we've definitely seen that go wrong.

Yeah. You know, we we we've we've had sort of a number of instances of that. But, you know, at the same time, anything we can do to lessen the influence of Vital is welcome. Well, this is the thing. Right?

It's, you know, it it makes me smile when we talk about the likes of of dev ops and and these ideas because we've spent so long building these these big rock solid change processes and all the rest of it. To then dismantle that, to to take a a different approach is, strikes me as as an incredibly difficult thing organizationally. Never mind the technology. The the technology is probably the easy bit in that sense. And and it certainly in many ways, it's it's easier on us to to to take that kind of approach.

Right? So, you know, and and this is direct experiences. We we we've worked on projects, which just to keep the numbers nice and simple might be a a 10 day project with, you know, 2 days worth of actual engineering work and 8 days worth of, worth of admin, you know, to raise the appropriate to create the appropriate schedule of events and, attend all the change meetings, get the change approved, and, yeah. But but again, I mean, this is this is the other part to it. I mean, I one of the things I always make make sure when I was architecting, networks for for for my customers was that they've gotta be supportable.

They've gotta be maintainable, and they've got to have all of the the support process and everything wrapped around them for them to work properly in an organization. So the organization gets the availability because otherwise, you can build these incredible tech technological edifices and then just fall to bits and be really brittle because there's no process around them that makes any sense. So it comes back to the pragmatism again. Yeah. So so so some of our engagements are more consultative.

In a lot of cases, you know, we'll we'll be we we won't necessarily do it, but we'll indicate the need for some operational readiness. Because if you're doing network transformation, you could be moving away from a, you know, a set of devices that are all very command line driven to something, something new and and SDN based, and and that has that has a lot of, operational impact, like you say, on on change. But also on sort of, also on skills, speed, the visibility that you have of the network, and and and also how you do, you know, when it comes to when, how you do your procurement as as as as well because, yeah, because you need to you there's an opportunity to look at all of your contracts and Yeah. And circuits. No.

That's that's a really good point that that you know? And that's the thing, isn't it? That that the network is foundational in IT, but it has so many implications for for so many other areas. So, yeah, no. It's a it's a it's a very good point.

Mate, I've got a sneaking suspicion. We could just go on and on forever with these things. But any sort of any closing thoughts at all that you might want to share? I think only the, you know, the areas that we're we're really starting to look at now are are cloud networking. You know, SDN has has has always been there both WAN and and data center.

And, and and just sort of, skills, you know, the and continual development of those. I I do think, but but understanding requirements as well and having that Yeah. Long term view of of what you want the network to look like, 2, 3, 4 years out, I think, is really important and and and, you know, plotting a route to get there. Yeah. It strikes strikes me that that that long term view is is always gonna be super important from the network design perspective.

Right? Yeah. Yeah. Awesome. Listen.

Thank you very much for your time, mate. I really appreciate it. Are you, do you have any details that people could get hold of no. Let me do that bit again. Hang on a second.

Really appreciate your time, Steven. Thank you for joining me. How can people get hold of you if you want to talk more about, about some of the topics you talked about today? So, I guess probably the social media that I use the most is LinkedIn. I'm not much of a sort of a Twitter person, or x person.

So and, or come visit us at our, our sort of website, which is just, starfishlabs.io. Like I said, you know, we're a very network focused organization, so always happy to to share, some of our experiences and talk with, with with other engineers and and architects. But, yeah, find me on LinkedIn. Search for Stephen Hampton. Awesome.

Thank you very much for your time, mate. Much appreciated. And, thank you for those listening. There'll be another new episode next month. Until then, happy networking.