Bridging Networks and Platforms: A Deep Dive into Platform Engineering with Chris Wahl - C2C030

Chris Wahl: 0:00

I don't know. I feel like we're all kind of old infrastructure horses and we like to cowboy a little bit and that's not great for quality and I suffer that sometimes I'm like ah, it's dev, whatever. And it's like ah, a lot of people did not like that. I pushed that button.

Chris Miles: 0:15

Welcome to the Cables to Clouds podcast. Cloud adoption is on the rise and many network infrastructure professionals are being asked to adopt a hybrid approach as individuals who have already started this journey. We would like to empower those professionals with the tools and the knowledge to bridge the gap.

Alex Perkins: 0:44

Hello and welcome back to the Cables to Clouds podcast. I will be your virtual host today. My name is Alex Perkins. I'm at Bumps in the Wire on socials. I'm joined, as always, by my two lovely co-hosts, Tim McConaughey at OneGolbez and Chris Miles at BGP Main Golbez and Chris Miles at BGP Maine. So we got you know. I like to talk a lot about platform engineering on this podcast, if you've listened to any prior ones, and I think we got a really great guest today. That's going to kind of go into some of the ins and outs and hopefully we'll try to ask some network engineer centric questions around platform teams and what things to know, what things to look out for, stuff like that. So let's jump into introducing our guest. It is Chris Wall. Chris, if you want to go ahead and just do a brief introduction of who you are, that'd be great.

Chris Wahl: 1:36

Sure, and Alex and team. Thanks for the invite. Like you said, chris Wall, I work at a company called Slalom. We consult on a lot of things, technical and non-technical. I won't go into the details, but within there I'm a delivery director, which basically translates to all of the designs for software and platforms and quality and things that a technology company needs.

Chris Wahl: 1:57

I get to be part of the team that figures out how we're going to do it, assemble the team and get them staffed and organized and then build whatever it is, which is a combination of having our teams working with our client teams kind of this hybrid model as well as actually building the thing they're paying us to build. So it's a super fun job. I get to work primarily with large enterprise but, more special to my heart, public sector, like schools and state governments and things like that, where I get the delight of seeing what me and my team get to build gets used by millions of citizens all around the state or municipality that they're in, which is it's awesome. I love it. So there's my brief intro.

Alex Perkins: 2:35

Awesome, thank you, and I'm sure that has plenty of its own challenges that we'll get into throughout the episode as well. All right, so yeah, like I mentioned. So this is really going to be. We're going to try to tie it into kind of a network centric engineering mindset thing for platform teams, and I think really obviously the best place to start is what is platform engineering and why should network engineers care?

Chris Wahl: 2:57

Yeah, the way I like to put platform engineering is it's everything that you need to put together to ensure a high quality experience for those building whatever your product may be.

Chris Wahl: 3:06

So those product teams need to be able to think of something, build a prototype of it, test and see how it works within a larger system, get feedback very quickly and actually very short bursts of feedback, too right.

Chris Wahl: 3:17

We don't want to vomit information all over them and then make it so that they really are able to drive velocity within their product all the way up to deploying code into production multiple times a day.

Chris Wahl: 3:28

That's really the goal. How do we make that as seamless and as easy and transparent and invisible to those building the product as possible and do it in such a way that is scalable and reliable and performant and all those things that we put under well-architected designs, and so really it's taking that and put under well-architected designs and so really it's taking that and then pulling from a lot of different skills. So we take the cloud folks that were siloed and the network folks that were siloed and all these other sort of specialty units that are not necessarily needing to be in a silo. We put them on a team and we go. You are the builders of things, you are the makers of tools and you will do those things as a team and you will work with others as they build their things on top of your platform. So that's probably the way I would articulate it, just off the cuff.

Alex Perkins: 4:11

That was great. That was great. And yeah, silos I think we've all had plenty of experience with dealing with silos in various places. I will call out real quick you released. From the time I first approached you about this episode, you had released another blog post about platform engineering and you kind of likened them to like vending machines, which I thought was a really cool analogy. So we'll add that. We'll add all your blog links to the show notes, but I thought that was a really great analogy for what you're creating as well was a really great analogy for what you're creating as well.

Tim McConnaughy: 4:45

So can I ask, because I'm not as up on platform engineering as Alex is? When I was an enterprise network engineer, I worked really closely with our DevOps team and we had a DevOps team at the time right In the enterprise that I worked and is the idea of platform engineering about like silo busting and getting all of the different stacks together and then trying to figure out, like from a governance perspective, like who works on what, or just elaborate on that a little bit?

Chris Wahl: 5:13

for me, if you would.

Chris Wahl: 5:14

I think the root of platform engineering is actually a step or two back from that.

Chris Wahl: 5:20

It's saying the way that we build our org chart and structure ourselves as humans has a direct and meaningful impact on the way that we build products, and there's this chart that I wrote out that kind of has a product on top of a platform and the sandwich in the middle are the people that build it.

Chris Wahl: 5:39

So it's how do we put ourselves together in such a way that not only we have the right skill sets to do what we need to do because skill sets are pretty transferable, we're pretty spry individuals as former sysadmins and whatnot but more, how do we connect information flows such that you can drive consistency across a great quantity of scale and do it in such a way that everyone can kind of subscribe to that in as easily digestible method as possible, right, and the way that you do that is you structure your people in a way that make that advantageous, and you structure your information flows in a way that make that advantageous.

Chris Wahl: 6:18

The thing that I would like to call out here, though, is that platform engineering is not anything new. It doesn't really invent anything from scratch. It just says if we organize this way and we focus on consistency, using this pillar architecture, we can build kind of anything we want and we can make it very self-service and we don't have to be beholden to abstracting a lot of that way to a third party. We can actually own a lot of that and drive value into the system, not just seen as this thing that you pay a bill on every month.

Tim McConnaughy: 6:46

I've heard the, you've heard the term, I'm sure shipping your org chart. So is that is platform engineering, a focus on kind of leaning into that or leaning far away from that idea of like shipping your org chart as a product?

Chris Wahl: 6:59

I'll give you an example where we did this recently Very traditional operational model where we have IT and it's got the database administrators and the network engineers and the security team, and communication was not the best. There was definitely some friction there, right, because they were organized in such a way that friction was very advantageous. And so what we did was we said, okay, we're going to use the Strangler model on this. We're not going to try to completely convert everything in one day. We're going to build you a platform team and structure it with the right folks with the right skill sets and the right team structure and charter, such that they're going to start pulling in all these different application teams and domain teams and solution architects and people that own solutions and things like that, such that we start having this more broader vision of the architecture we're looking to build.

Chris Wahl: 7:48

And when you do it through that exercise of putting the people in that format, all of a sudden it's a flood of inconsistencies come rushing to you. It's like, oh my gosh, there are so many different variations of a thing that exist and so many ways that we can optimize this that it's almost like where do we start? And so we went through this process. We built this team early last year and by the end of it they're shipping product every single day. They're able to articulate what they're looking to do, the patterns they're looking to build, the modules that they're constructing to the greater organization, and they're just consuming this, whereas a year ago it was all hand-built, largely on-prem. So you would absolutely take very raw and very sort of feels, unrelated type skills, transfer them into a platform team, build out that proper organizational structure and magic happens and I've seen it a couple of times already.

Alex Perkins: 8:40

So in those cases, are you bringing in people to do that stuff or are you more transforming, if you will, the people that are already in place and getting them to kind of build that platform team on their own? Oh, we're keeping them in place.

Chris Wahl: 8:55

I mean, I don't ever want to be the Grim Reaper. Like, hi, I'm here to just fire all of you Like that's a losing strategy and it's a stupid strategy because those people have value. It's very transferable.

Chris Wahl: 9:07

I don't think a lot of people agree, but that's because it's hard to understand it. So you've lived in both worlds and I've certainly grew it up in the on-prem Cisco, router, vmware, blah, blah, blah world. To now everything's serverless, everything's cloud, and so I understand what they're going through and what that experience is like. I'm like oh, actually you can do this, because that's the number one thing that comes up when I work with people looking to do this sort of platform work. I don't think I can. I don't know how to do that. That looks cool, I like it, I want some of that, but I feel like I'm banging a rock on a piece of iron and you're showing me a lightsaber and it's just like so out of my realm. So the process is to take small chunks, and that's where I was writing about the layers of building a platform, this kind of three-layer approach and how you start, and I actually have a whole post dissecting exactly how I built the last few platforms and I think it's a recipe that works pretty well.

Chris Miles: 9:59

Yeah, one thing that I can think of, like, if we're thinking about this concept of building a platform team and you, you know, you said bringing in people with you know kind of diverse skill sets to to address each, each kind of vertical that they may need to, um may need to assist with their how, how are platform teams typically handling ownership in that capacity? Like, let's say, you do build a platform team where everyone is from a diverse background One's dealing with end systems, one's dealing with networking, one's dealing with storage, etc. Right, how does ownership transfer across that?

Chris Wahl: 10:32

as far as you know, from a delivery perspective as well as an ongoing support perspective, Let me start by talking about the rhythms that you build, because I think of teams have rhythms and rhythms are repeatable and you can feel them and you can feel when they're right or when they're wrong. So we think in terms of rhythms, rhythms align very well to sprints and so you build all of the interlocks necessary to do an internal design review every sprint, a intake process where your domains and application teams come with their requirements for the next two running sprints. You build the machine through your rhythms such that you're forcing those interlocks to those teams. The people that you need to be working with are included, because that's a piece of your puzzle.

Chris Wahl: 11:18

As far as the other side of it, the demarcation a lot of that is, you can mask that. For an example, if you're running a GitLab organization, you can put all the core stuff in completely in a closet. No one else sees it, and then I'll be your application stuff more front and center. But I think, more importantly, where you're going to meet friction are three places. One, anything that's shared from a project perspective, because developers love to build shared projects with tools in it. By the way, don't let them try to get rid of those Monorepos of any sort right, because there you're automatically admitting there's no true owner right. It's this sort of amalgamation, and whether it's your monorepo or a developer's monorepo matters. And then I think, thirdly, more in the code, and that's where a thing like a code owner's file can be that contract that you build with your dev teams to say this is how we're going to delineate who sort of owns and drives the pull request.

Alex Perkins: 12:08

Okay, before we move on, I just want to linger on something here, because you mentioned that you do a lot of public sector space. So what are some of the challenges I guess that you come across, because I know a lot of these places? Change management is like really strict, or they have, or they don't have any of these workflows already in place, like you were mentioning sprints and like the whole agile methodologies and stuff like that. So how do you, how do you start overcoming those barriers? Right Cause I guess that would be really the first part of trying to build out this platform team.

Chris Wahl: 12:40

A couple of good ways that I recommend. A trick that works well for me is architecture decision records, or ADRs. They're a great way to. So you're trying to break a number of bad habits right. One is the siloing information. Two is lack of architecture in general. Three is documentation. Solve all those problems with the same thing right. Build architecture decision records that say, for our landing zone, how do we want to do IP address management? What is that going to look like? What is our decision around this piece of architecture?

Chris Wahl: 13:07

It's a communal document, so anybody can contribute or have an opinion it doesn't matter who you are or what your title is and at the end of it it's either accepted, rejected. It has a lifecycle that goes with it and can be versioned. And so starting there at least gets the chaos to calm down and everybody agrees that, maybe not on the solution, but at least what the problem is right. You know, if nobody agrees on the problem, like you got worse, worse issues to solve. But you're getting to the point where people agree on the problem and then you're walking them towards solutions and then it's just a matter of ID, a prototype, scale it, abstract it. Yeah, you just kind of do the rinse and repeat.

Chris Miles: 13:43

How, how, how diverse typically is that portfolio of those architectures? Like I hear that and I'm like you know, I can think of a few organizations that I know of that would probably spend months on end just putting together every corner case or every little minute detail into an architecture design. So how diverse typically is that portfolio and how long does it take to build?

Chris Wahl: 14:06

it.

Chris Wahl: 14:07

There's the bootstrap phase where you you know you already have kind of a good idea of the basics the landing zones and security, and what's your CICD going to look like, what's your release process the sort of normal stuff.

Chris Wahl: 14:19

The beauty of it is that after that it's really a pain detector because you allow anyone to build an ADR or to propose an ADR to be constructed. To build an ADR or to propose an ADR to be constructed, you're bringing them up routinely in your intake process so that the interlock between the other teams are aware of kind of where that is and they are using them too. Right, you got allies that are also like why, why not? Why would they not have agreement on architecture? Like nobody's going to be able to really successfully push back on the idea, especially if you're already doing it, and they just can subscribe to it. But the end result is that because you have this very open culture of hey, anybody can have an idea and it's either accepted or rejected, we'll refine it until it gets to that point vastly accelerates the amount of input that you can take as a team and it's going to give you clarity and direct feedback loops with the people feeling the pain. Right and I think that's really important for the, for the ADRs you mentioned.

Tim McConnaughy: 15:13

Like, anybody can have an idea and you know, collaboratively we're supposed to come up with a plan or whatever that ADR is supposed to look like with that finished product is. Is there a? Is there a? Is there an owner? That, or an owner or a leader that like if, if there's consensus, comes in and cuts that Gordian knot or what does that look like? How do you get to that ADR being a finished product?

Chris Wahl: 15:39

So typically, you're going to get just sort of the problem. You're not going to get a whole lot of the architecture. It's just like hey, this is a pain Whenever we're trying to figure out this particular issue with a pull request. Blah, blah, blah, something's happening right. They're like this is the problem. Then the fun part begins, because you've got someone that owns architecture on the platform side of things, or a COE that owns it, and you have similar counterparts on the people that are building the application. Right, they're going to have engineers and architects and things like that. And so then it's like ding, ding, ding. Hey guys, found pain. I want all of you to join.

Chris Wahl: 16:14

Typically, what you're going to do is like a design review or a brainstorm or something like that, One of the patterns that you use to ideate across your teams. And then it's what do we think about this? Where do we take it? Right? But it's more about being a collection basket of good ideas or maybe bad ones that you're like oh, now we know that's a bad idea and you can actually mark that as rejected ADR to save it for later. It allows you to cast that wider net, and what you're also going to see is like you're going to get a ton of them in the beginning, Like you alluded to that, I think, earlier, Chris. That would be like a lot, and then they're going to start to trickle right, Because you shouldn't really. It's either going to be a version update, because your architecture is just woefully out of date that it needs a rev, or it's some new thing, because a new domain got spun online or a new service got spun online and you haven't handled that yet. But it should be pretty minimal.

Chris Miles: 17:00

I think that sounds good. Yeah, like I didn't. I didn't grasp that concept. Technology domain would be proposing the architectures you know per per domain, so that that makes a lot more sense and scalability of it. Yeah.

Chris Wahl: 17:13

Yeah, and especially with the domain driven design right, where you're building those bounded contexts, you're building those language models so that you can have common language between your teams, just so you're not calling a spade a spade when it's actually a heart, right. So all of that connects, all of that bridges back together to proper, or at least very, very high velocity ways to build software. I'll say that instead.

Alex Perkins: 17:34

Well, and also I think, just to call this out real quick, you mentioned in your blog post about how there's like different phases of building this platform as well. So how much do you really need for like a prototype phase, right, like there's? You're going to have a lot of these coming in, but you might not just you don't need as much to just get started and you'll add more as you go, right.

Chris Wahl: 17:55

Yeah, yeah, getting started, probably the, the, the bulk of it. I remember we were like two or three weeks in and they're like man a lot of.

Chris Wahl: 18:01

ADRs to deal with. I'm like I know I know it'll, it'll calm down, but we have to build. Like you know, the landing zone is not a trivial thing. That takes 10 or 12 ADRs just alone because there's big chunks and then you get it right. So there's a lot to it and I will say, kind of bridging it back to networking in general, the bulk of the architecture is the network.

Chris Miles: 18:20

There's lots and lots and lots of networking.

Chris Wahl: 18:23

So I hope people the application's kind of the easy part right, so it's all the networking that goes around it. That's the challenge right, so it's all the networking that goes around it.

Tim McConnaughy: 18:31

that's, uh, the challenge and that and anything I am and like. So, um, networking, the hierarchy, if you will, of networking has traditionally been very, uh, well, it's been very hierarchical, right, like we, I'm sure we've all have stories of the uh, you know, the network architect up in his ivory tower handing down, you know, uh, the stone tablets uh, to the rest of the network team. So this idea of being able to essentially crowdsource the creation of architecture decisions is very fascinating to me. But I know many network architects, that very traditional network architects that were kind of my way, or the highway types that would have to find a different way to do their business, if you will, within this framework and I'm all for it, by the way, I'm very, very much for it, right, but it definitely would be a challenge the way networks have been traditionally run, which is very, you know, top-centric, filtered down, if you will.

Chris Wahl: 19:26

And that's not any different from what I find. I think that's I make it my mission to make that safe and okay and normal, and I just do it over and over and over again until it becomes like why aren't you doing it? You know like there's, there's really. It's just you sort of weave it into the tapestry of the culture, that space and assuming like I guess everybody's different. But I haven't run into a stubborn mule yet. Networking or security or otherwise, that didn't see. Like you know, this works pretty well. Yeah, it does. All right, how do I use it? I'm glad. Welcome to the club.

Alex Perkins: 20:00

Let me teach you.

Chris Wahl: 20:01

Right and figured it out.

Chris Wahl: 20:03

That's the best. Because now you're taking like security is a great example of this. You're taking someone that's typically having to come in and sort of after the fact check on the work to see if it was done correctly and scan it, and they're just like always sort of on, they're so far to the right in the process. It's just gross. And when you push them far left and there's actually a decrease in velocity for a while, because they're like I don't know what I should be doing. And what I found is like, hey, let me show you all these security things that you know, these dashboards and reports and how they all work, and frameworks and Salsa and SysBranchmarks and all these things. And I'm like let's start thinking about how this applies to the platform, because guess what? We have a magic machine here that just makes infrastructure. We can print it, you know, in the blink of an eye. And if you want something changed, we can just do that. And that's not typically the experience they have, but they tend to say I like this better. Yeah, duh.

Chris Miles: 21:03

It's more fun. I don't want to derail us too much here, but I am curious to get your take and I think we actually might even looking to do a an episode on this later on. But are you seeing, in your experience, teams building multi-cloud platform teams and, and if so, what are the like? How is how is that spread happen right? Or do you do you see domain specific people, just specific, or domain specific uh teams for specific clouds, or are you actually seeing true teams that are spread across multiple CSP environments?

Chris Wahl: 21:34

Most I'll say most of the clients I work with. They all have. They all have a footprint in all the clouds and, for the most typical reasons, identity at Microsoft and workload stuff and AWS and apps in Google, something like that, or docs, right, so like that's the. That's the typical trifecta and if you're in that boat where you kind of have the lion's share of your platform stuff in AWS, I don't really encounter a lot of folks that find value from diversifying. They do find value from having a center of excellence. I very strongly recommend open to the public centers of excellence where it's just discussing the state of the art and staying in touch horizontally across teams. So that would be a great place to have that conversation as well. But yeah, that's that's. That's been my experience and I think it. I think it lends itself well to a team that's able to take advantage of it.

Alex Perkins: 22:23

In one of your posts. So so this kind of ties into the security talk that we were just having. You mentioned quality engineers need to be heavily involved. I guess my question is what does this look like? And I'm going to kind of tie two ideas in this blog together. You mentioned it lends itself very well to having seniors kind of mentor juniors as well. Is that like? Is it literally just anyone can be a quality engineer? Is it like specific people? No, no, no, okay, yeah.

Chris Wahl: 22:56

Let me tell you the story of quality engineering. Yes, so in the world that I live in, there's no such thing as QA. That's kind of a non thing. It's all quality engineering and the idea behind it is, if we take a very seasoned and experienced and typically the more senior developer and we put those on a team maybe two of these quality engineers, two developers, one architect, one person to sort of own the team and the six person team, something like that so you put something like that together. What you end up doing is you take all the quality elements of building software and you make that responsibility a shared thing across the developers and the quality engineers, but you give them different roles.

Chris Wahl: 23:47

Quality engineers are looking at the story from the moment it's kind of the concept hits are the one that controls the button of merging the code into the main branch, right, they're the one that goes to the checks. So it's just a way to monopolize on the fact that there's this very short window of time between when a developer has made something and when they've committed it and flush it out of their RAM in their head. And if you can get the quality work done in that sweet spot, it's easy, it's incredibly easy, you know like it's just mind-blowingly easy. So what I did was said well, I like that idea. Let me borrow that for platform Because I think I don't know, I feel like we're all kind of old infrastructure horses and we like to cowboy a little bit and that's not great for quality and and I suffer that sometimes don't like it's, you know, it's dev, whatever, and it's like ah, a lot of people did not like that. I pushed that button, uh, and so we just took that same principle and said what if we took our more senior cloud devops platform what have you people? And pair them with either a client that's new to this stuff or an internal you know engineers do this stuff and give them kind of that same mandate.

Chris Wahl: 24:51

Think about the quality of what we're trying to build the infrastructure to do, how it gets its inputs, how it processes those inputs, where they go. Are they secure, like? Really think about how this architecture is impacted and what tests you might want to write to have the pipeline do or to have a little app do or your SDK do all those kinds of things. And what we noticed was if velocity before was like 10 units of velocity once we implemented quality engineering as a platform team and gave it a few sprints to run through. We were doing 30 units of velocity, so we tripled our speed by making quality just this thing where we took advantage of the sweet spot. We knew the change. We introduced the quality right then and there and we got that same result. So ever since then I'm a huge believer.

Tim McConnaughy: 25:36

One thing that's really hard, though, from a quality perspective. Speaking specifically of network, even in the cloud, where your cloud network is completely ephemeral, you find that it's still not as ephemeral as dev would be. You can't build a whole other cloud network with apps to test on. You're still doing thoughts and prayers a little bit. You still can't get that true quality testing framework that you can get with an application.

Chris Wahl: 26:09

Yeah, I'll say I kind of put those into two buckets. There's the buckets of sort of things I don't care about, like a transit gateway. I don't really need a dev version of that, I'll just control traffic myself. So, like that, I'm willing to give up on that. But white flag fine, I have one of them. I hope Amazon knows what they're doing and I just trust. But for all the other stuff, there's a lot of effort that a good platform team puts into building those ephemeral environment, sandboxes, testbeds, whatever flavor you want to call that and I'll say that that's where you invest that energy into true ephemeralism as much as you can. I think IP address management is probably the place where I suffer the most pain in AWS because it really likes to hold onto pools forever. But for everything else it's pretty much like you can set it on fire. You can get a new one in a few minutes, right. So focus there, and that's where you're going to get a lot of ROI from that network automation and ephemeralism.

Alex Perkins: 27:02

Okay, there's one thing that I had to push back on just a little bit, or call out from your article that you wrote, oh good, about the rule of one layer of abstraction. And I bring this up because in networking, right, we're so used to overlays on overlays, on overlays on overlays. So how do you reconcile that? Obviously, sometimes there are exceptions, right, of course.

Chris Wahl: 27:35

But I just I wonder how you reconcile that. So I also state somewhere else in there that when you exceed one abstraction, you built a product. Yes, and the general allergy that I have is building products. I don't mind building products, but each one of them is just an infinite drain on my resources that are very finite and very scarce. So I'm always hesitant to think, okay, do I really want to abstract the abstraction? What do I get out of this product? Who's going to own it? How is it going to work?

Chris Wahl: 27:55

And typically the math doesn't work out very well. It's just going to be operationally more effective and typically even more secure to just take the bare bones of things and connect them to one another and really make sure that the pipeline that's doing the things in the infrastructure, the vending machines, as we talked about earlier, are managing that flow, because you'll just find like man when you're like oh man, look at this script. It does all the things, it runs and it slices and it dices, and then you get the junior. Engineering is like I don't know what the heck this thing does, we're screwed, and that's just very common, very, very common. So I like keep it real simple, make it really basic. Put it together using your automation and your pipelines. Let it do the heavy lifting. Don't try to make some Rube Goldberg machine. And that's where I'm trying to say like be very mindful when you exceed the one abstraction layer theory.

Tim McConnaughy: 28:46

We kind of have that in network engineering too. I refer to Rube Goldberg. More often than not this idea of building N plus 12 layers of redundancy into any network ends up being like an extremely complex machine that when it breaks, it's going to take you longer to figure out what broke than to just let it break and then fix it in the first place. So I like that.

Chris Wahl: 29:09

Yeah, I'm also enjoying the luxury of working in a very API serverless container, even clustered ephemeral database type of world. It's built for this right. So a lot of my work is taking people that are trying to apply the old models to this, which is just expensive and doesn't get them anything, and say look, we can actually do this extremely cheap and way easier If you just let go do it, do it like this and that's that's typically that, that transition that we're, that we're looking for Right Move to this new model.

Alex Perkins: 29:41

Okay. So yeah, we are running a little short on time, so I'm going to try to squeeze in one more point here. I think we'd love to have you back for a part two because there's a lot of stuff here that we could continue to unpack.

Chris Wahl: 29:55

I talk too much, don't I? No?

Alex Perkins: 29:58

No, not at all. No, this is all very new to network engineering, I think. So right, a lot of us, like Tim said, I've looked into a lot of this stuff, but I know a lot of network engineers don't even know the first thing about platform engineering, right? So that's really why we wanted to do this episode.

Tim McConnaughy: 30:14

Just to introduce it, yeah.

Alex Perkins: 30:15

Yeah, exactly. So the last point is you write about collaborative generalists. Are the people you want building platforms, and I guess, to tie this back into completely, back into network engineering, is how do network engineers start expanding their knowledge to become those collaborative generalists? Right, because it's. We already learned so much stuff across networking and all the different domains that we need to know. So how do you also, on top of that, be like now you got to do security, now you got to learn all this other stuff, like, do you have any advice or tips there?

Chris Wahl: 30:45

You know it's not a it's not a question that I get asked often, but I think it's a good one. And where I would start is, like with any good thing, find the map right. So, within your world, what does the map look like? It's not so much that you understand how to configure the security thing and what it specifically needs to be installed, as that's not that important. It's more a general of like, hey, if you were to build a landing zone and a network design and use a transit gateway or whatever, where would you put your firewall? Why would you put it there? How would you secure it and build rules for it, and where might things go? How do you make sure that dev can't talk to tests?

Chris Wahl: 31:22

Think more of where does network play in the platform and then dive into those components, but understanding how it's all architected to work together. I mean, you have such a leg up if you understand the basics of networking, and most network engineers, like know a lot more than that, except now you're not working with, like routing protocols so much as you are. Oh, I'm going to write a little bit of. You know, yaml or, or, or Terraform code or whatever, to build a thing or work with a DevOps engineer and they'll build the thing and we'll get it all configured the way I want and what do I want this world to look like? And I think what we want this world to look like is a much better question than go into your little silo and network things you know like. That's way less interesting to me.

Alex Perkins: 32:03

Yeah, that's a great like Tim for you. I mean this harkens back to. You've been talking about this for the last couple months. A lot is systems right like taking that that overlook. So, um, do you want to provide any any last thoughts here before we wrap up on on that?

Tim McConnaughy: 32:18

part, he's absolutely correct. I mean, um, if you, I mean you know kind of t-shaped, right, we tend to be kind of t-shaped. We get really, really good at one thing and then we kind of like spread to the sides, that's generally what people should be doing, right? So network engineers that have spent a lot of time becoming CCIEs or whatever the experts of their domain you know you're only going to benefit and, like you said, I've been saying this forever right, you're only going to benefit by reaching out left and right and seeing how applications are built, how the systems are built, because you got to know what they're doing, to know how to network them together, right? So, yeah, I mean absolutely, I completely agree. Yeah, I think I think it's tough.

Chris Miles: 32:57

I think that's the easy part. That's the easy part is to reach out to your counterparts and and try to figure out how they're you know how things work in their world. Like if you're, if you're a network person, you're're probably reaching. You have a, you know, a DevOps team, um, or something related. You can reach out and see how how that world works and how you could potentially contribute to that. But I think one thing that's difficult is is advertising to the stakeholders why you benefit from this kind of unified system that you get with with a platform team, right, um. So that's that's. That's that's the hard part, I guess. Last bit, I would ask you, chris how are you seeing, how would you see individual contributors, you know, kind of pushing leadership to adopt that kind of model and leverage their expertise within the relevant domain?

Chris Wahl: 33:43

I mean money talks and in this case, when I talked to CFOs and CTOs, cios, I'm like we're going to slash your budget. It's not going to cost nearly as much to run it in this more modern, efficient model. Um, you can point to the dora uh, you know state of devops report. It goes like this was the first year where documentation scored on a critical matter like that's like number five on the list. Now it's crazy, uh. And they also go into things like AI and what, and you know, like the winning three things that actually impact velocity for teams, flexible infrastructure, loosely coupled architecture, speedy code reviews. Those are the things you optimize for if you want to go fast, and the way that you do that is you build teams like this you have to drive consistency, because consistency builds trust and trust builds products right. So that's kind of the sell and and it's going to be way cheaper because you're probably doing it wrong in the cloud today or you're doing it something non-optimal.

Alex Perkins: 34:35

I'm either going to make it cheaper or faster or both. That's really great Cause that's almost like a definition of of what platform engineering is Right. Um, so I love it All. Right, Chris, is there any last thoughts you want to leave us with? Or, before we go, where can we find you? Is there going to be more blogs? I hope so, personally.

Chris Wahl: 34:56

Yeah, you can find me on wallnetworkcom. I blog very randomly. It's certainly, I think it's like 14 years old now. That's pretty crazy, but you can find me there. Otherwise, that's pretty much it. I don't have any other social media.

Chris Miles: 35:10

You can. You can direct people to go back and listen to the backlog of data knots episodes that are out there in the world somewhere. We probably started talking about this stuff very early on, right?

Chris Wahl: 35:20

I'll post a post to this, to this recording, when it comes out.

Alex Perkins: 35:23

So it'll be on there too. Part of the log. Appreciate it yeah.

Chris Miles: 35:28

Yeah.

Alex Perkins: 35:29

All right, Awesome. Well, thanks for coming on, Chris. We're going to go ahead and wrap up this episode. So if you like what you heard, you know, hit all the buttons like subscribe, follow across all all the platforms that we're on and, yeah, we'll catch you next time. Thanks, Hi everyone. It's Alex and this has been the Cables to Clouds podcast. Thanks for tuning in today. If you enjoyed our show, please subscribe to us in your favorite podcatcher, as well as subscribe and turn on notifications for our YouTube channel to be notified of all of our new episodes. Follow us on socials at Cables to Clouds. You could also visit our website for all of the show notes at CablesToCloudscom. Thanks again for listening and see you next time.