Hi, everyone. Great to, be along for another community fabric. Well, what do we call these things? Conversations, podcast recordings, live streams, whatever you wanna call it. We're we're here, on, LinkedIn live chatting with someone who, let's face it.

I'm sorry, mate. I'm gonna have to say it. A bit of a legend in the, in in the the networking space. Duane, Lightfoot, do you wanna give us a quick intro, Duan? Great to see you.

Hey. You're too kind, Dan. As many of you know, my name is Dwan Lightfoot. I'm a cloud networking developer advocate here at AWS. I'm passionate about networking, and I'm excited to be here.

Yeah. It's great great to have you, my friend. And and and I'm sure, as you said, loads of people know who you are and and and have followed your journey, I suppose, because you've it's it's been fascinating watching you sort of grow and and go through all of this all of this stuff in in a in the public view as well. You know, we've put yourself out there from day 1. Right?

And and it's been really interesting, watching all that happen. As a as a networking old guy myself, you know, I've I've it's it's brilliant to see because you you've really been a fresh a breath of fresh air and and watching you and the way you engage with with an audience and and and show people what's possible, you know, has has been a real inspiration, I think. Would you mind giving us a little bit of a background about your your networking side of things? Because, obviously, that's that's where this started. Right?

Yes. So my background yeah. Well, I'm an air force veteran, and that's kinda how I got started in the air Sure. In the air force. But during that time, I kinda dabbled in different areas in tech, right, until I really landed in my passion, which is networking.

And my first role was my first official role was a network technician. And in that role, I think we I supported about 40 different buildings, but it was a flat layer 2 network. Mhmm. DTP everywhere, you know. Version version 2, version 3 is it could be a nightmare some days.

You know what I mean? And so I really learned a lot about, you know, layer 1, layer 2. And then kinda transitioning in that role. I set up a whole new environment, but this time, I used layer 3 with EIGRP. And so that kinda just helped me, you know, on the trans transition to become a network engineer, getting my CCNA.

And so after that role, I became a network engineer supporting a very large infrastructure, about 33,000 different locations. Mhmm. If that was So so you say 3000? 3000 different locations. Wow.

Right. Okay. But it this is the thing. In in that world, right, we had some traditional networking, but we also had some some location that was still t one. You know, t one, t t three, depending on how it b s 3, how we had the network design.

So I had to do a lot of migrations in that role. And that's what kinda introduced me to network automation. You know, if you have to support infrastructure at that scale, you know, you may not have the man hours or woman hours, you know, to support the infrastructure as need be. And so automation is gonna have to play a role in that. So that's kinda how I got started down this journey in the transition into network automation.

And I just sat there. No. I've been and and this is the point, I suppose. We followed you through through a lot of that process, the the the the learning that you went through in order to get there and so on and so forth. And I know you've you've mentioned before that that, the CCNA kind of kinda changed the way that that that you you approach your career really and and, really developed as an as a as a, a a man working in tech.

Right? It was it was important to you that important to you. I mean, obviously, you're not now working in this pure networking. And I'm I'm really interested in this in this transition because you've talked already about about the fact that you've got this you're rooted in in the classic networking that you've that you then started looking into the automation piece and and focusing on that. And and and, I guess, really seeing the benefits of it and understanding why you would why you would need to focus on it, particularly when you're talking about that sort of level of scale.

How did you go from there to where you are now? That that transition kinda was like it it all was kinda lined up. So before I took the role that where I supported 3,000 sites, I was a system administrator. And so in that role, as we we migrated from Windows Exchange to Windows 365. Right.

Right? So that was my first kind of experience with the cloud. Right. And then we had this one of our large scales at applications where we started beginning to plan to break that down to a microservice so it can be faster, scalable, and more reliable. Right?

Because if one piece of that monolith breaks, you know, the whole application is down. So Sure. We we started rethinking how we would deliver this application. And in that process, the call just kept coming up. So there there's sprinkles of curiosity Yeah.

You know, 6 years ago. And as our plan transitioned to different roles, I'm often standing up VPNs that connect to the cloud. Right? And I'm wondering, okay. What's on the other Yeah.

Yeah. Exactly that, isn't it? It's like, that gap, isn't it? I know that I'm connecting to the cloud. Yes.

What is that thing? What is that thing? Exactly. So that like I said, a sprinkle of curiosity just kept happening throughout my network engineering career. And so before I joined Cisco in 2020, I was really heavy into network automation, and so I started using more APIs.

I started leveraging Terraform. I started leveraging, Docker containers and all these different tools. And I'm standing on VPNs to the cloud, and I'm talking to these dev DevOps engineering teams. And I'm hearing about the application and the things they're doing, and I'm just curious. But as a network engineer, it's kinda hard to step outside and just do a VPN to the cloud because you'll have you may have a cloud engineering team that just focuses on the VPC side Yeah.

Yeah. Infrastructure side in the cloud. You know? And and to be fair, most organizations do have exactly that, don't they? Because because they've come from a situation where where where those same people who are probably looking at cloud, infrastructure now were the ones who were doing the on prem infrastructure, servers, storage, all that good stuff in the on prem data centers of of old.

Right? So so I think that's that's a really interesting point that what you you've got these these separate silos, right, looking after the different parts of the infrastructure. And and and as well as, you know, it kinda it makes sense because you have different skill sets and different areas of focus on both teams. Right? It's like having a security team.

You have different areas of focus. And so what I started doing is just ask some questions and looking at tickets that they're working on and just trying to be a part of the conversation and then certain myself where I can to learn what they're doing. Right. And, you know, that kinda led me to, just continue being curious, but I I didn't really make the transition until I got the opportunity here at AWS. Sure.

Sure. And, of course, now that's that's opened a whole load of doors. Right? I should imagine. And, and certainly from the certification standpoint is, it's it's a whole new world.

Right? Yeah. I mean, you know, I'm I'm someone that has always supported certifications. Not because of the benefits that they add to your resume, not because they can help get you interviews, not because they can increase your salary, but because they give you a a starting point to learn new skills. Right.

They give you these these guardrails to say, okay. Here's what you need to learn in order to do this job role. Right? Yeah. And so Yeah.

And I put you on the path. It's it's but it's the path. Right? It's that thing, isn't it, of going, do you know what? If if you wanna reach a certain level of of of ability, capability, I suppose, in a particular technology, then these this is the path you need to go to to get there.

These these are the fundamentals. These are the specific areas that you need to focus on. This is the depth you need to go into and so on. It just gives you all that structure. Right?

I'm completely with you on that one. I mean, that that is is a is a long running debate, obviously, about about do you do search? Do you not? I think certs are are great for that structure, from a learning experience. Right?

Some some better than others. But but, ultimately, that's if you if you've got the opportunity to use them as as a, as the path, then follow that path, by all means. I think it's, it's, yeah, it's a really valid point. Sorry. Go on.

One thing that I've always done is I focus on search that are aligned with what I'm actually doing. I don't focus on things that I'm not doing. And so that helps me, you know, learn more in-depth the things that I'm working on as well as once I pass it, so I realize how much I don't know. Yeah. Well, that's well, that's right.

So that was the the that was a joke from from the old CCIE days. Right? It was when when you got your CCIE, the whole point was that you just found out what you didn't know. Right? That was the whole the whole thing.

And I think that's why certainly the mindset of 1 of the of a lifelong learner is exactly that, isn't it? It's always like, right. I know this now, but think of all these things I've yet to find out. You know? And and I think that's that's super important.

But you make a really important point there as well. It's not about what you don't you what you're not doing, I suppose, is going chasing a cert in order to get into a particular technology. Right. What you're doing is supplementing your day to day role and and the knowledge that you've accrued through doing that with the certification process. Right?

So it's so it's augmenting the process or the learning process, right, rather than trying to to to use it to take you somewhere new. Right. Really important point because I think that that can be a struggle for people, right, is is if you're switching to something new without having the context of of what that new thing is. I think what what you've described there and so many of those things ring true to me. The the the business of the of the the cloud infrastructure team, knowing the cloud infrastructure but not understanding the connectivity, and then the network team knowing the connectivity but not understanding the cloud that they're actually doing the thing you expect them to?

You you can't because because one person doesn't know what the other thing should be doing. And I think you you end up with information disappearing down a a gap between the 2, a skills gap or a documentation gap or or just a knowledge gap. And that's the important thing for me to fill in. And I think why we need to get more network folk really appreciating and understanding what cloud means. Right?

You know, it it it you make a great point because if you start in in the cloud as a network engineer, you know, as a cloud engineer, you kinda skip steps on building that foundation in networking. And I think as a network engineer, well, you already understand layer 1. You already understand layer 2 and how the everything is actually connected. And then once you get to the cloud, now you're just looking at overlays. You know, you're just expanding on the things that you've already been doing with routing in different protocols.

You know? Yeah. Hey. This is really interesting. I I I don't know if you know.

We we had the chance to chat with with Jose Moreno from from, Azure, a couple of months back. And CCIE, super clever guy, you know, got loads of networking experience, went to work for Microsoft, and he's gone through that same transition. And what he had to do was really almost create his own understanding of the networking aspects of the cloud in order to to present it in a way that made sense to him. Right? And I think this is the this is the key, isn't it?

What you just described there, understanding all the stuff that sits underneath is great, but but you do get to that point in the cloud infrastructure where it's represented in a way that that doesn't necessarily make immediate sense to the network engineer. Right? And so it's it's being able to to create that that understanding of the overlay Yep. That makes sense to you as a as an individual based on your experience. And I think if you're you're right, I think if you've gone through that process of learning networking from the ground up Yeah.

You're so much better prepared for that. So Yeah. Yeah. I think that's a that's a really valid point. That's a good one.

I'm gonna switch gears a little bit. So so if you think about the, from an automation aspect, obviously, all of the the work that you've done up to to this stage, The tooling that you would you were using for your automation, I mean, what what what was if you if you could zoom in and say these were the things I was using, what were what were you using? There's a there's a short list, but actually kinda long list list because the breadth of knowledge Sure. You know, that it kinda takes to put it all together. Yeah.

But for me, I think learning Linux is like number 1. Just Right. Just just on that, actually. Delaine, there's your answer to to question number 1. Right?

Linux is super important. Learn it. There we go. Go for it, mate. Sorry.

Linux is super important. I'm actually working on some content around, like, skills you need to learn right now. And so Linux is kinda at the top because when you think about software development, you think about the cloud, you think about IoT devices, you think about you you name it. A lot of the applications running in back in the databases, web apps, they're built and ran on operated on Linux. Right?

So that you as a engineer and as a developer is having a strong understanding, and lens is important. Yeah. The next thing is understanding the version control. One of the biggest problems I'll face as a network engineer back in my day is device configuration Yeah. Like version control amongst the teams.

You know, somebody will create okay. This is the source of truth of what everybody should be using to script routers and switches. This will get passed amongst the team. It's supposed to sit on the file server or something. Somebody will edit it.

They become different versions of copy, Which one is the good documentation of a real diagram? So understand the version control with git GitHub. Like, that's just important from a, a source of truth aspect in in a merchant team. But as far as managing your code, same thing applies. Yeah.

Yeah. Absolutely. And in terms of, of the coding, just give me a flavor of what the what the sorts of tooling that you would have used. Let's say pre cloud, would be you know, if you if you were automating an on prem environment, what would you have used? Well, the tool that I saw with and the tool I kinda stick with today, which I'm kinda looking at some others right now, but Python is the core just because of how widely it's supported amongst the libraries, amongst the community.

You can do a lot. And the flexibility that you have Flexibility. Yeah. Yeah. Good.

It's it's interesting, isn't it? Because I think a lot of people go through, particularly in the open source, people go through different tooling to to try and get to the place where they're most comfortable. They'll they'll look at the they'll look at the answerables. They'll they'll probably have looked at some stage at pocket and chef and and and all of the the kind of or a kind of orchestration rather rather than programmability because it's it's about the getting to a point where you're comfortable with with being able to achieve something with the with the minimum possible, outlay of of or expenditure of of resource. Right?

So to be able to go, I just need something to do something. But then you very quickly get to a point, I think, where actually that flexibility becomes more important. Right. And often people just end up naturally in a Python, You know, just not descending into that level, but but having to to go to that level of detail. You know, look looking back, I took the long road.

If I was starting over, I probably would have started with ans Ansible because it's more imperative rather than Python is more imperative. Okay. So you gotta tell Python not only what she wanted to do, but actually how I hope to do it. My own code for that. But in some, like, Ansible or TerraForm, you just declare or define in the configuration what you wanted to do, and it does everything that it's supposed to do on its own.

You don't have to turn it to steps to do it. So you just you just said you just slipped something in there. You mentioned, the magic word Terraform. Right? Which, again, from in that traditional network automation sense, people don't tend to talk about Terraform a lot.

Right. Only once the the cloud door is opened. Right? Primarily because it was used as a as a way of building cloud infrastructure, right, initially. Do you wanna just fill us in a little bit more on that?

Is that is that is there anything more to to say? Or Yeah. Man, we we can go on and on about it. But the first time I started using telephone was when I Yeah. Got introduced to ACI.

Right. When I started using ACI, we tried to automate into ACI. And then I was like, you know what? Let me try out this telephone because somebody on the DevOps team had mentioned it to me, and I was like, oh, this is amazing. You know, I started building subnets, building, bridge domains, all of this inside of ACI with TerraForm.

It's a infrastructure. It's called tool, so your infrastructure is entirely in code. When you're when you're, automating to the cloud, now you know exactly what your VPCs that you have in the cloud, you know, the EC 2 instances that you have in the cloud. All of this is defined in a configuration or a state file that you can get locked. So if anybody tries to automate any changes that go against the state that you already have locked, they you they won't they won't be allowed to automate those changes through telephone.

You have a lot of capability in this. So so just just help me a little bit there. So so what you're saying is you're able to create, an abstraction, I guess, of the state the the end state that you're looking for in the, in your infrastructure, whether that's on prem or off on cloud. Is that fair? I mean, I guess you talked about ACI.

Right? So that's that's on prem. It's cloud and on prem. So Right. Underneath, when we start talking about Terraform, it it uses API calls.

Yeah. The the concept of providers is only an API call. So it's communicating with the API. If there's a provider built, it communicates directly with the API or whatever platform that you wanna communicate with. And if you don't know what an API is, that's a application programming interface.

Look at every look at it as an, a middleman or a middlewoman between the platform that you want to automate Yeah. And then the code that you're pushing to the the API. The API is what handles all of that traffic to get routed to, let's say, create an interface, shut down an interface. Your API kinda handles all that. Sure.

So you can basically create these providers then for for anything that that that handles, an API. So so I guess like you say, ACI controller driven. Therefore, there's an API. Yeah. Cloud networks controller driven, so there's there's an API there.

Yeah. And I guess this is this is the thing, isn't it? I I know that the that the cloud providers often have their own tooling that you can use to spin up and automate their own their own infrastructure. But Terraform, I guess then, is multi vendor it's kind of vendor agnostic tool for for that purpose. Right.

So you can use it in the cloud, and then you can also use it on prem. Yeah. So that's that's what I'm trying to Multi multi cloud as well, I guess. Right? Correct.

It doesn't doesn't care so long as you got the right providers for for Terraform. So Yeah. Care so long as you got the right providers for for Terraform. So so so we we kind of answered that that question then, I guess, of of what the difference would be between doing an on prem automation and a a a cloud based because of the API driven nature, because of this idea of of creating this this declarative view of of what you want the infrastructure to look like. And so and so the provider, I guess, just just makes makes that that happen, right, based on on the, on the data that's that's sitting in the, what did what would you call it?

The the, the inventory. Are you talking about configuration file, the sleep file? The real estate. Yeah. Yeah.

Right. The configuration file. Right. Okay. Configuration file.

Okay. Cool. So Then it creates that state file once you once it once you telephone a file. Yes. Kind of kind of right.

Okay. So it kind of renders renders the state and then and then pushes it through through the API. Right. Okay. So does are there ways of dealing with traditional networking infrastructure with Terraform as well?

Would you be able to let's say you you had a, I don't know, Cisco, Nexus data center as well, and you wanted to push stuff not not not through ACI, but through command line. Is there a way of doing that with with Terraform that you know? Or I would have to check on providers. That part Yeah. I'm not sure.

For something like that, I would either use Ansible or Python. Right. Or or it should be I guess I guess what I'm getting at is is then that because, obviously, the the next things. As as we know, not everyone is going completely a 100% cloud. Right?

That's that that we we kind of started down that path, and I think people realize quite, you know, hey, how expensive it might be, but also how restrictive that that would also be. So so now that that hybrid approach of having some some on prem, so mostly cloud based, potentially multi cloud seems to be the way that people are driving. So it's, like, I I guess it's ultimately, what you wanna be able to do is is automate that as one, really, isn't it? And and kind of kind of create that that service of So multicloud. Sorry.

Go on. I can give you, like, a a great use case. Go for it. In in one of our roles, we had, like, ACI, which is API driven. So all of the data that you return or request from ACI is gonna be structured in JSON.

Right. But if you're dealing with SSH, that data is not structured. You're gonna have to parse that data with, like, regular expressions. And so what we did was we built a NoSQL Mongo database, use our AC I used, like, NetMico or something to gather that data, parse it the way we want, put it in MongoDB, and now we have your entire inventory, interface information, route table information, ACLs, you name it. You can put it in a database.

And now since Mongo actually allows an API that comes back structured in JSON, you query Mongo to get the information that you want from your devices rather than having all of your network engineers query devices, try to parse these devices. Sure. You just talk to the Mongo database to get the information to say, okay, what is the, BGP information for this device, etcetera. You know? So so would that then you have a provider for Terraform for for Mongo.

Right? Is was that that how it might work? You could build you could build yourself. Right. Right.

Right. Right. Right. Yeah. So, again, I'm just just trying to piece the piece the thing together, really, to understand it.

And, obviously, we're pushing Terraform as a as a particular thing because that's the experience you've had. Are there any any other tools that are similar or or have a, that that you could also use? I so we have CloudFormation at AWS Right. Which is if you're building on AWS, CloudFormation allows you to create stacks Right. To build out your infrastructure.

But, a great thing about using CloudFormation, we started talking about hybrid networking, is the AWS solutions library. A big thing in software development is don't repeat yourself. Yeah. Obviously. Right?

And the same thing applies to solutions in code. If there's something, an idea that you have, there may be already a library created that does exactly what you needed to do rather than you trying to write the code yourself. So the same thing applies to your infrastructure. There may be someone that already configured the infrastructure exactly what you want your infrastructure configured. And so at at this point, you check the AWS solution library to see if somebody else has created a cloud formation template for that.

Yeah. Yeah. We took it, load up the stack, and now get infrastructure. You just do the configurations how you want it at that point. I see.

And and that's, I guess, the the beauty of of an automation approach generally, isn't it, is that that you're able to template things, to share those templates, and to and to kind of kind of works from a community basis. Right? Because if you get the right community of people together who've done done the things that you're interested in, then, you're able to to, to share that amongst the the community as well. Yeah. Yeah.

Awesome. Which, of course, leads us very neatly on. And and, unfortunately, Andy, he could wasn't able to join us today. But Andy, of course, has set up a little Slack group of of exactly this, people who are doing cloud automation. Right?

Yes. Which is which is great. I don't know. Have you had much chance and opportunity to, to mill around in there and make some time at all? It's going it's going every day.

He'll be really passionate about cloud network automation, and he's he's doing some great things internally and externally. I'm I'm happy to be work working for me and working for me. Yeah. Yeah. Really.

Unfortunately, he's just too busy alternating clouds for today, so he wasn't able to join us. But but, yeah, hopefully, we'll we'll get him on again later. And what we'll do is we'll share links for the for the Slack group and everything with the, the notes for this. So so and people are able to to to join up because it's, yeah, it's it's a busy resource and and lots of interesting folk doing some really cool things in there. So I know I've spent a bit of time in there.

I'm now thinking of all the opportunities that we've got for integrating IP fabric APIs into this stuff, but that's just me. So yeah. I yeah. I'm, this this isn't a sales pitch. This is.

It's all it's all good. I'm just checking. We've got a couple of questions, which are coming, but I'm just checking. I think we've actually answered them along the way. We talked about managing cloud networks from different vendors.

So so I guess I mean, we talked about I mentioned AWS specifically, but with, obviously, Azure, Google, Alibaba, all of these are gonna have providers in Terraform, right, that you're able to to take advantage of. So that's all cool. And then, the other question we've got was, do we interesting. So talking about using, APIs to manage all the different multivendor networks or if there's a kind of framework to abstract those. I don't know if there's anything there that you've you've stumbled across at all where it where you're able to, for example, create an object and and then that same object is, could be created in AWS or it could be created in Azure, but but it's abstracted away.

Is that I guess Terraform, I I believe, kinda does that. Right. I guess that's exactly what I was thinking is is that actually from the way you've described it. That's that's that's pretty much it. Once you have your providers, then at that point, you can start building resources.

Right. So you would just have different, different, modules Uh-huh. Depending on what you wanna deploy. So if you wanna deploy a VPC, you create a module or you found a module that's already ready to deploy the VPC. Right.

And as long as you have providers installed, at that point, you you just build your code how you how you want it. Right. And it and it will just go ahead and and build build it wherever you want it to be built with the the credentials and their logins and the accounts and all that sort of good stuff. Right? Yeah.

No. That, that makes a a great deal of sense. I I think that pretty much answers the questions that I can see at the moment. But, I guess, is is there anything else that you would like to point out? I mean, you've already mentioned that you're looking to do some content, which is always a good thing.

Right? So because Duong content is always always good to say. But anything else that you'd like to to sort of just, just mention? I think it's important. One of the things we didn't miss, we didn't talk about was testing.

Uh-huh. It's important to Yeah. Test your code. Test, test, test. There's test and frameworks like unit test and Python, Pytest and Python.

There's PyATS. Testing is very important. And so, when we start talking about automating, creating pipelines that have tests built in it that you can automate the end result or mainly do check the test once they've been, have been run. Having those pipelines in place is a real, key into a successful automated deployment in your infrastructure. So I got a couple resources I know from re Invent 2021 and I did this this to you there.

There's a net DevOps, a modern approach to AWS network deployments. That's a great talk. As well as Ed Cho, he has a, LinkedIn learning course that he just released that I have some engineers where he talks about the entire process of NetDevOps, which I believe having a strong foot. Understanding of DevOps before you even talk about NetDevOps is important, and he kinda covers all of that. So those 2 resources will be giving you the big picture approach to how to apply automation in your organization.

That's that's perfect. And, again, we'll pop those links in the, in the notes after. But, yeah, Eric's stuff, always good. It's always good to, to to hear what Eric's got to say because he's, he's definitely a man on a mission. So, yeah, that's great stuff.

I think, my friend, I'm looking at a time. I don't wanna keep you too long, but it's it's great as always to talk. I guess the only question is, where can people get a hold of you, Duham? Well, thank thank you, Darren, and IP Friday for having me on today. It's been awesome.

Thank you to the community for joining us. You you contact me at Lab Everyday on every platform and do one life with on LinkedIn. Awesome. Well, thank you very much for your time, mate. It's always good to talk, and we'll, we'll definitely talk again soon.

And, yeah, we'll, hopefully see you again. Thanks very much.