Folks, thank you for joining us. This you've joined, well, a community fabric, conversation where today what we're gonna be talking about is networking, in a multi cloud world. Now conventional wisdom might state that as more and more of our applications and our services become cloud based, so the need to understand the network over which they deliver decreases. But is that really true? My name is Darren Forwell.

I'm a product evangelist for IP Fabric. I'll be quizzing my illustrious guest here about that topic over the next half an hour or so, but so feel free to share comments and questions. We'll do our best to either answer them during the live stream or afterwards on LinkedIn. But my guest, who is a bit of a legend in the Azure networking space even though he smiles every time I say that, Jose, would you like to introduce yourself? Yeah.

Absolutely. Thanks for having me, Darren. So, yeah, let me introduce, about about my career, who I am. So Jose Moreno is my name. Originally born and raised in Spain, but living in Germany for the last 22 years.

I I started my career as a data center network engineer in, in a mission critical data center, so I still remember the times where the the managers are looking over your shoulder, and you are typing, iOS commands like crazy because the clock is ticking and the SLAs are counting. After, while, got my CCIE and my CCD my CCIE at the time, I moved on to to Cisco, working on on, still working on the rest Internet working, for the ones, still remembering the the the CSS or the CSM module for the 65 k 65 1000000. Them well. Remember them well. Yeah.

The the one optimization engine, doing, doing, UCS when it, it, it came out. After that, I I that that was my my entry point to to server technologies like VMware or or OpenStack. Then I moved over to to the ACI, world application centric infrastructure. I I almost said Azure container instance, but I can't promise. And, yeah, there, I I had the honor and privilege of writing a book with my dear friend, Frank Dagenhart, on on on deploying ACI for Cisco Press.

And after that, I moved over to Microsoft, where I've been in the last, five and a half years now, doing mostly, cloud networking. I started in in, in the partner organization, and now I am helping customers that, encounter technical challenges when moving to cloud. Fantastic. Thank you. I mean, you know, very very imminent.

And and, I I know you talk about ACI and and everything. And so you've you've watched things, I guess, move from that sort of traditional networking through through the controller, through the the sort of cloud esque, view of of an on premises network infrastructure into, And as you say, you're working in in full full cloud now. But why do you think cloud has become a particularly important way of delivering applications now? Is is there a particular reason to think? I'm not sure if there's a particular reason.

I can tell you most of the customers I work with, it it used to be a question they they asked themselves. Should we cloud should we go to cloud? Should we shouldn't we go to cloud? We are having that conversation less and less. It's it's becoming more a no brain a no brainer.

Okay. And I think it's it's, mostly, a financial and and risk, reason rather than technical. Right? Okay. Moving from a CapEx to an Opex model, sharing risks with with the cloud provider so that you don't have to do everything yourself, especially I I see those I I I see those being the primary two reasons, at least for the customers I work with, why why they decide to move to cloud.

And I suppose the other the other side of that is is the, things like agility and stuff are different, right, in a in a in a cloud model as opposed to to on prem? I mean, what what sort of what do you see as as as the sort of technical drivers, I suppose? Yeah. Exactly. And and, so the the what I mentioned earlier that you go from a, a CapEx to an OpEx model, it has that those implications as well because, suddenly, you can deploy whenever you want, and you can create stuff whenever you want, which means you can delete stuff whenever you want.

So sizing, exactly. Sizing is is on one side a a more refined exercise because you are continuously rightsizing, which might be up or down, as well as role based fax control is is critical because, you cannot accidentally delete a router on prem. Yeah. Yeah. But in in in cloud, you could well, I don't know if easily, but you could, if you put some effort into it, you could delete the whole infrastructure of your company in one go.

So so, yeah, there's some very go ahead. I suppose what you're talking about is consumption. Right? Is is is building being able to to create resource as and when you need it in a consumable way so that so that you you're not you're not I guess you're not thinking necessarily about I need to spin up some infrastructure to support this thing. I just go and create this thing and and the infrastructure is is built around it in order to deliver it.

Is that fair? That's exactly correct. That's exactly correct. So so one difference I was, I I see in the way we we we used to do automation in the network and the way that I see automation being done in cloud is in in in the network, we still had our silos. Right?

And, I had my networking tasks that I I I did automate, but, we were not breaking those silos. Instead, in cloud, it's like this application is going to be deployed programmatically, And I don't care what infrastructure we need for that, but I want that infrastructure to be, deployed at the same time. Right. So it's like bringing everything along. Yeah.

This is what I meant about the consumption thing, I suppose. You're not having to say, oh, I need to configure this port to do this thing. I need to create this VLAN and trunk it from here to here and blah blah blah. What you're saying is spin me this thing up on this IP address and and give me the connectivity I need to make that happen. And and the stuff happens under the hood, I suppose.

And and it it makes me makes me smile, the network automation thing. Obviously, what we're trying to do now with network automation in my view, maybe I'm I'm not getting this quite right, but I think is is really just do things faster, and more consistently. But, ultimately, the same things that we've always done. Right? So it's like, give me this VLAN.

Right? Okay. Well, I'll log in to all of these devices and create this VLAN on all these devices, but it's still configuration in lots of places. So what you're doing is just just being consistent and doing it quickly. Whereas something like, what you've just described is having to hit multiple different things in order to deliver a service.

And so it's more it's almost orchestration rather than than than task automation as such. But, but the outcome is a consumable service, isn't it? Absolutely. Absolutely, Darren. You you got it.

And, there's one additional, subtlety, which is the the cloud offers you a single API. So in in the on premises world, we we talk about orchestration because you orchestrate those different worlds. Right? I bring up the VM. I bring up the network.

I bring up the application. Everything has to happen together. However, in in in in the cloud, there's one single API to manage all those elements. I use the same REST API for bringing up my VNet or my virtual network or my virtual machine or my Kubernetes cluster. So so, yeah, it's it's kind of forcing everybody to to work, merrily together, right, instead of patching, bringing a patchwork of of scripts, in in the same process.

Yeah. So as you say, breaking down silos. Right? Because you're not having to go to different people in order to bring the service up. Yeah.

That makes sense. Yeah. Exactly. So this is interesting. So in that case, we don't we we can basically leave this to to, someone who wants to bring the service up can just do what they need to do.

They don't need to understand networking. Right? Because ultimately, the the the service does that for them. Isn't you know, that that's what why do I care then anything at all about how networking works? And you're smiling now.

So I know that that's that's that's that's I'm I'm prodding a little bit, but you see what I'm saying? Yeah. Absolutely. I'm not sure if this is different. Like, many people on premises as well tend to I'm when I say people, I I I I typically mean application folks.

Typically, don't necessarily diminish the value of networking, but take networking as a given. Yeah. And and, and in in in cloud, it's no different. Right? Like, yeah, I mean, of course, I'm going to deploy an application, and it's going to work.

However, are are you sure that that application is going to be connected to the users in your in your network, or what happens, with user public users coming, over the public Internet around the world? Are you offering them the the closest one, or, what about encryption? Or I mean, all those network issues that we used to have in networking, guess what? It they apply there, and the application folks are as a little interested as ever in those, so there's absolutely a place for network engineers there. Well, that's good to hear.

But I and I guess I guess then what you're talking about there are are different issues to the ones that you would traditionally have worried about because of the way applications are deployed, but equally as important, I suppose. I'm I'm thinking, and you'll know you'll remember this very well, I'm sure, back in the day when when we had to deploy VMware into into our data centers and and and people wanted to be able to have the same VLAN in 2 locations and be able to route to it and fail it over and all those sorts of good things. As as a network engineer, you looked at that and and you you rolled your eyes and you were like, oh, we've got to jump through hoops again in order to create this this network environment for that purpose. What we're talking about here is completely different to that. Right?

Because because applications don't work that way anymore. But can you give us a bit more insight into into that maybe? Let me start saying, yes and no. Okay. Because I just that that eye rolling experience, I I have it every now and then, with with, with, with, with, projects where the the the subnets or the VLANs need to be or or the customer would like to stretch the VLANs from on prem to to to Azure, mostly to to Azure VMware services, Azure VMware solution for to do exactly that.

So it's kind of a deja vu, but but I I think I know where you're going, and and and you're completely right. Yes. And the the in opinion, the main difference is that in in, Azure is a multi tenant infrastructure. And as a user, you don't get, the the the access to that, underlying infrastructure. You get, like, some abstraction that the cloud provider, AWS, Azure, GCP, Oracle, they offer to you.

So you can do whatever that abstraction allows you to do. It's not like, you can do all of those little things that we use to to to to have to care about on premise. You have to learn about those abstractions, and you have to learn to to to under to to try to understand them to the best, we can and to to live with, those functionalities and limitations, Yeah. Which is a piece of a different angle. I I find this one really interesting because I know when when people were first looking at migrating to Cloud, the whole idea was, oh, how do I get these VMs and take them and move them from from this on premises data center into cloud infrastructure and just spin it up in the same form that it was on on prem?

And you could see then the problems we were just trying to recreate the same problems as elsewhere. And, of course, the the cost of doing that was almost prohibited because of the way that you're trying to just just recreate your your your data center in the cloud would mean that you are running VMs all the time, that you were building much bigger machines than you would necessarily want to be running with your applications and so on and so forth. And and so it's almost like you you're just moving the problem. You you're addressing that that thing you talked about right at the beginning of of, not having to manage your own infrastructure and and and turning everything into OPEX rather than than CAPEX. Fantastic.

But what you're not doing is is maximizing the, the the advantages by by reengineering the application so they behave as a as a as a as a proper cloudy citizen, I guess, which which, you know, what I do see, I'm you're you're nodding. So I'll I'll let you just, fill up the the gaps in there that I've that I've left. No. I was going to say that that that that's exactly right. Like, I see some customers that kind of embrace the the cloud mostly because they are doing some cloudy things already on prem or and others that by just replicating what they are doing, that not only they are moving the problem, they are creating new ones.

Okay. Take for example, somebody that is using is is is centralizing all firewall or all network segmentation in a central device on on premises. That central device on premises might be a huge appliance, appliance not like pizza box, but appliance like fridge. Yeah. And you have, like, there are there are bits of capacity there.

Now you move that to cloud, and your fridge sized appliance becomes a virtual machine. Yeah. So that that's that's going to In in in one place and you're having to to funnel all your traffic through it from from the cloud. So you're losing all of the that that that distributed, capability that you've got by by using the cloud IE, spinning stuff up across regions or across data centers or whatever, you you've kind of lost a lot of that because of the that that sort of traditional thinking of of traffic flows and so on. Right?

Exactly. So we should be doing things differently is what we're saying here ultimately. Right? As far as they make sense. Yes.

Yeah. Okay. Understood. So what what kinds of things I mean, that's a really good example, I think, of the idea of of of of the of of managing those traffic flows. How do you get around those kinds of problems?

What do you do instead? What what what's the cloudy way of doing things? Yeah. That's that's a good question. Probably, the the the answer would be depends, right, on which problem we are we are trying to tackle.

But let's let's deal with that one. Me, Jose, that's a CCDE answer to to anything if ever I heard one. Right? You got me. You got me.

Yeah. Yeah. And I I could move on with the CCD answers. Like, let's separate complexity for complexity. Right?

Absolutely. And, yeah, like, I mean, like, in anything with anything, right, you need to to use the the the strengths of the platform and try to avoid their weaknesses. The weaknesses of of, any any public cloud is the the lack of of scalability of any single given, appliance, right, where you need you don't want to scale out, you want to scale out. Yeah. What's the strength?

The strength is the the certain function that can be done at, in in in in the actual platform it's itself at no cost or or penalty or performance penalty. In in this particular example of traffic segmentation, what we call network security groups in Azure or the the NACLs and the the NSEs as well in in AWS cost nothing, and, and, they can do layer 4 filtering at at the line rate, let's say. The problem is, the management of those things can be very different, as compared to the management of a traditional firewall. Sure. So So this is so this is basically a capability a firewalling capability that's distributed effectively out to right down to the to the to the host, I guess, or to the to the sorry.

Use the word host. Forget that. The word I would I would use the word host. Yeah. Yeah.

I'm I'm thinking right at the very edge rather than funneling all the traffic in, you've got to effectively you create a central policy and you can you can have that policy deployed right to to where the workload lives, at the edge of the of the network. Is that fair? That's right. It's as if I told you, Darwin, if I told you, like, 10 years ago, I want you to stop doing ACLs on your routers, and I want to to do ACL on every single switch port. You tell me you are crazy, man.

I mean, there's no way I'm going to be able to manage that. Right? However, in in in in cloud, there are some alternatives to alleviate that that management. And and this is where, yeah, I suppose the idea of of grouping, you you create groups and you have policies that you apply to groups and and do all that through through the API. So you'll you'll manage or or through the cons whichever console capability you're using.

Yeah. You're able to to to centrally manage it that way. Like it. I mean, that that saves well, it saves it saves that problem, doesn't it, of having to to to manage the traffic flow to to funnel it into a central point. And the problem becomes a different one, right, which is the management of those constructs.

Sure. Sure. And and I guess there's always as well times when you will want to to do that. I mean, that's that's the other thing. Right?

And this is what you were saying before about it depends. Yeah. Yeah. Yeah. Exactly.

Like, for example, more advanced functionality like web application firewalling. If you cannot do that in the fabric, then you have to to do that on on a network with all appliance. That's the term we we use. And then if you do that in a network with all appliance, then you'd better use a scale out model and not a, like, a large VM because, no matter how large your VM is at a certain point in time, especially for CPU intensive operations, you are going to run out of steam. Right?

So So if you're if you're taking that kind of view, I guess, again, you need to to have a really good understanding of your application flows to be able to be sure that you're you're pushing things in the right direction, that you've got those those capabilities where you need them. I'm thinking now load balancing becomes more interesting, DNS, and those sorts of things where you're you're really fully appreciating the the behavior of the app, as well as all of the constructs that sit underneath the app in order to deliver it. Is that fair? Absolutely. Yeah.

And and yeah. Exactly. There another another perspective is that the cloud offers you a lot of multiple form factors where that app might live. And depending on where the app lives, your job as a network engineer might be different. If your app lives on a managed, service like, our web, web apps or AWS Beanstalk, then your networking job is going to be very different as if the app lives on a Kubernetes cluster or on a a plain old virtual machine.

Right. Right? So that that's introduces as well another dimension, to the to the role of the network cloud network engineer. Oh, just because I so you've you've introduced here then then containers and Kubernetes into into the loop. We've got some new technologies to learn as well by the sounds of things.

At least that that's that's been one of my learning, learning lessons, or or lessons learned in in in Azure. I used to be a data center network engineer. I used to know my my, Nexus switches like the palm of my hand. I used to know my, EVP and BGP protocols, but that that was it. And and when I came here and I started looking at that, I I had to go out of that small world, right, and learn other network technologies.

And that might be only my my situation back then, but I didn't know a lot about DNS. I didn't know a lot about, other technologies, like identity, and and guess what? I I found myself as a as a cloud network engineering engineer having to do that as well because of those multiple form factors that the application can take up. And and I guess as well and and, I'm just looking at some of the comment comments in here. Yeah.

Then I am those are interesting. Just yes. Yeah. I mean, the the there's a couple of things, I suppose. One is is talking about, how and thank you for this, Hubballa.

The the idea of of how we go from a traditional, environment and and, how we we migrate to the new. So so this this this is kind of what you partly what you're alluding to there, I suppose, is that the idea of you've got these traditional ideas. You need to think about that migration, but you also need to be able to accommodate both. Yep. So I suppose there's an aspect of that.

And and the other thing is is, of course, you're never only gonna have one cloud, are you? There's always that thing of of, if you've got multiple clouds, how you manage and handle the differences between the two and the commonalities, but different approaches potentially. So, you must be having those conversations all the time, I'm guessing, I say. Yeah. So let let me let me tackle the second question first about multi cloud.

Yes. Sounds good. I I see multi cloud mostly in larger customers. Why? Frankly, I've been 5 years doing Azure, and I still don't know, everything as much as I would like to.

Right? So one single cloud is is enough for me, and I'm, like, 100% on it. So you you kind of need a large team if you want to be specialized in in multiple multiple clouds or outsource to somebody who does. Right? So I I see this mostly in in larger customers.

Now to to your first point about, connectivity to on prem and as well that's going into into how people ask question. Like, the the way I see most people end, coming in is, by not by necessarily by migrating stuff, by deploying new applications, in the cloud. So, typically, a connection back to on premises is required, and you are not replacing anything. You're just adding stuff to the cloud that needs to go back, to to your your data center. So it's just like an additional network, really, and that's will.

Yeah. It's similar to a a new branch or or something, and and and potentially, that customer might decide to migrate stuff down the line or maybe not or maybe add the second the the next app to a different cloud. But at that point, it's it's, a bit closer to a one engineer rather than to to to to being in into that, segmentation or or or, management what we we talked about earlier. Yeah. Understood.

I I I always think, and and this comes from from, again, my cc the days, I suppose, of when when you were architecting a large network, it was never really a single network. It was always a network of networks and trying to appreciate how individual parts of that network interacted with the others, and and you were able to get that overarching view. And I think this is no feels no different really to to some extent because you're just creating more islands of networking that you're that you're bringing back in with all the rest, but but we've got a whole load more options here. And, of course, the behavior of that new island is very different to to the Yep. Perhaps the the what you're used to dealing with.

So I couldn't agree more. Like, that that thinking in tiers that, network engineers have so ingrained in our brains. Right? That that's True. Very, very valuable here in in, no matter whether you're on premise or in cloud, that doesn't change.

Yeah. It's and there's some interesting, capabilities, and I don't know how much exposure you've had to things like to to the Aviatrixes of this world, to Alkira and people like this who are now building Yeah. These these multi cloud overlays or orchestration pieces where they're able to to to bring together, these environments again with on prem or with SD WAN, in order to deliver that that continuous connectivity. That's this always makes me smile because people say, oh, well, it keep makes things simpler. Okay.

What it does is makes it perhaps simpler to create that that capability or to operate it. But under the hood, you've just introduced another tier, right, of of the the complexity there. So, I mean, do you have much sort of much to say about those and and much exposure to those types of solutions? Yeah. I have, well, I'm not an expert on on any of those.

Right? I have had certain exposure. It it it's a RFC 1925. Right? With that, you can always add another layer of of abstraction problem.

So, yeah, I mean, I I think there is a valid place for for these solutions. If that additional abstraction you're introducing actually, allows for, for example, in the case of Aviatrix, having a single network campaign for the multi cloud perspective, why not? Zscaler is another company that has a very interesting approach to to this problem, and they came out with a solution last December on on, cloud workload segmentation, agent based. So that's closer to the Kubernetes world and service desk than so you are doing your networking inside of the workload on the virtual machine. Right?

And so you don't care about the networking in between, right, in theory? I I haven't I haven't looked at that one closely because it's so new, but that's the sounds of it, right, as you said. I I I do think there's place for for these solutions depending on your culture as organization. If you want if you are so application centric that you won't don't want to know anything about networking, and we come back to our discussion earlier on of those application folks, Maybe one of these solutions will help, but at the end of of the day, as you say, there's a network below. Yeah.

Right? Yeah. I I think I think this is what it I mean, I'm biased and I'm I'm sure you are a little bit We we are. But we come we come coming from that networking background, you cannot help but say, well, look, ultimately, you need to understand or appreciate what the network is trying to do underneath in order to ensure that you are gonna get the service delivered you expect. And so and and and I mean, I remember seeing this somewhere actually, in a in a report, last year where they talked about the fact that if you've got a disconnect between your networking folk and your application folk, if they don't have the same understanding of of the the connectivity, if the the networking people don't don't know how the cloud's built and vice versa, you're gonna you're gonna put your your cloud delivery at risk because ultimately, how can you know that failover is gonna work or how can you know that that, that you'll get the the the quality of of network connectivity service that you need in order to be sure that your your application stays available.

I guess it's about working together more. Is that fair? I think I think it is. I think it is, Darren. Like, I don't I don't think, a project without any network expert expertise has a lot of chances of becoming successful.

I'm not saying that application folks know anything about networking, but, we as network engineers, I think it's it's up to us to step up, right, to the challenge and and make sure that we are in those, in those projects because, yeah, they need us, frankly. So how do we do that, Jose? I mean, you've you've clearly done that because you've gone gone and and and, you know, progressed to a really high level in networking, and now you're you've you're kinda making that transition. I'd I'd say made, but from what you're saying, you still think you've got plenty to learn. So what's that again, CCIE mindset there.

Right? But but that's that's there's always new things to learn. So but but how would you go about it? What's the what's the best approach, do you think? Yeah.

So, what I would recommend folks out there is just pick a a cloud of of your choice, potentially the one that your organization is working with, if there's one. If not, you can open free accounts with with any of the big ones and start playing around. There there are a couple of of, adjacent skills that are going to help you, getting there because it's not only as we were mentioning earl earlier, it's not only about learning how to create a a VNet or a VPC in in in that specific cloud. It's about knowing how to automate that. So you you should be looking as well at things, like Terraform.

If if, you you don't know what they are, you you should be googling that right now. Yeah. And, potentially then, depending on on on the technologies you have on your organization, things like like, Kubernetes. But my like like, cutting it short, my recommendation would be just start doing it. Sure.

I I can't disagree with you. I mean, for from, I mean, from my very limited exposure, I mean, I I am way far back on on that journey. My previous role before this, I was working for a, they would kill me if I called them a VAR, but but a partner, a technology partner to to a lot of the main cloud providers. And it was evident then that this this is super important to try and understand these things. So I did the the cloud practitioner exams.

I did the fundamentals exams to to just get that grasp because that's the starting point, isn't it? It's understanding what what those services are and why they're different, but then looking at all of that network automation stuff that we're we're always being told as network engineers we need to do now, now, now. Just broaden the view a little and look at, yes, Python, fantastic to learn to to to operate APIs, but there are other things as well, and it's definitely worth broadening that net a little, I think. Yeah. I I agree.

If if somebody asks me what's the framework automation framework I should learn, yeah, probably Terraform would be my my first answer. And, infrastructure so c I c CICT pipelines would be my second one, which are closely related to each other. No. Absolutely. I think that that, yeah, that that sounds sounds like a very, very sensible advice.

I've already made a note on the Terraform thing. So, what we might do actually is if you've got any resources that that, people might might be interested in, for that, or I know I've got a couple of things that I've been following up on. We could pop those in the notes afterwards and, see if we can follow-up on that. That'd be great. I've just we're already 34 minutes in, I'd say, which is which is fantastic because that means that this conversation has just been flowing.

We don't have any more comments or questions, but if anyone else does want to put anything in there, that'd be great. I'm just wondering if any any other pearls of wisdom, really? Any any other thoughts? I mean, these are these are great because getting that understanding, working out, you know, the automation piece is gonna be super important. So so, obviously, building on that would be great.

I any other thoughts that the of things that people can can sort of read around or or try and understand a bit more, or is it just really a case of getting cracking? Yeah. Potentially, one last thought, I would like to to leave people with is is how how different, at least in my in my opinion, this is from, other networking technologies that we've seen in the past. We were talking about this earlier, Darren, like like, NSX or or, OpenStack, Neutron, or Kubernetes itself. We are talking about that where as networking folks, we see a we see ourselves a bit like, being left out of the party because that's a platform created for for some somebody else.

Right? And then they do networking, but it's like, we are not supposed to go into the OpenStack console and and configure stuff. I'm I'm oversimplifying here. No. No.

However, in in in cloud, there's not such a thing. Right? Cloud is is built from the ground up to to let, database administrators have the little corner and to let, network administrators who have the little corner. So everybody's welcome. Right?

Yeah. And this is everybody's party, and everybody has the same It's it's it's coming new to this. So don't feel, that you are, worse and worse position than than than anybody else. It's like everybody's starting with this. So just as you said, get started with it.

And and and the the sooner you you start, the the more, familiar it will, be at the end of the day. Yeah. From from my perspective, can only say the same that that, as you've already said, projects are more successful when everyone has visibility and understanding of of what's going on, that you've got, a a mixture of folks involved in in these projects so that you've got the the that multidisciplinary understanding and everything. So, it's a case of just mucking in, I suppose, as as part of the the the delivery team, whatever that team looks like, and and, and to get on and and, just make make the most of of everyone's understanding as we're all learning together. Exactly.

You you you you will reuse your BGP skills in the cloud as well. Be sure about that. Oh, yeah. Oh, yeah. Oh, definitely.

I think I'm gonna wind it down there if that's okay, Jose. Listen, I I really appreciate you spending your time talking to us today. It's been really, really interesting, and I think it might be a a conversation we'll have to have a part 2 on at some point to to take it to the next level. But, anytime you want, Darish. It's been a pleasure.

Fantastic. Thank you for for joining us. Folks, if you've got any other questions, you know where we are, feel free to to, contact myself or. Jose, where can people get hold of you if they want to to follow-up? LinkedIn is probably the best place.

So just, drop me a message, and, yeah. Happy to happy to, to work to work with you guys. And your your blog, where else is that? Oh, thanks for you see, you're in your in in the deal market, and I'm not. Yeah.

If you want to to to learn, what I'm what I'm what I do in my free time, block dot, cloud trooper.net. I can help being a a Star Wars a Star Wars, fanboy in my free time. Top job. So, yeah, that that that there are some, some information that come up, often and so that I don't forget myself. I'm I'm growing old.

I tend to try to write that down. It's a really good idea. I I must have I, I've read a few of the articles on there over over recent weeks, and they're great. They're they're really, really good from a it's that thing of have being able to describe capabilities from a networking perspective really helped me understand things. So, yeah, we'll what we'll do is we'll we'll we'll pull some we'll pull some stuff together, and we'll pop them in the notes.

We'll make sure that you're, yeah, that, the cloud trooper, appears there as well. And, we talked about some potentially Terraform, resources or whatever. Sonoran, just send you a note there as well, so we'll we'll make sure that that, that goes into those as well. Thank you very much for your time. Appreciate it, and, thank you for all of those people who, have joined us and and watched and listened.

There will be a recording, that will go onto, onto LinkedIn Live. So if if you know anyone who who would be interested in in seeing this, this conversation later, and we'll be putting a recording onto Spotify as well if anyone's interested in that as well. So, an absolute pleasure. Thanks as ever, Jose. We'll talk more.

Thanks, Darren, for having me. Thanks. Cheers. Have a great day. Bye.

Bye bye.