45. The Network is Finally the Application – Tech Field Day Podcast

Is it true? Is the network finally the application? And what does it mean that the network is the application in a complex, hybrid and multi-cloud world?

Do we even know what's happening on our network that isn't now our application? Tune in and find out on the Tech Field Day podcast. Welcome to the Tech Field Day podcast, where we bring together a group of IT technical experts to discuss a single idea about key concepts in the industry.

This podcast features a variety of perspectives from members of the Tech Field Day delegate community, and is often recorded in association with one of our events. This event is Cloud Field Day Tech. Field Day is part of the Futurum group, and this podcast is also published on our sister companys site Techstrong tv.

On this episode, as we head into cloud field day, we'll be discussing how the network is finally the application. But before the discussion, let's meet who's on the panel. Hi everybody.

My name's John Meyer. I'm a technical host podcaster of the John Meyer podcast, video media content creator and founder of Meyer Media. Hey everybody, my name is Michael Lavan.

I am a fractional engineer slash CTO and live trainer. I'm a Microsoft Azure, MVP, and I focus on everything around hybrid cloud app modernization and scalability. Hi everybody, this is Larry Smith.

I am an automation consultant that is, uh, not very active on any social media, um, but uh, I'm sure you can find me on LinkedIn, places like that. Um, but glad to be here. And I'm Alistair Cook.

I'm an event lead here at Tick Field Day, which is a part of the Futurum group. What we really are, are seeing, uh, is applications spread all over the place. This is what we started to see with cloud, with this combination of infrastructure as a service, platforms as a service, software as a service being popping up and being integrated into our enterprise applications over the last 5, 10, 15 years.

And it really seems like we're starting to deliver some of the, the promises that networking was the way we were going to deliver applications, that it wasn't all going to be about putting an application on the endpoint device and synchronizing data down to that endpoint device. I know we had that for a little while, but now we're accessing almost every application through a web browser or through a, an application that actually is just a web browser anyway, because everything's being managed on the, on the top end. And so the network is, is the, the application is how we get our access to our applications and, and our data, which was a promise from a while ago.

But it seems like there's still an awful lot of complexity around this and that we are still finding all of the implications of accessing everything across the network. And John, are you seeing this as being a big challenge for organizations that you're working with? When I look at the network, and when you think of a trend, traditional type of network where it was just, you know, hard wiring things together and configuring it on premise and getting things to connect, now you're in the cloud and one of the biggest things is everything is just virtual.

You're not actually physically connecting things together. You are actually coding things together, which brings a new challenge in order for it to communicate, but also for everybody to access not only the cloud information, but your on-premise information leading you to a very complex environment and hybrid all over. Yeah.

So, uh, something interesting that I'm working on right now is I have this Intel Nook 13 Pro and, uh, I'm testing this out for a client that's doing some edge based stuff. And the goal is they want to be able to run some Azure Kubernetes service clusters, uh, based on where they are in the world. And the really cool thing is, so you implement something like Azure Local, which it used to be called Azure Stack, HCI, and the gist is from the Azure portal.

Like I can go and I can deploy an a KS cluster or something like that, but what I could do is I can also just go to the portal and deploy an a KS cluster like I would, except it's on my desk at home. Uh, so it's, it, it's very, very interesting to see the whole idea around hybrid cloud being this like, oh, now you have one entity to manage everything, both from an on-prem perspective and from a, um, public cloud perspective. And then obviously there's also the pieces of like multi-cloud in there, which the two drastically different concepts, but the end state is, is more or less the same.

I want to hit on something, John, I think John, what you were talking about is around code being able to manage these things in code and, and these hybrid environments. Everybody's doing Terraform, right? Let's talk to Ned.

Not to drop Ned's name in here, but hey, but you know, some of the things that we're seeing, you know, as far as like day in, day out that I deal with clients is that how do we manage this stuff, you know, holistically across these environments? You know, everybody's like, oh, we do on-prem, but then when we get into public cloud, isn't it the same? The reality is it's easier in cloud, right?

We know that even from obviously from a networking perspective is, you know, bringing in like a holistic approach. Um, again, dropping Terraform, some of the other tools, Ansible, whatever, but being able to apply those same principles on-premise is pretty complex. I know, Michael, you mentioned Kubernetes.

When we start talking about, let's talk about OpenShift, how do we get these things, you know, kind of stitched together? Um, and things could start breaking down really quick. So John, hate to piggyback on that, but I think that's a pretty important piece Actually, that's really important that you're adding onto it because I love that you added in Terraform there, right?

There's a whole bunch of other languages that we could utilize, but now you have the cloud where you're, you're just coding it and you can code on-prem, right? You could do a subset of everything on-prem and deploy it out to it. Uh, all the cloud providers have something of an on-prem nature.

Michael mentioned it, you know, you could do the nook, which now you have your own it at home. Your you're selling services and nobody knows it. It's somebody else's computer, let's just say.

Right? Well, now you need to take that code and you need to manage it not only within the cloud, but can I do the same thing on-prem? No, it's just, oh, now I'm actually physically doing something or now I'm coding something.

So Larry, you touch on it, it brings a complex nature to it, And that's a, I I think that discontinuity between cloud and on-prem is often talked about a lot that we used completely different philosophies, how we built things on premises historically versus how things are built in cloud. But I think there's also an element of the, the reality for a lot of organizations is, is not just hybrid cloud, but it's also multiple clouds that they're needing to glue together the disparity between maybe, um, you know, Azure Kubernetes service for some elements of the business, but maybe some other Kubernetes based applications are running on the Google Kubernetes engine and, and maybe anthos on premises for some, you know, if you're a global company, these decisions may be made in a decentralized way so that one region uses one piece of technology and another region uses another piece of technology. And yet as the the infrastructure team, we've gotta glue these things together and make them operate together.

And so those disparities can be really difficult and, uh, tools like Terraform are, are cross platform. But do you end up with the same capabilities on the different platforms? Is it just that you're using the same domain specific language that, that terraform, uh, uh, manifests to, to describe things, but within it you've actually got a different dialect for each of the the things that you're targeting that leads to more complexity and more uncertainty?

No, I was just gonna say, I think that's kind of what makes it so fun, because at the end of the day, like the, the 50 foot view, everything's an API endpoint, right? So whether you're using an SDK, uh, whether you're using something like, like an infrastructure language like Terraform, everything's an SDK, it's just a matter of what library framework packages you're using. Uh, it makes it a lot of fun because you can kind of design it in the same sense of like, okay, we're gonna use Python for this, right?

But you still have to change out libraries frameworks and such, but at least you kind of have an idea of like, okay, if we're multi-cloud or if we're hybrid cloud, we're gonna hit these API endpoints. These are the things we're gonna use, this are the things we're gonna build architecture around. Uh, of course you gotta dive into it, into the, uh, the interaction points are always gonna be different, but the fact that you can just look at everything as, oh, this is, you know, a bunch of API endpoints, let's build and design for this.

It's, uh, it's, it's quite lovely. That's another important Piece is it sounds like, I would say Michael sounds like an executive saying, Hey, this is easy, right? Why can't we do this?

You know, again, you know, we, we know how this goes. But you know, I think it's, you know, that, that important piece is, um, because of the hybrid nature, because we've got multi-cloud, we've got Azure, AWS, Google, um, you name it, VMware environments on-prem, OpenShift environments, everything like that. And again, going back to how do we standardize on a way, so we, you know, working with clients, we're looking at things like patterns.

We understand those patterns, like things deploy in a certain way. I mean, at the end of the day, what do we care about a service is how do we stitch all that stuff together? Hey, we're an app team and we do everything in AWS, awesome, we're good to go.

But we break down when we get into, hey, this also needs to go on-prem because part of the, the, the organization wants to keep things on prem for certain elements. Um, and again, it goes back to, like we said, it doesn't always work that easy. Public cloud specifically around networking has made things really simple.

I know I work with clients that are using NSX, um, you know, from an SDN perspective, Cisco, a CIF five, you know, you name it, it's all a little bit different. So Alistair, Larry, you guys touched on multi-cloud, obviously we said how much we love all this networking and the capability stitching them all together. Just think about it, the different languages, the different variations, the different understanding of each one and the different ways it can communicate.

So bringing all this data just actually to visualize to the end customer has gotten more complex, even though it's an application when it was on premise, right? You knew that you were opening up port 80 for this web interface. It worked out it great, it communicated if you couldn't ping the gateway, you had an issue on the server.

Now try to figure it out between the various gateways, the VPNs, and between all the different cloud providers in order to communicate, to pull the data back from on-prem into the cloud to present it to the end customer. I mean, it's an application, but it's complex. Well, John, I'm gonna pile on because I feel like Michael's going to as well, and I want to get a head start because, you know, again, a minute ago we were talking about something, and I wanted to go here, but you just brought it back in, is the observability piece, right?

Is being able to understand, you know, again, I mentioned earlier like, things I work on are all over the place, like most of us. But again, automation and, and being able to deploy things and being able to get into observability, like how do we stitch things from an observability perspective and be able to get that visibility all the way down into a on-prem or b in a public cloud. And again, from that service level all the way down is extremely difficult.

I know we've probably spent, I can say examples of a year plus of just what does this thing look like and how do you visually see all the components? So Yeah, it's, it, it's interesting because in some, in some spots it's so much easier and in other spots it's so much harder. Like what I was saying before about everything is an API endpoint.

I mean, that is like, I, like I started out my career like on-prem and then in virtualization, and that was not all API endpoints. I mean, I think we got lucky at some point, and ESXI had a PowerShell module, uh, and we were able to do some programmatic stuff that way, but e everything was very like manual. It felt very manual now, yeah, I mean, I can, I can write any piece of code in, in just about any language to do just about anything in any cloud.

Um, and I can piecemeal it, but then at the same time, to you guys' point, there's just so much of it happening at once that it's very difficult to keep track of it in comparison to, you know, 12, 13 years ago when I would, you know, I, I go back to this one night where we had like an 18 hour data center migration and I was sleeping on a data center floor, but like that, it was just, now looking back, that piece of here, everything is here, it was so much easier than it is now. Uh, so there's, I mean, I guess it's everything in life, right? There's, uh, there's some pieces that get real easy and then there are some pieces that it's like, oh, this actually harder.

So makes sense. Yeah. But the observability piece, like, so funny enough, even, um, with, uh, with, with, with Catchpoint, like we were talking about, they can look at everything externally, but then we still have to look at everything internally from an application perspective.

So we have multiple different, uh, logs, traces, metrics internally, and then we have to do the same thing outside if we're going hybrid cloud and multi-cloud. So there's, and the tools are there, the, the data is there, but it's, uh, it's far more difficult to manage and maintain nowadays than it was before. But don't worry, everybody, uh, AI is gonna take our jobs, so pretty soon we won't have to worry about any of it.

Thank God I'm ready to retire. I dunno about anybody else, but I'm glad you mentioned it because it wouldn't be anything without an AI conversation or wording. Well, I want to go back to something Michael, and again, not to go too far down this, because the premise of this was around the network being the app, which I think we're, we're hitting on pretty well.

But I, I think what you said is important of what I've seen as well is if you started looking at the way that folks generally programmatically program a network, let's look at it from that perspective. Um, it's usually started from individuals or teams or organizations that have started in public cloud, but then when they get into, Hey, we need to now be hybrid, um, a lot of those skills don't exist. Like you mentioned 12, 13 years ago that we were in data centers, and again, you know, obviously I've been around, uh, much longer than that.

But being in the actual data center and having that experience doesn't exist as, uh, in most of these organizations, Right? And, and the, the, the insane part about it is like, anytime I'm talking about Kubernetes and I get asked, oh, how do you, how do you know this piece? How do you then know that piece?

And I always tell people, 'cause my background is in systems administration and I moved to software development later. Once I picked up Kubernetes, I knew 80, 90% of it. So yeah, you're absolutely right.

Like, and those, those skills, like we don't, we don't start that way anymore. Like there was a time where we started in, in our careers where it was like, you're gonna be OnPrem or, or you're gonna be in virtual environments or whatever. Now it's like, Hey, you're starting at home and you're logging into this portal here and you're gonna hit this API and that's it.

And it's, it's a drastically different learning experience now for engineers just coming in than it was, uh, a, a long time ago. I've always said, and, and this is a thing coming back and I know we we're dating ourselves here, right? We all come from a data center.

I used to build rack and stack servers for a web hosting company, right? And we ran the cables and all that stuff. I really think there should be classes now that you do that, while some of us will never touch a physical server or install an OS running on a cd, oh, I'm sorry, uh, floppy or USV, however you want to run it and get it installed or we'll do a pixie boot onto it.

I think you should learn that aspect. Oh crap, I can't get to it. I mentioned you can't get to the gateway.

I think troubleshooting and understanding the whole aspect of a network configuration is essential then going to the cloud, because now you can visualize that there is a physical server, whether you touch it or not, you can in d os is there, you install it, you can configure it, you can see the routes, the route table set up a firewall, literally set up a full network lab for yourself and you'll be golden. Whether it's a cloud hybrid, what are on-premise environment, you all have a leg up on everybody. Now, I think one of the, the, the elements in, in that, John, is that all of the cloud platforms that we work with that are infrastructure as a service kind of platforms where we're building these networks, they're all just representation, software based representations of the physical stuff we built 10, 15, 20 years ago.

So I think, yeah, understanding the physical root of that virtualized, uh, element is, is a really important part for future skills. And yeah, I'm, I'm seeing, uh, a bit of a, a movement back to people actually building at home labs. Uh, I've been watching some of the Jeff Gilling videos recently about building 10 inch labs that are much more hospitable to the, the kind of places people are living these days than having full 42 year racks and three phase power as, uh, the, the most famous labs when I was starting out were, that was, uh, Scott Lowe's lab was, was famous for that one.

Uh, and yeah, times have changed and, uh, I think times changing is also one of those constants that we see in here. And I wanted to swing back to an, an early point Larry made. Larry was talking about spending a a year working out how an application fits together and visualizing and being able to describe how the application fits together.

A lot of modern application environments a year is like 400 feature changes and an additional 20 microservices have been deployed in that type. And so the, the moving target part of it becomes really problematic. And again, hopefully you're using these APIs and you, you're writing code that is allowing that dynamic state to be monitored over time.

And this is where we get some feelings around digital twin kind of behaviors where we can replicate in a, in a way that isn't our actual deployed network, the confis at some previous state to troubleshoot issues. Because of course, if the network's constantly changing, you had an issue last Tuesday, you can't look at how the application is today, 15 versions later to work out what happened last Tuesday and, and maybe why we lost a, uh, customer transaction pace of change is, is phenomenal when we're using these, uh, APIs. And that complicates the whole operation and, and monitoring as well.

Alistair, what you were saying is to add to that complexity is, you know, I mentioned the year part is trying to understand what the architecture looks like, how you're gonna scale it, how you're gonna automate it, how you're gonna also iterate over time is not only is part of it in the cloud, so having a test environment is easier on-prem because it's part of the bigger picture. I'm sorry, but most, at least what I see, and people still don't have test labs, like development labs, you, you're talking about, Hey, I need a dev lab. Oh, we use part of prop, like that's still a thing.

And I'm like, no, we can't send devs in to do work that are going to be touching anything close to production. So again, extremely important. Well, Alistair was talking about the microservices and you mentioned serverless before, and I'm gonna bring it back to the application observability.

The one of the concerns and the biggest issue is that your microservice or stuff is deployed and it's gone. It's no longer there. So when you go to troubleshoot, it's not, you can't figure it out like how did it go?

It wasn't developed in a way that we can efficiently troubleshoot the problem that came up. And logs are written to be in a alien language half the time for you to understand what the problem is. X had issue with Y.

Okay, what was the, you know, and it's, you know, that's hard to understand when you get platforms that can pull in this data, show the problem, retain the data, even though the application or the services is no longer there, now you can troubleshoot and blame it on the network. Well, I think that's what's gonna be interesting. Michael, you brought up Catchpoint.

I know we, we heard about that a little bit yesterday is it's gonna be very interesting. 'cause again, I'm going back to what I was describing a minute ago, is we've got all these tools, right? We've got big pandas, we've got Cribble, we've got, you name it, Dynatrace and all the things.

Um, because that's gonna be where we get that more granular, um, visibility. Whereas Catchpoint's gonna be that outside in. And you also mentioned Edge cases, right?

This scenario that I mentioned a minute ago also includes Edge. So there's Kubernetes at the edge and all that, and people are still trying to figure out if we have a network outage, how much visibility do we still need at that edge? And what is going to be the key to bringing that data back?

Because at some point when it comes back online, if we don't have proper compute at the edge, you're gonna lose that visibility. You may not get complete picture of what happened. So yeah, And I, I often wonder too, so like what you, you, you guys are talking about logs and, and overall observability.

So if we're thinking about like logs, metrics, traces, um, logs are only as good as the developers try accept log skills. Uh, so the only thing that's gonna come out in the log is like what's actually recorded in the application itself. But I, I'm, I would also hope that like, let's say you're doing some type of hybrid scenario, um, I'm, I'm gonna, I'm just going off of Azure 'cause that's what I'm currently working on.

So if I'm doing public cloud stuff, and then if I'm also doing edge stuff and I'm doing, you know, all the hybrid goodness and stuff, I, those logs, those traces, those metrics aside from the obvious of we're now leaving the public cloud and going to whatever environment should hopefully be pretty flush in, in, in the sense of how the output looks, um, to hopefully things like that will be able to help. Because to your guys' point, again, what you're saying before is like you're getting data from all different areas and then you have to somehow like look at it from a structured or unstructured perspective. Like does it, what is, what is, what is making sense here?

What's not? But if all the data is hopefully, theoretically coming from the same place, like if you're doing a hybrid solution and not a multi-cloud solution, then uh, hopefully it'll look a little bit better at the end multi-cloud solution, you're still gonna have the same problem with like, what does this even mean? What does this log, et cetera.

But hopefully it'll be a little bit easier with hybrid cloud. Going back to, again, we're talking about network. If you start thinking, you know, again, I'm going off my experience as far as network, um, that everybody has their own interpretation.

So again, a a traditional network engineer does not, in most cases have that same approach to visibility, programmatic kind of orchestrating things that you would think, and I know I'm going a roundabout way, but someone that is very familiar with public cloud has a very different perspective on how you bring that stuff together. Meaning, like you said, if I look at logs just from networking perspective, I have a ton of insight of what's going on. But nobody use logs.

Nobody uses traces unless they're in a structured way, which is why it's very important to architect it around the perspective of how do we bring it in. I mean, I could talk all day about this, like put it on a bus, put it on Kafka, have something, watch it, monitor it, be able to take action on it, report on it, Lord forbid, have to actually remediate something because a network device is out of config. So, Larry, you touched on it, that was perfect.

I love that you said put it into something and do something with it, right? You could have all logs, you could have all this stuff, but if you're not looking at 'em and not doing anything, turn it off. It's a complete waste of time.

If you're not gonna actually ever go investigate or ever do an actionable item with it or use the information, it's pointless. Luckily, I, I do think that there are particular tools and systems that are maybe getting us a little bit closer. Like for example, as, as you guys were talking, I was thinking to myself about, uh, cda like Kubernetes event driven auto scaling.

And the, the goal of key A is it has like 70 or 80 different, uh, triggers. And what ends up happening is you can perform a particular action based on a trigger. So Larry, what you were saying, like let's say you have stuff coming in from a service bus, well, you can have K to trigger based on events that are coming in in a service bus to go do a particular thing in a Kubernetes cluster.

So I think luckily it seems like we're getting a little bit closer to that, hopefully. Um, and I, I always, I I, I'm gonna butcher the, the quote, but like from the SRE handbook, the Google SRA handbook is they say that like SRE are, are software engineers that build infrastructure like software engineers. I totally just butchered that quote, but it's something like that.

And I think that's what we need more of in today's world versus maybe before I will say that Alistair was getting ready to kick in, but also I've spent a lot of time around SRE, um, kind of getting that whole mentality. And again, when you get to traditional mindsets, they're like, we need to monitor everything. No, you don't.

But like those engineering days, I mean, we always did it as CYA, right? We're gonna monitor CPU memory disc utilization. It's always gonna be green.

We don't know what a baseline is. We don't know anything about it. But getting back to the SRE thing, I, I agree everybody, we need to get to a place where we're looking at things as actionable and those actions are driven by SLOs and things like that, SLAs, and more importantly, what does that mean?

And only capture those metrics that align to that because you're spot on. It's just, yeah. And I, I really like the Idea that we're, our objective is to collect the information we need to take action and not just collect information for the point of collecting information to close that loop around.

And as we're coming to the end of the episode, I would like to thank you all for closing that loop around with me and, and having this great discussion. We will be having more of these discussions around Cloud Field Day as well. And so you can find us, uh, all of our YouTube and, uh, content from Cloud Field Day too.

So thank you all for joining us today at the Tech Field Day podcast. But before we go, where can people close the loop with you and connect and, uh, converse with you further? You can find me at at John Meyer everywhere, LinkedIn, YouTube, Twitter, Instagram, uh, and TikTok is at Meyer Media.

Uh, LinkedIn for me, just Michael Levin. You can also find me on Twitter or x, uh, at the NJ DevOps guy. Uh, but primarily LinkedIn And me, like I mentioned in the beginning, I'm not very active on anything anymore.

Um, but you can still find me on LinkedIn. But more importantly, you can, uh, at Mr. Ellie Smith Jr.

com. Um, but there's nothing out there anymore. So, And of course, I'm Alistair Cook.

I am your host here of the Tech Field, a podcast, also the event lead for Cloud Fields A 22. A lot of my online presence is as deas nz deas being bundle little company down here in New Zealand for the nz. Thank you for listening to this episode of the Tech Field Day podcast.

If you enjoyed the discussion, please subscribe to our YouTube or on your favorite podcast application. Uh, don't miss a single episode and do consider giving us a rating and a nice review so that other people find us as well. This podcast was brought to you by Tech Field Day, the home of IT experts from across the enterprise, and a part of the Futurum Group.

com/podcast or view us on Techstrong tv. Thanks for listening, and we'll see you next week.