Ep 15 - Hybrid Cloud Revolution with Azure MVP Karl Cooke

Speaker 1: 0:00

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.

Speaker 2: 0:29

All right, and welcome back to another episode of the Cables to Clouds podcast. I'm your host this week, Tim, and with us with me, as always, are my two lovely co-hosts, Chris Miles and Alex Perkins. Alex, how are you doing over there in the western part of North Carolina this week?

Speaker 4: 0:46

I feel pretty lucky. It seems like the weather that everybody's getting on the East Coast was for like two hours here and then it just completely went away and it's my kids are at the pool, the sun's out. So, yeah, feeling pretty lucky. We thought school started at the end of August and apparently we were two weeks off, so been scrambling a bit. Yeah, I didn't realize school started so early. I don't know why. I'm so used to. It's like late August is usually when I thought it starts.

Speaker 4: 1:14

But I got less than a week and I can't wait.

Speaker 2: 1:17

Oh man. Yeah, it's funny because I'm on the East side of North Carolina and my kids don't start back until the end of August, like the last week of August, so it's funny that it's different.

Speaker 4: 1:27

Yeah, I thought it was like the 28th, I think is the last Monday, but it's 14th, so I don't know. I was two weeks earlier than we were expecting.

Speaker 2: 1:34

Yeah, okay. Well, when I lived in Idaho it was all messed up. We would start super early but there was a lot of expectation of snow days and stuff and they still at that time gave extra time for kids to help their parents with farming and stuff. So there was harvest time, that was figured into the whole thing.

Speaker 4: 1:55

I also, yeah, I went to high school in Idaho. So, yes, I remember yeah.

Speaker 2: 1:59

All right, chris. What's going on in the land down under?

Speaker 5: 2:01

Hey man, not much, certainly not harvest time here right now. It's a beautiful. I don't even know what day it is Wednesday morning. For me it's quite early, still disoriented, still down in this first cup of coffee. But yeah, man, things are good. We're heading into spring here, so it's starting to look a little bit better outside. You can't tell right now it's very dark because it's so early. But yeah, we're getting over this Sydney winter, as I say with air quotes, because it's probably the most life-hearted winter I've ever experienced in my life. People here are very spoiled. They think it's freezing. When it's like for the Fahrenheit folk out there, it's like. When it's like 55 degrees, people are like, oh, it's so cold, it's like dude, this is nothing.

Speaker 2: 2:51

55, yeah, you need a light jacket. Yeah, exactly, all right.

Speaker 5: 2:57

Yeah, so I've been wearing shorts most of the winter, which is very nice.

Speaker 2: 3:02

I bet people are giving you strange looks. Who is this mad lad?

Speaker 5: 3:06

Nah, dude, so many people, people here. Half the people here are not half the people, but there's a very large Simone population here and I feel like every Simone person that I've met in the United States would be one of those people that wore shorts year round. So that's still very common here to have a lot of people still wearing shorts when it's cold, gotcha.

Speaker 2: 3:31

As for myself, I am just getting all my stuff together. We worried about the east coast weather as well, because we're going to be flying soon, so yeah, but it looks like tomorrow would be good, so I guess we'll see, and when I get back I'll sure I have lots of fun stories to tell.

Speaker 5: 3:51

So you're going to the road tomorrow. Yeah, yeah, sure. How long is the flight?

Speaker 2: 3:56

It's five hours to the west coast, but we're actually staying over at the west coast, so that makes sure that we don't miss the one to Japan. So we're actually going to sleep there in the LA and then go back to the airport early and get on the flight to Japan. It's 11 and a half hours, so we'll see. Hopefully it'll be a good time, man. Hopefully it'll all work out. So we'll see. By the time I think probably by the time this one airs, I'll probably be back, but yeah, anyway.

Speaker 2: 4:26

So the reason that it is so early for Chris and thanks to Chris for getting up and everything is that we actually have our first guest from the European part of the globe. So we'd like to welcome Carl Cook. He is an Azure Solutions Architect with Avanade, right? I said that? Right, right, yeah, awesome. He's also an Azure MVP, so we're going to be talking a little bit about the Azure MVP program as well and, honestly, just we wanted to get more Azure content in here, because we know we've spent some time, a lot of time, on the AWS stuff and we want to give all the clouds a lot of love. So it was really great for Carl to agree to join us here. So how are you doing, carl?

Speaker 3: 5:10

Pretty good, tim thanks. Thanks for getting up so early. For me, chris, that's great.

Speaker 5: 5:15

No worries, it's something I should be doing on a regular basis anyway, and I don't do it, so this is a good excuse.

Speaker 3: 5:22

Yeah, I often say yep, I'm going to get up at 5 am to study, and I think the last time it happened was maybe about a year and a half ago. So that's about right, yeah same here. But it's awesome to be here, so thanks for having me.

Speaker 2: 5:36

And Carl, you're actually in a podcast yourself, right.

Speaker 3: 5:40

Sure. So, yeah, this week Thursday will be our 10th episode. So we're really, really pretty and you're still finding your feet. So we run a myself and a couple of former colleagues run a video cast live stream called Cloud Native Weekly. So we're all Azure MVPs, but we recognize that Cloud Native isn't single cloud. Cloud Native is multi-cloud, even like we were talking about before, like hybrid and on-premises. So we wanted to start a podcast that sort of talked about what we've been doing, what we've been hands on with the last week, and then talking about specific texts in the Cloud Native ecosystem. So Cloud Native Computing Foundation. So that's what we're doing, so Bitesize sort of show 30, 35 minutes each week just covering off what we've been up to and what the latest sort of trends and news are. So it's pretty cool and it keeps us all in sort of contact with what's happening in the Cloud Native world, because it moves, like everything in the cloud and tech in general, it moves so fast, doesn't it.

Speaker 4: 6:45

Yeah, it sure does. Is that mainly Azure focused? Or you're saying you do everything?

Speaker 3: 6:50

No. So I mean we do a lot of Azure focused stuff being Azure MVPs in other user groups and talks and stuff like that but the purpose of that podcast with the Cloud Native Weekly is specifically to be cloud agnostic. Yes, we talk about if there's news for AWS, if there's news for Google Cloud in the Cloud Native space, we'll share it and we'll talk about it. And likewise, if there's stuff for Azure or just general sort of cloud native news, we'll look to talk about it. Our specific goal is to be cloud agnostic because, like I said, cloud native tech Kubernetes and related technologies it doesn't really matter where you're running it. Obviously, if you're running it outside of a cloud provider or a hyperskiller and you're not using the managed Kubernetes stuff, then the level of difficulty goes up a little bit. But I mean it's still cloud native tech and it's still worth doing.

Speaker 2: 7:44

Yeah, definitely. So what I tend to see actually is for guys, for people that get into cloud that are coming from either from something else or even just in general. They kind of go, they pick the cloud, whatever cloud that's going to be that they tend to really excel at, and then, depending on what they're doing, they tend to branch out, add the other clouds to some degree. Do you think that it's easier or harder to like once you've added like? So, once you know for me it's like AWS right for your Azure once you know the cloud of choice really well, do you think it's easier or harder to actually branch out?

Speaker 3: 8:25

Well, I think so. It depends what cloud you're moving from into, I suppose. But I think once you've learned the way of working in the cloud, it's not so much about which cloud, but you're trying to automate everything. You're trying to adapt as much DevOps culture and principles and tooling as possible. It generally doesn't matter what cloud you're coming from and going to, as long as you learn the differences and what they call things and the you know.

Speaker 3: 8:53

Each cloud and each tech has its own idiosyncrasies, right, you know. So. I think that once you know one cloud really well, the on ramp to learn another is is you know it's? It's a lot less steep for me coming to learn AWS it's about. It's about learning what the tech is called. It's about learning what cool, funky names AWS has given things you know. For me it makes sense what in my head. It makes sense what things are called in in Azure. So then I have to then translate that into the AWS world. If I'm working with AWS but I mean, if that's all you have to do and the tech is similar that's not always going to be the same, but if the tech is similar, then that on ramp is next to nothing, right?

Speaker 4: 9:36

that's yeah, I think that was like the hardest thing for me. I know, when I took what the certified cloud practitioner and then the solutions architect associate for AWS. I mean going from knowing nothing to just trying to cram in everything and every little different all the services server type yeah and like serverless versions and then like kinesis. How many different versions of kinesis stuff is there, like there's so many different different naming conventions and things that you got to memorize. So I get it, yeah, but I do like what you said.

Speaker 5: 10:06

There is like the once you, once you get familiar with how to work in the cloud and how to you know, you know, move across the landscape and things like that, it's, it's, it's the multi-cloud thing just kind of like takes hold. After that, right, you kind of learn the new way of operating and a lot of people are always like you know, oh, which cloud should I learn?

Speaker 5: 10:26

what's the best one to learn? You know first. If I'm first getting into it and I'm really just like, it doesn't really matter, man, just pick one as long as you pick one and you know if it's, if you have a use case that's, that's better suited for you.

Speaker 5: 10:39

Like you know, if maybe your company's an azure shop and you have more advancement opportunities because you you learn azure, then do that, man, you know, just dive in, then you can, you know, move around your own environment, things like that. And then you know that multi-cloud approach just kind of makes more and more sense the more that you deal with the cloud.

Speaker 3: 10:57

After that, right, yeah, 100% you find a lot of a lot of traditional server techs from you know, like Microsoft houses, they're running Windows Server for everything, the, the. The gap needed to make the jump the azure is a bit narrower than perhaps the gap is to move to to something like AWS. You'll find a lot of the old Windows Server techs. Make the jump, the azure, yeah, and a lot of the. What I find, and and this is a sweeping generalization so I apologize in advance but a lot of the, a lot of the. You know Linux techs and you know hardcore network people like yourselves tend to tend to make that jump to AWS. Some someone once, once told me the day AWS networking was networking for grown-ups and azure networking was networking for children and toddlers. So I think that we're being about that.

Speaker 2: 11:50

We're being about harsh, to be fair, but I mean yeah no, that's, that's that's really good, because, especially on the networking side, I find that most CSPs I find from a service side meaning like the service, like kinesis or, you know, azure bicep versus cloud formation or something like this, like that those ones are almost like one for one and what you say is actually true, right, once you learn just that the names are different, like and the cloud mindset, or like the cloud, the way things are done in the cloud, the the why cloud of it.

Speaker 2: 12:20

I do agree there's a lot of transference between all of the clouds that are out there. But then you run into these fun little ones where, like the AWS networking versus like azure networking versus GC oh god, don't even start on gcp networking right, there's a like like almost like holy war type of, yeah, fundamental differences between those. So that's that's where I start to, and I guess it really does depend, right, where you're coming from, where you're going to and what part of it you're focusing on as well. I find the networking is very different between all three clouds yeah, it is for sure.

Speaker 4: 12:52

I think also I don't know, at least, and maybe this is just anecdotal, but to me it seems like a lot of the people who are really knowledgeable in networking move to the AWS like work for AWS. Like you know, I don't know a whole lot of people that were network architects that went on to work on azure networking, and maybe that's just because I don't know enough people, but to me it just seems like maybe that's, maybe that's the case and I actually like azure networking.

Speaker 2: 13:17

I should get that out front right. I actually enjoy like the, especially things like there's. There are things that, uh, that azure has done that make a lot of sense to network architecture, like, for example, I actually love that the azure route server, like the route reflector. I love.

Speaker 2: 13:31

It right, I mean like it makes perfect sense. That's a great you know. And then so I mean things like there are other things that I'm just like why do they do it this way? Or like they did not realize it was going to screw everybody up, like things like direct server return and and things like that. So but I mean, yeah, I don't know, though I don't agree with the whole azure. Networking is for children.

Speaker 3: 13:50

Maybe it was being facetious, right 100% was being facetious, but it got us the point across. You know, and and whichever route server sorry, I'm talking to some Americans, so I should say it correctly, right, right, right server is a fantastic piece of kit and you know, if azure if anybody is watching can make their native azure firewall talk bgp, then that would make network engineers lives a lot easier and then you wouldn't have to use palo Alto or or checkpoint or name your firewall of plans. But I mean that makes your life so much easier because it integrates with the fabric in terms of your express route connections, new VPN connections, and you know you're linking it up to your, your firewall. So you're you're not having the program manual routes everywhere.

Speaker 2: 14:40

It's just fantastic resource yeah and but and before the show we were talking about how I think we all agree that, like, hybrid cloud is here to stay right. Like the idea of taking something outside the cloud, connecting it to the cloud that's not going anywhere. Pick your cloud that's not going anywhere. And so things like bgp, things like you know, being able to, anything that makes it easier to integrate a third party extra cloud with cloud is like is really helpful, is great and and yeah, in terms of dynamic routing protocol, bgp is tends to be where it's at.

Speaker 3: 15:10

There isn't really any other choice in azure, if you want to use the azure tech, it's bgp. I don't know. I'm not familiar enough with the networking stack on aws to know if they know it's true anything else, but it's all bgp all the way down pick, pick your cloud.

Speaker 2: 15:25

It's all bgp all the way down right thank god, that's all right, yeah no, no doubt.

Speaker 2: 15:32

Um, so I would love to ask about because none of us? Again, because we want to get more azure in here, but we also want to understand. Because none of us? Uh, when we first had been talking to you, none of us understood the, the mvp program. Like, I'm an aws community builder, so I assume it's something, yeah, somewhat similar, right, but but tell us about the mvp program because, honestly, outside of yourself, I hadn't heard a lot about it before then.

Speaker 3: 15:54

So yeah, there's swine and azure mvp. There's about 3000 mvps in total well, maybe a bit more than 3000 in total across the globe and that split across multiple like specialisms almost swine, I'm azure there's like business applications, things like business central and dynamics and things like that. Then there's there's specialist areas like office 365 and dev ops and stuff like that. So there are multiple sort of specialisms, um, and it's a. It's awarded yearly by Microsoft for um, community contributions, sort of tech leadership sort of stuff like, uh, mentoring and community leadership stuff. So, yeah, I mean it's just.

Speaker 3: 16:36

I mean for me it wasn't ever really about the award, because if it was about the awards you'd get it and then you'd stop. It's about just making the journey for people coming after me easier. You know, I was always and one of the, the folks from the networking community who now I think he works for AWS a guy called Deanne Lightfoot um, he was, he was one of the folks back when I was focused solely on on networking and it ops was um inspired me just to get involved in the community and start to give back more than it had been, you know. So you know it's just about giving back and helping people. For me in the. The MVP award for for things like that is uh is a nice bonus, you know yeah, it'd be hard to find someone that doesn't know who Duane is.

Speaker 2: 17:22

Yeah yeah, duane, duane. I think we all know Duane, and I mean Duane was one of the people that wrote one of the forwards for my book. We, we know each other very well, so I'm glad it's, I'm happy to hear his, his name, come into your mouth, because he's a yeah, awesome guy, awesome guy.

Speaker 3: 17:38

I guess he's working for the the enemy. I mean AWS now, but I mean that's there's no we're.

Speaker 2: 17:44

I mean at our level, I truly don't believe there's such a thing as an enemy, because we 100, not, I think you know, if familiar with Kelsey Hightar um familiar. I don't know personally, but I'm familiar so he he was.

Speaker 3: 17:58

I follow him on Twitter or I refuse to call it X, but you get the idea. Um, you know, he said uh off, so he was working for Google, right? So he said someone. It said he had said someone at Microsoft. They're like, uh, different company, same team, sort of. And that's how I view all of the community involvement. We may all work for different companies, we may even work for competitors, but we're all on the same team, as cheesy and as corny as that perhaps sounds, but same team. We're still trying to advance tech and we're still trying to make people's lives easier, right?

Speaker 5: 18:31

I think, alex, I think we were talking about this I don't remember where we were talking about this the other day but just this concept that like as much as we buy into the multi-cloud way of life here. That means that these teams that are managing your cloud environment should not be siloed into a single cloud, right? They should be multi-cloud engineers and multi-cloud architects and things like that. Right, because there's you need to see it as one big synonymous thing. Obviously, the constructs and how things interoperate together are different, but, yeah, it should be a sole platform engineering type thing that's covering all of your cloud environments, right?

Speaker 3: 19:12

Yeah, and if you're running platform engineering teams, they're going to be cross-functional anyway. So they're going to be cross-functional between dev and ops dev ops so why not make them cross-functional against different cloud providers this way, If your company's that?

Speaker 4: 19:28

big. I'm glad you both said the platform teams are platform engineering, because that's exactly what I always try to preach about. But it's not like. There's not like a multi-cloud community builder program, right. So, everybody's going to have their own cloud, like Tim is saying their own cloud that they're specialists in, and that's probably I don't know many people that are probably an Azure MVP and a AWS community builder and whatever you know. Google's might have right so.

Speaker 5: 19:57

Yeah, I'm sure. Oci can come up with something pretty soon.

Speaker 2: 20:00

Yeah, right, yeah, oci Alibaba like there's something, but the industry, though, is very small Like we talk about. We're on the same team. I don't think it's cheesy and corny, because the industry is so much smaller than all of us think it is. We all know each other. It's like it's not even six degrees from Kevin Bacon, right, it's like three at the most.

Speaker 3: 20:19

Yeah it's remarkable and the rise of I'm going to sound like an old man here, but the rise of social media and how people interact and how people build their networks, the people version, not the blingy lights version, but how people build their networks in on social media, on Twitter sorry X and things that blinked in. I mean, that's how I got my last several jobs was because of the networking that I had to people networking I had done helping people out, getting involved in conversations.

Speaker 2: 20:49

And it's really important to get involved with the community, and we've been. I mean, we preach that ourselves. We're all getting involved with the community. If nothing else, it helps you network. I've often said especially when I worked at Cisco, but even after that I still say that the networking industry is a lot more networking than it is. Networking meaning people.

Speaker 4: 21:13

Networking is very important Right, yeah, 100%, it is for sure.

Speaker 2: 21:18

All right. So let's talk a little bit about what you do with Azure. So, obviously, as solutions architect, in theory you do a little bit of everything, but walk us through a little bit of do you have a focus or do you just pick and choose?

Speaker 3: 21:31

So I have a favorite technology or set of technologies, yes, so, as we were talking before, I'm originally from an IT ops background, so a lot of hands-on server tech and a lot of hands-on Dell networking sort of kept. So I mean, that's the sort of background I'm from. But get that gives you a good foundation for working in the cloud, regardless of who it is. But for me it was that good foundation for working in Azure. So I'm fairly generalist across most of Azure so I can put my hand on most of it and I'm fairly good at reading the docs if I don't know it. But cloud networking for me, and then more recently like managed Kubernetes and Kubernetes, cloud native sort of tech, is what I call my hobby space.

Speaker 3: 22:18

But my day-to-day at the minute is working with as we were talking earlier, working with a big like energy supplier provider company that spans a few locations around the globe and where I'm embedded with them as a cloud architect, and my day-to-day is fairly different each day. But at the minute we're working towards a migration of several thousand servers out of private data centers to India Azure. So some of that's going to be lift and shift, some of that's going to be refactoring and rearchitecting into new technologies, so most days are different, or most weeks are different to the last, which is why I enjoy working in the cloud. It's not. You don't get bored very easily.

Speaker 5: 23:00

Yeah, that's something I commented on One of our earlier episodes is like when I first came over here to the cloud space, I realized how fast these projects move and how quick you have to be on your feet because it's you're not waiting for procurement cycles for kit and things like that. Right, things move so much quicker, but these are crown jewels applications as well, so it's kind of like this strange new dynamic that I was not accustomed to whatsoever.

Speaker 3: 23:31

And it's funny you say that about procurement times and lead times. I was shocked to hear that my client is ordering some new special switches from Cisco and the lead time on them is several months and I was like what?

Speaker 5: 23:47

So we have to adjust down Several months. That sounds good. Yeah, that was way worse.

Speaker 3: 23:54

So they're using those for their express route and their max-sec for the connection or the port encryption and stuff. But because I've been working cloud focused or cloud only, pretty much the last few years, it took me a moment to get my head right. Hang on a minute. What Several months was like? Far enough, I suppose.

Speaker 2: 24:12

It was years. At one point, not so very long ago, it was a year or more lead time on some of that, a lot of that kit.

Speaker 4: 24:19

Yeah, I was seeing like 70 weeks at one point.

Speaker 2: 24:21

Wow. Jesus yeah it's the chip shortages and silicon shortages that COVID kind of exacerbated. I think it is starting to get better now. But yeah, I mean, it's hard to think about that in the cloud, but I mean, in one of our previous episodes we were just talking about this like the CSP is about to be feeling the pain of those shortages as well. So far they've hidden it. Well, I think you can just buy in whatever white boxes or who knows what they're doing.

Speaker 4: 24:48

Yeah, not only talking about provisioning time or not provisioning time, but like procurement times, provisioning time is down because everybody expects you to just build the infrastructure with some infrastructure as code use Terraform or something or whatever the cloud native one is and they just expect it up just as fast as well.

Speaker 5: 25:09

Yeah, all those IEC constructs are already being there for you. Make it that much easier to adopt, right? So yeah, yeah.

Speaker 3: 25:17

What are our favorite infrastructure code? Are we all Terraform? Are we starting another holy war?

Speaker 2: 25:24

Yeah, I was going to ask you the same. Actually. It's funny, but yeah, we're all Terraform guys here.

Speaker 3: 25:29

So I mean Ben Ben, an Azure guy, primarily. Of late I was armed templates which are, I'm sorry, microsoft, but they're terrible. I'm more recently bicep, which is similar to in fact it's super similar to Terraform. It's scary. Starting my new job at Avanade, I played with Terraform bits and pieces but hadn't really got involved, and that's what we were saying earlier about knowing one tech helping you with the on-ramp to another.

Speaker 4: 26:03

My on-ramp.

Speaker 3: 26:03

In the first six months learning Terraform, I would say now my Terraform skill set is either as terrible or as good as my bicep. So Terraform's fantastic language. There are some annoyances with it, but I mean same with everything, right.

Speaker 2: 26:24

That's true.

Speaker 3: 26:24

And you can take.

Speaker 2: 26:25

Terraform between clouds. That's the big one is that you can use Terraform with other providers and all of that. That's the big one, I think.

Speaker 3: 26:31

Once you've learned the logic and the F and the loops and all of that good stuff. I mean, it's just about the provider that you're using and the resource definition.

Speaker 2: 26:41

Modules and resources.

Speaker 5: 26:42

yep, absolutely One thing that's really funny is, if you look at the differences among the providers, though it's like everyone I first looked at how to build an EC2 instance versus how to build a compute instance in Azure. The example code that they'll give you in Terraform, it's like you're like what the f**k? The Azure one is like 60, 70 lines of code and the AWS one is like 10, you're just like, oh my gosh.

Speaker 5: 27:08

But you understand what the need for all of it? It actually is good to have that much versatility and modularity built into the Azure one, but it's pretty daunting at first.

Speaker 2: 27:19

Yeah, most of that needs to be optional. How the code should be, of course, is that give us the minimum required right that had the required things we have to include right, and then just give us 50 optional ones to add on right, right.

Speaker 4: 27:33

Yeah, and I mean some places you don't even have an option, right? Like I said I was saying earlier, I do a lot of hybrid cloud stuff, so I can't just pick one. I basically have to use Terraform, because a lot of times it works for the on-prem stuff too.

Speaker 2: 27:44

Yep, the providers for actual hardware, oh my god. Or even just virtual, like even VMware stuff. Man, it's really all over the place. Most of them are really bad.

Speaker 4: 27:55

Yeah, we've been working with the ACI one a lot. I'll just leave it at that.

Speaker 2: 28:02

I mean A for effort, I guess for trying. But yeah, there's been a lot yeah it's better than not having one.

Speaker 4: 28:08

At least I have something out.

Speaker 2: 28:09

But I agree with the IAC the whole point of it is to speed up agility, but also to support elasticity, which is the really the big thing about the cloud is being able to do elasticity. So being able to build something, use it, destroy it, whatever. That's the big benefit, the bonus.

Speaker 3: 28:30

Yeah and funny having this conversation with our client today.

Speaker 3: 28:34

I mean, the whole benefit of using something like Terraform, especially for big enterprises, is to make sure that virtual machine one is configured in exactly the same way as virtual machine 101.

Speaker 3: 28:47

You want to be building as an architect or consultant or an engineer. You want to be building your IAC modules in an opinionated way. So if there are non-negotiables like lack of public IP address or specific configurations on your resource, make an opinionated module and then, like we're saying, make the stuff optional. You don't care about it. That can be tweaked without creating massive security holes. But that's the whole point of infrastructure code is just to make consistency and standardization a lot easier, especially if you're working at enterprise grade, because you're not deploying one or two of these things and ultimately your infrastructure code acts as your last line of defense when it comes to, like, disaster recovery and business continuity, because you're not going to ask Tim, who deployed a 10 virtual machines six years ago, to come and deploy them in exactly the same way, so that the infrastructure code is your source of truth. Then you're ensuring that that consistency and standardization and your last line of defense after a resume generating event.

Speaker 4: 29:55

Yeah, it's also not only that. I mean, do you do a lot of work with IDPs and those are internal developer platforms Of late? Not really. I only bring it up because basically an IDP for those who doesn't know it's like an interface where someone can go and basically grab runbooks. If a dev needs to spin up an environment, the infrastructure team or platform engineering team usually will already have kind of everything built out and it's like a self-service portal. So the point is like you want that predefined infrastructure so someone can just go in and take that and build it out for whatever environment they're trying to set up.

Speaker 3: 30:34

So we're starting to do that sort of thing with this current client that I'm working with. We're starting to build out sandbox environments which has predefined sets of code that they can go and deploy. The one I've just finished was what I dubbed an AKS playground but was renamed a sandbox. But it's effectively the same thing. It deploys a playground, if you like A set of infrastructure, container registry, networks, monitoring and Kubernetes cluster, just so that devs can then go and play with it effectively, learn it and see how it all fits together. So doing that, having that sort of thing inside your business, the IDP, your internal developer platforms it allows your developers and your architects to go and play and learn and imagine what's next.

Speaker 4: 31:22

Yeah, absolutely. It gives you a lot of freedom Backstage. If anyone's heard of the, anyone heard anyone talking about backstage. That's probably the most common one right now. I think it's in the CNCF as well.

Speaker 2: 31:37

That's the agility use case, if you will is to give the developer everything they need to just start mucking stuff up and building and sandboxing, and all that when I worked at Cisco. On the vendor side, when I worked at Cisco, we had Dcloud, which is the demo cloud. It's very similar. It doesn't use Terraform or anything. It's all built on other stuff because it's been around for years and years now. So it was built on, but it was the same idea. Right Again, on the vendor side, it was more about being able to have repeatable architecture for demonstration purposes, for customers to play with and to be able to show customers the different stuff. But it's the same idea. Take it from a network perspective versus the developer using it as a platform to go build or learn. But it's huge, it's a big deal and it's really, really useful.

Speaker 3: 32:28

Yeah, I mean in terms of speed and agility. Developers and businesses in general aren't going to wait six weeks for you to build up an environment for them. It might be an exaggeration, it might not, depending on the business, but they're not going to wait longer than a couple of hours for you to get them an environment to test their theories and to test their ideas and, realistically, to be successful. You've got to learn this stuff. You've got to know how to decrease the time to build stuff or the time to create stuff in the cloud, so that your developers can get a running start on it. They're not while the idea is fresh and exciting in their mind, so they can get a running start at developing it and seeing what fits together and what doesn't.

Speaker 2: 33:11

And prototyping and just doing that basic smoke test thing.

Speaker 3: 33:15

That's the word I was looking for.

Speaker 2: 33:17

Yeah, I think that actually is the software development word, for it is prototyping.

Speaker 3: 33:21

But yeah.

Speaker 2: 33:23

When I did my bachelor's, there was a whole class about software development and I had to learn all the little tech, the words for it, and it was like what is he talking about? Yeah, prototyping, yeah, so no, but that's it. That was the value prop of the cloud to begin with. That's why Amy Davis started. The whole thing was here's some extra compute you could be up and running in seconds. That was the value prop to begin with.

Speaker 3: 33:45

And while we're talking about that, leveraging the cloud, if that, oh terrible, the Phoenix project. Nobody can see that.

Speaker 2: 33:52

Yeah, man, there it is, there you go.

Speaker 3: 33:54

Yeah, that's what they end up doing in that book is they end up leveraging so that it sounds like they're running big batch jobs on old compute, old hardware and it was just falling over. So what they then did was leverage the cloud to scale up and hundreds of nodes or whatever it was, and then scale back down again. So exactly what we're talking about they're leveraging the cloud to accomplish things at speed.

Speaker 2: 34:22

And elastically, which again was one of the huge value props of cloud to begin with was you don't have to overbuild your data center to support the biggest amount of work you're going to do right.

Speaker 3: 34:32

Yeah, I mean you find that I mean I say this to customers all the time as an architect you find that so much hardware on premises and in private cloud and data centers is so much of respect, like you were saying, Tim, just for the possibility that you might need to scale into it. But in reality, when you're running your reports and when you're getting your trains, maybe they're only using 25% of that. So all of that CPU and not much above 70% of the memory or something. So you're paying for what might happen in the on premises world and the cloud that allows that elasticity, like you said, and you're paying for what you use. It scales up and down so fast that there's no point having it sitting there twiddling its thumbs and not doing anything. That's just costing you money. So cool tech.

Speaker 2: 35:20

Yeah, I worked at a company that their whole model basically was that they would send you something. You would go to the website and order stuff for a box that they'd put together and send to you, but if you didn't do it, you were committed. So what they would do is they sent a backup order. It was like a every month. They had like a backup order thing where if you didn't order anything, you know you were still committed to buy something. So they would just have a generic order they would send you, and so what you would see is that at the end of the month, before they've ticked over and people were going to be sent this backup order, people would panic, run to the website to buy, to like actually put the order that they wanted together and they called it month end and it was exactly the situation where the entire data center was built to handle, essentially, you know, five or six hours of that kind of hammering.

Speaker 3: 36:14

Yeah, I worked with a customer several jobs ago at the stage of e-commerce platform in this part of the world, and they in advance. So they were running on virtual machines. So they were running on virtual machines in Azure, which is a start right, but because of the way they built their application, they couldn't, like scale out across multiple instances. So what they were doing was, in advance of the busy times Christmas, valentine's Day, anywhere where you have to buy a jewelry for vertical, you know. You know they scaled up to a massive VM skew that cost them so much money, over and above what they will ever need, no matter how busy they are just so they wouldn't hit that limit, right?

Speaker 3: 36:53

So what we did then was we worked with them to say, right, let's make your application a bit more stateless, let's allow it to scale out across multiple instances. You know, let's take advantage of the cloud. You're sitting running in the cloud, so let's take advantage of it. So instead of, you know, having to manually scale your VM up to something huge, you know, let the platform or move it to like app service I think it was that we moved it to and let it sort of auto scale based on your CPU starting to creep up, your memory starting to creep up. Okay, let's double our instances here.

Speaker 2: 37:26

You know, again, refactor, that's the R, the refactor R to make it so that we can scale it outwards, Otherwise all things monolith that you just keep having to make bigger and bigger.

Speaker 3: 37:35

Yeah, and the best way to take advantage of I mean you can take advantage of the cloud with a stateful application. But one of the best ways to take advantage of the cloud and the elasticity and the scalability is to create a stateless application. So I mean what I mean when I say stateless application. It's that you're not relying on local server storage for caching, for state or for, you know, for data storage, so you can afford to lose an instance of an application and your customer just drops to another one as if nothing's happened. There's no experience change, you know, because the databases, the databases outside the application server, the state, the session state and the you know the data files and stuff that they're working with are all outside. So you can scale from one to 100, perhaps, and the experience is the same. It doesn't matter which one the customer drops on, so long as you know your backend or your backing services are still there.

Speaker 2: 38:26

That's the loose coupling model, right? That's what. That's what it's called. That's what ABS calls it. Abs calls it the loose coupling model, with this idea of decoupling all of your apps. Yeah.

Speaker 3: 38:36

I make them not rely on each other. Introduce things like service bus and stuff and curing and messaging technologies in between your services so that if one feels the upstream or downstream service doesn't care, it just picks something up from the queue or from the service bus, you know.

Speaker 4: 38:52

And we're dancing around it, but you know, kubernetes, a lot of the stuff, one of itself to Kubernetes. So I think you mentioned that you do some work with Kubernetes as well. Is it mainly just I think you mentioned AKS is it mainly just the Azure?

Speaker 3: 39:08

So mostly it's the Azure one. Yeah, I mean, once you're scaled in Kubernetes, it genuinely doesn't matter where it's running. You know, because the principles are the same In the on-premises world. You're perhaps having to manage your SCD database and you're having to do an awful lot of like cluster management, control, plane things that you wouldn't have to do any KS and AWS or AKS in Azure.

Speaker 2: 39:35

Or GKE.

Speaker 3: 39:36

GKE.

Speaker 4: 39:37

GKE and.

Speaker 3: 39:38

AKS.

Speaker 2: 39:39

Yeah, we don't have enough of these.

Speaker 3: 39:41

In the managed versions. You know they abstract an awful lot. It's not completely responsibility free for the operator but it takes an awful lot of that worry about managing. You mean your entire cluster databases and SCD. So I mean you're managing that on-premises, making sure that's highly available and making sure that's backed up and that it all works.

Speaker 3: 40:03

You know, so I mean the managed Kubernetes versions are no brainer for me because the platform, whether it be Azure, aws or Google, they take a lot of that responsibility, that take on a lot of that shared responsibility for that sort of stuff. So you know, gke.

Speaker 2: 40:17

They let the developers focus on developing for the platform rather than having to deal with the system administration essentially of the life cycle.

Speaker 3: 40:26

GKE, and there's still your platform engineering folks and your day of apps folks and your Kubernetes specialists. There's still a lot of apps work to be done, even on managed Kubernetes. You know you've still got to make sure your scaling is there and make sure you're tracking your dependencies and making sure that you're not using out of data APIs and stuff like that. I mean there's I mean I could go on for an hour or more on things that your IT apps folks will still need to do, even with managed Kubernetes, but it's removing enough of a headache that you know they can focus on making the platform scale, making it secure and making it so that, again that your developers are, are we able to hit the ground running?

Speaker 4: 41:07

Yeah, the irony is the more experience you are with it, the more you want to manage service. Service instead of donate yourself. Hey, you know what can go wrong, then right and you're not responsible for all the things that usually do break.

Speaker 5: 41:21

Yeah right, just a quick question I want to ask, since you do have a bit of a networking background as well, and now you've kind of transitioned to working with Kubernetes where do you see the role of networking in a Kubernetes space, you know, with this kind of adoption of C&Is and things like that, C&Is and stuff yeah.

Speaker 3: 41:41

Well, funny, you'd say that. So I've been talking to one of the solution architects at Cilium today. So Cilium is there are lots of C&Is out there, right, but Cilium, I've just started to get the grips with it and it's awesome, yeah, in terms of what it can do. I mean it's combining your C&I and your Calico C&I, maybe in AKS. Before you had to have separate ingress controllers and such like Nginx and maybe Link or D or SDO for something if you're wanting to use ServiceMesh or something like that. And I'm just learning Cilium at this point. But Cilium in the networking stack it seems to do all of those things. It seems to do them really well while giving you a lot of visibility through their Hubble. You know the metrics gathering and stuff. I mean network specific metrics gathering, which an awful lot of times you're missing in the cloud that network engineer specific sort of viewpoint which Hubble will give you.

Speaker 3: 42:42

So network engineers are still very relevant. And knowing how, even in a managed Kubernetes, knowing how your pods will talk to each other and, if you're using an overlay, how they're talking to the nodes and how that then all the dreaded not word comes in, how that all talks to the platform and how that all talks to the internet or other services hosted in the cloud, then that network knowledge for anything in the cloud and Kubernetes specifically because you asked, Chris, it's still very relevant. And I'm attracted to Kubernetes A because I find it fun which maybe is weird, but being from a network engineer background, but maybe definitely not as experienced as you three, but being able to get involved in the weeds almost of the tech, that's attractive. I'm getting to know one and how it all plums together and how it all connects and how they all talk to each other. It's super interesting.

Speaker 2: 43:41

It's fascinating, honestly. Container network is fascinating.

Speaker 4: 43:44

Yeah, and it's two points. All three of the big three CSPs Google, azure, aws. They're managed providers, all use Scyllium. And then the second point someone that everyone should follow, if you're interested in this space at all, is Nicholas, and I'm probably going to mess up his last name. I think it's Vibert or Vibert V-I-B-E-R-T. I think. He's the senior technical marketing engineer for ISOvalent, which is the parent company for Scyllium.

Speaker 4: 44:12

Man. He puts out demos daily and he builds all these courses that are like how to use BGP with a CNI, and it's awesome he's got so much content up there.

Speaker 3: 44:24

So Scyllium, talking to one of the solution architects today. They have a map of the labs that you can do to learn Scyllium and one of them is advanced BGP with Scyllium. And then there's Ingress and network and EBPF and all of the magic that EBPF enables you to do, and there's loads of labs you can do. I'll drop you the link afterwards if you want to include it in show notes yeah, absolutely.

Speaker 3: 44:48

But it allows you to see. So there's the observability with Hubble and stuff like that. Then there's the security and the networking side of things. That takes you through multiple labs and they're all hands on and I'm working my way through them at the minute, but they're not paywalled, and that's one of the things about cloud native tech it's open source and they're not paywalling a lot of the learning content and stuff. So I'm working my way through it at the minute and it really is fairly high quality for being free. So I'll drop that in the show notes so that the labs are pretty good.

Speaker 2: 45:21

Yeah, absolutely, we definitely need to put that in the show notes. We've got a whole list of stuff we need to put in the show notes for this show as well. So I'll have to go back and grab everything your podcast and, of course, how can we get in touch with you, and stuff like that. It's all go, it all has to grab all that stuff and put it in the show notes.

Speaker 3: 45:39

Yeah, I mean, if you can see my name down here somewhere, I'm pretty much that handle at Carl and the Sky Teenert for most things I'm involved in, so in some shape or fashion. So, although there's X or Twitter and LinkedIn is pretty much where I focus most of my time, but I haven't made the jump to three yet. Yeah, for sure, let's see.

Speaker 2: 46:04

I'm just going through the list of stuff that we had still on our list that we haven't asked yet. I did have one last one, I guess, and it might be a really short one actually. So we've been looking at a lot of the stuff that the different CSPs are doing to kind of more abstract networking, not just on the container space but just in general, like, for example, like AWS has VPC, lattice, for example. That's very, you know, very dev focused. I'm not as up to on Azure, so do you know, is Microsoft planning to do, or are they already doing, something to kind of more abstract, the networking away from the devs?

Speaker 3: 46:43

So is VPC Lattice like a mesh networking sort of all the VPCs can talk to other VPCs.

Speaker 2: 46:52

Aws themselves themselves would say not really, but I think for purposes of understanding the very high level, the idea is, yeah, that developers can say these services can talk to each other, and then there can be policy where they can talk to each other.

Speaker 4: 47:06

I think, since you know a little bit about service mesh, think about it as a service mesh, but not just for Kubernetes, it's for, like everything, so VPCs and any resource everything. And you build your own service networks and it's got a registry and it's got all that policy and stuff.

Speaker 3: 47:23

Yeah Sounds interesting On the Azure set of things. I mean you generally for most enterprise-grade networking you're running with Hub and Spoke or you're running with Virtual One, which is abstracted Hub and Spoke anyway, you know. But they do have something that you can do with, network Manager, which I suppose abstracts away some of the skillset needed to manage Hub and Spoke networks and stuff. Or you can tell the Network Manager product what you want, whether that be a full mesh network or whether that be Hub and Spoke, and it goes and does it. So it probably not advanced as what VPC lattice sounds like it is, without looking at it. But it's that sort of technology that removes the need for well, I was about to say removes the need for that skill set. But I don't think you ever truly remove the need for that skill set right, because if something goes wrong you're going to need to understand how the higher cloud routes packets. For me to be, yeah that's fair.

Speaker 4: 48:22

One other thing that we kind of hit on a little bit earlier is like hybrid cloud stuff, right? So I think have you been working with Azure Arc, yeah, and what do you do with that, I guess?

Speaker 3: 48:35

So at the minute, actually there's a couple of things we're doing. At the minute, whether it's my client, runs a fairly large Linux sort of Red Hat state and previously monitored with SCOM, with System Center Operations Monitor, whatever it's called, but SCOM anyway. The nightmares.

Speaker 3: 48:52

Yes, you're familiar, and it's a bit behind the times in terms of patch level, so it doesn't support the most recent terms or the most recent Red Hat 8.0 something.

Speaker 3: 49:04

So what we're doing is we're replacing that with Azure Monitor, and in order to do that in the on-premises world, we need to onboard the servers in the Azure Arc.

Speaker 3: 49:12

So we're doing that. We're using Ansible there's a really short Ansible playbook for onboarding stuff to the Azure Arc and then what we're doing on top of that is, once the resources are in Azure Arc, they're treated almost like a virtual machine. You can apply Azure policy to them, you can do guest configuration, and being able to apply Azure policy to them allows me then to target the resource group that they sit in and tell the policy, to make sure that the Azure Monitor agent is installed on those on-premises servers and to make sure that we're collecting a specific set of data for logging and monitoring purposes from those servers as well. So, yeah, azure Arc is a really cool piece of tech and I'm only scratching the surface of it with the monitoring. We're also looking at their Windows Server 2012 and SQL 2012 and stuff as end of life or coming end of life. In October, you're able to do a pay as you go. Extend the security updates as long as you onboard your Windows Server 2012 servers.

Speaker 4: 50:12

That's a lot of words a lot of time saying server.

Speaker 3: 50:16

But if you onboard the Azure Arc, you can activate extended security updates for three years and pay for it with your Azure build. So month to month sort of pay as you go, instead of having to buy years at a time.

Speaker 4: 50:29

There's a lot of places that could take you into that.

Speaker 3: 50:33

And that's 100% only scratching the surface with Azure Arc, because you can do guest configuration, you can do. You can apply all sorts of security policies and the what Microsoft called the defender for cloud can reach into your own premises environment and monitor that sort of stuff as well, and then you can use that to feed into your SIEM Sentinel if you're using Microsoft SIEM, but you can feed all of that into you know. So Hybrid cloud is for most enterprises will be where they sit. The lots of enterprises, maybe most enterprises, will never go full cloud because there'll always be something that'll always be a workload or an application that doesn't make sense.

Speaker 2: 51:14

Yeah, hybrid is the future.

Speaker 3: 51:15

It doesn't make sense. Maybe there are latency requirements. Submillisecond latency requirements are you know that mean that moving to the cloud, where even a couple of milliseconds increase, you know, grinds your application to hell. That doesn't make sense. So there's always going to be.

Speaker 2: 51:29

We've got 24, seven workloads that'll never be elastic, that don't belong in the cloud. There's lots of reasons, right?

Speaker 4: 51:35

Yeah, so hybrid is, hybrid is the way. Yeah, we do. We need to get like a Azure Arc specialist to come on and do a whole episode about it. That'd be awesome.

Speaker 2: 51:44

Yeah, it's really cool. When I was studying for AZ 104, I spent a good bit of time. I didn't get it a lab or anything, unfortunately, but it looked really cool. The idea it seemed like the idea was to put these agents on your on-prem gear and essentially bring the cloud operating control model thing to it.

Speaker 3: 51:59

Yeah, so if you're looking for someone to come on and talk Azure Arc, there's an advocate at Microsoft called Leor Camrat and I've probably butchered his name, but he is Mr Azure Arc and he also. He also dreamt up and built Arc playground, or Arc Jumpstart it's called. So if you Google Arc Jumpstart, there's a lot of predefined bicep or terraform and stuff that'll. That's cool. It'll deploy entire environments in Azure as a hyper-v and then sort of VMs on top of that hyper-v virtualization and it'll pretend to be an on-premise server so you can play with Azure Arc.

Speaker 2: 52:39

You can put Arc on. Oh, that's cool yeah.

Speaker 3: 52:42

So that, just so you can play. So there's Arc for server, there's the data platform stuff and there's the Kubernetes stuff for Arc as well. There's, if you Google Arc Jumpstart, there's just entire like workshops worth of information there that you can run yourself and get the grips with.

Speaker 4: 52:58

Very nice. Yeah, small world Leor. I know Leor from what is the VDM virtual design master like back in a while back that used to do a lot of VM or stuff that he was super involved in, so that name definitely is very familiar.

Speaker 3: 53:13

So yeah, he's definitely the one to be asking about Azure Arc and he's usually more than happy, in my experience, to talk about Azure Arc on socials and stuff.

Speaker 2: 53:22

So very cool. We'll reach out to him. Awesome, I think. Yeah, I think we're actually just about at time. So I wanted to thank Carl for coming on. We already kind of covered. Like you know, how do we find you? We'll add a lot of the other stuff to the show notes as well to make sure that other people can find your work and also find your podcast and a lot of the other stuff we got to talk about over here today. So this has been Cables to Cloud. If you guys enjoyed what you heard or saw, depending on where you are consuming, please feel free to smash that like button and subscribe. There may or may not be a like button, depending on whether this is YouTube or the podcast.

Speaker 5: 54:04

There's always a proverbial like. Button.

Speaker 2: 54:07

There's always a proverbial like button, even if that is just a subscribe button, so please feel free to subscribe to us as well. And again, thanks for coming on. This has been awesome, carl. We'll have to have you back at another time, it's been awesome.

Speaker 3: 54:19

Thanks a lot.

Speaker 2: 54:20

Take care, everybody. Cheers. Hi everyone, it's Tim 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 podcast catcher, as well as subscribe and turn on notifications for our YouTube channel to be notified of all our new episodes. Follow us on socials at Cables to Clouds. You can also visit our website for all the show notes at CablesToCloudscom. Thanks again for listening and see you next time.