00:47
This is the Art of Network Engineering podcast.

00:58
In this podcast, we'll explore tools, technologies, and the talents of people. We aim to bring you information that will expand your skill sense and toolbox, and share the stories of fellow network engineers. Dear Journal, Nobody understands me. I mean, in the modern era, I'm practically a mature teenager. But people really don't get me. I just get labeled left and right. They say that some days I have a lot of sass, which seems a bit rude. I'm just figuring things out, you know?

01:27
Other days I get called full of IaaS, which I don't even think they know what that means, but they make it sound like an insult. I wish they would just see me for who I am. I'm much more than just somebody else's data center. I am magnificent. I am nebulous. I am the cloud. P.S. They didn't estimate their usage correctly, so I'm practically rich now. P.P.S. I can't wait to enjoy this episode of the art of network engineering.

01:55
You know Tim, I gotta tell you for a second I thought you were reading my diary and I got a little bit worried about what you were gonna say there. I understand you AJ. So he's in my diary, he's in my books. I thought those were secure. First it was your DMs, now it's your diary. All right, welcome to another episode of the Art of Network Engineering. I am AJ Murray at No Blinky Blinky. And I am joined this evening by Tim Bertino at Tim Bertino, that super creative title.

02:25
Twitter handle Tim. How you doing Andy was he just giving me shit? You know it's part of AJ's charm He's mean to you, but somehow that means he likes you so yeah, if I'm not picking on you. I don't love you I am actually on still on cloud 9 no pun intended Teaser for the episode, but AJ and I just got to hang out in person a couple of weeks ago from this recording We got to be at networking field day 30 out in sunny, California together, so that was

02:55
That was awesome to get to catch up with AJ and I'm happy to be back. The last time I saw and recorded with Andy, he had like a wicked pre beard going on and now that's gone. So I, I don't know what way is up. Now you got the beard. Yeah. I told you my wife didn't like the mustache alone, which I now so our episode with Roel, the wireless episode just recently dropped and I saw the, uh, the thumbnail come out and that's when I had just the mustache. I'm like, okay, now I get it.

03:22
That wasn't a good look. That's great. That's great. Yeah, Tim. That was a great time. I was really good to see you again. I you know, and like I said before I feel like i'm getting a little bit spoiled because I have zero expectations I'm trying to temper them that I would see at anybody at any given point as much as I want to see everybody all the time Uh, you know in the podcast group so to be able to see you like once twice a year I'm i'm tickled pink and it was so fun to hang out with you for

03:50
Almost a week and we also got to meet Gerard in person Gerard Cavalinas from tech house 570, you know, we've hung out with him virtually for quite a long time now And you know, he's been on an episode of the podcast and it was just really cool to see him in person He has just as much energy in person as he does online Maybe even a little bit more than I expected but that was really good watching him All right, cool, I'm not alone now it was super fun hang out with everybody

04:19
Ethan freaking Banks. I mean it was yeah, it was cool. There's lots of lots of good people to meet Yeah, it turns out Ethan and I are Practically neighbors practically neighbors now He lives about two hours away, which is closer than I expected so at some point He's and I are gonna get together and have some fun But yeah, no it was really cool to meet everybody out there Jordan was there as well

04:41
And, you know, he's on his trip around the country. We, you know, he kind of shared with us how he lives as a nomad with his family. And that was really cool to hear about. And so such a fun event. Those those tech field days. Andy, how are you doing? Hey, AJ, I'm good, man. I just got back from a week in the Caribbean. And man, then I came home to like snow. And I don't know why I live where I live. You know, you talked about out in sunny California, like when I went out to work at Cali, I'm like, yeah, this is.

05:11
Right. This is this is the spot and then you know, I go to like the Caribbean and I I'm not built for east coast winters Man, I gotta get out of here. So as we record this episode right now It is 28 degrees outside the schools for tomorrow have already been canceled in my region because it is supposed to be bitterly cold the the temperature will be negative nine and then with the wind chill We could see temps as low as negative 30 during the day tomorrow while the sun is out

05:41
I have a reason I have a reason that I'm okay with that because in Watching the stream tonight We have Chris miles and Chris miles lives in a place where the spiders are as big as your head And I'm sure there's other animals that just want to punch you in the face So that is why I'm okay with living in a place where the air hurts my face. That is a fair trade-off I've seen videos of those huntsman spiders. I think most recently I saw one like in a car like

06:11
climbing across the hood or the roof of the car or whatever. And it's just like, nope, nope, whole lot of nope. Beyond that, getting back to me. Oh, sorry, didn't mean to take the attention away from you. But yeah, beyond that, we have some really exciting things that we probably can't talk about here, but our phones have been ringing and our emails have been dinging and I think we have some really fun, cool, exciting stuff. Yeah.

06:36
a ton of regarding the podcast coming up. So I'm really looking forward to sharing things if and when they come together. But yeah, so that's it for me, man. I'm good. You know, I have to say, it looks like you had a great time in the Caribbean. I was honestly concerned with that last photo that you sent the group, because I thought that you were in like a life raft. I really wasn't sure.

06:57
It did look like that. You were like, current status. I'm like, Andy, are you okay? Oh yeah. They have these little plastic island hammock things that are 50 yards off the beach and anchored to the ground. So you swim out and then you just lay in it. It looked like you had been out there for days. I was off all socials. I wasn't talking to anybody. I'm like, you know what? I miss my podcast chums. Let me send them a picture of current status. And AJ immediately comes back like.

07:24
Are you okay? You look like you're on a life raft. Do you need help? I don't know why I bother Because leave it to andy like if he's in a life or death situation I do picture that he would send us a you know a picture of his current situation. He's got a document It's just like my airplane crashed, but i'm in the caribbean. So it's like I don't know how much trouble i'm in right now It's coming hashtag winning. We had such a good time. We rebooked while we were there So i'll be in turks and k-tel this time last year. That's great. Nice next year. Yeah

07:53
So let's get to the guests. That's what we're talking about here. So tonight we're talking about the cloud. We want to lay a beautiful foundation of the cloud. And Andy, you happen to work with somebody that knows an awful lot about the cloud. Tim has done an awful lot lately. He got his Cloud Plus certification. And I myself am currently studying for some additional AWS certifications for work. So it seems like it's the right time to talk about cloud. Andy, do you mind? Who is your friend? And what is their background in the clouds?

08:22
So I don't want to tell the guy's story, but I'll tell you that this gentleman, we work at the same place and he had tweeted something out about having gone to a vendor after being a network architect. And it caught my attention. He wrote up a little piece, you know, a thread about how amazing the experience had been. So I reached out to him and it became a job eventually through some other circumstances. But yeah, Sean is my go-to cloud guru buddy at work.

08:52
And I just can't wait to learn some cloud stuff here. We've never done a cloud episode. So I, you know, I'm hoping that we can just start high level defining some terms and then just jump in, you know, as deep as we want to go. I don't see Sean. I'm not sure if we lost him or if that's just a video. I'm here. I see him. He's there. Awesome. I lost you. I just see an S, but I know what you look like. Yeah. Well, good. Yeah. Thanks for, thanks for having me on. Much, much appreciated.

09:22
Yeah, as Andy said, we work together and it's kind of my first gig on the vendor side within a networking company, predominantly my background. I'm a networking, routing and switch guy. Give me a CLI, give me some OSPF and BGP and some layer two networks and let me run with it.

09:46
I've just kind of been fortunate that I've had the experience really started more when I was still on the customer side of kind of like doing cloud migrations. I was working for a fairly large company as a senior network architect. We went from NeverCloud to Cloud First. So that was a fun experience. Kind of got some exposure. They said, hey, I knew that we were doing some cloud things. I kept asking kind of what was coming along.

10:12
you know, typical, typical enterprise networking, right? Somebody came to me and they said, Hey, I can't connect from, you know, inside the data center to our instances in Azure. And I'm like, yes, that's, that's correct. You can't cause you know, we, what are you talking about instances in Azure? Um, and so then it was like, yeah, can you fix this today? So that was my introduction to cloud. I was trying to learn how to spell Azure and, you know, it was basically like, here, go, go get us connected. So, um, and then from there, yeah, it's just kind of.

10:42
I did a bit of work for a while with the company, really getting people set up with hybrid connectivity going into public cloud. And then since my time at Juniper, I've been working a lot on various different cloud initiatives. So networking products that we have that are really like cloud native networking products to help customers turn around and build cloud platforms themselves. And then also some things we were doing around the public cloud space too. So yeah, thanks for having me.

11:09
My, my insurance cloud was at my last employer. So some, some guy they had built connectivity into Azure, put some workloads out there, didn't document anything and then quit. So then something, something broke and everybody was pissed and they were like, Oh yeah, um, Andy, can you like figure all this connectivity out and document it? I'm like, Oh my God, why does God hate me?

11:36
That was my introduction to cloud. And I've joked in the past, oh, it's just somebody else's data center, but that's a very minimalizing kind of statement, right? Like each cloud provider does their own thing and connectivity in and out of like multi-cloud. So then we went through a merger and we went from Azure to like all of them. And it just overwhelmed me, and it was really hard to like figure out. But I'm hoping like, so I was thinking today.

12:04
I was thinking about the show tonight and I remember studying CCNA and the diagrams like the internet is the cloud, right? Like, oh, you just draw a cloud and that's an internet. So I'm hoping we could just start like real high level definition, right? Like for somebody who has no idea. Like what's the cloud? Is the internet the cloud? That's not what we're talking about here. Maybe it is. So you're our cloud guy. What the hell is the cloud, right? Andy, that's exactly why I started kind of studying.

12:33
to trying to understand cloud basics, not to jump in and be a practitioner, but to understand so when I'm in meetings and I'm hearing terms get thrown around and people are discussing cloud services and where to take the organization, I can at least have somewhat of an idea so I know what is being agreed to or not. And that's.

12:58
really where it started for me. And that's why I went after I started looking at CompTIA's Cloud Essentials Plus, because it really breaks down, you know, what it is. It starts with the NIST has a number of characteristics that define the cloud. And then they get into the different service models in delivery models. So I don't know if maybe that's Sean, is that a good place to start or? Yeah, I think it is. And I think too, like to me, always like demystifying things helps.

13:24
I think those service and delivery models help. I think, you know, we think about public cloud too, right? Maybe the first level set basics is, whether it's Google, Azure, AWS, right? Look, they're going out and building a bunch of data centers and throwing switches and routers and racks of servers in them, right? I mean, I'm obviously oversimplifying that, but when they come out and they say, hey, we, and then they call it a region, right?

13:50
You know, AWS is infamous like US East one, right? It's like their original kind of regions in Northern Virginia. You know, and they go, okay, that's the US East one region. It's comprised of like, I don't know, like 30 different data centers or something like that, right? Going up and down the, that kind of area. So I, to me, like, I think, you know, just demystifying, just think, okay, look, they're, they're brick and mortar. They got power cooling racks and racks and racks of gear. And yeah, the scale challenges that they have are pretty unique.

14:19
Right. They're pretty unique on the scaling challenges they have, but then they, they basically turn around, they expose some services to people that want to go use their stuff, right. And they expose these different services to them. And, and then as a, as an operator, right. Or a practitioner of using the cloud services, you use the tools that they have to, to provision those different services. And I think probably that, you know, maybe Tim, that probably gets into a little bit about like the.

14:46
I think what you're alluding to around the delivery models and kind of what that looks like. So I do want to touch on scale for a minute. You said scale is an interesting issue. Thinking about it from just an enterprise network with their own data center, you pretty much from a scale perspective, you have to think out in front of, okay, what's the most I'm gonna have to run and I have to buy that thing. And if we ever get close to that, we have to duplicate it essentially. How do cloud providers

15:15
think about scale when, like you said, they're basically just giving customers that they have today and that they may have tomorrow these catalogs of what they can purchase, their usage can vary differently on a day-to-day basis. So how do cloud providers deal with scale? Yeah, that's a good question. You know, data, like actual data and lots of it.

15:43
You know, they're very disciplined in that in that manner, right? I think you know, it's a really good really good point Like really good perspective if you think about it, you know, they can't think about like oh What's the name of that switch and let me go log in to the CLI and SSH to this device, right? So they have to like abstract that out, right? So they go and they create like products that they call and that that product might be a rack It might just be and so usually what they'll do is like they go prefab a rack full of gear and they have a template

16:10
that this is our rack and we're going to go give it a name. and they use single mode fiber for everything. There's these little things that we probably take for granted of, let me go roll out some new switches It's completely different for their environment.

16:39
whole rack of equipment that's already pre-provisioned, they'll connect it up, and that's how they start looking at things. When you think about a data center core in AWS, for example, what they call a data center core is somewhere around 200 routers. It's like a core router for the AWS data center core router. You start thinking about some of these types of things.

17:08
and the scale that they deal with. And, you know, yeah, it's, it's completely different. They do a ton of telemetry. They're pulling a lot of data out of their systems. They have custom tools in the house to go and look at all these things. And they have data scientists that like, that's their, their sole job, right? AWS has people that turn around and focus on how to go get more data going over the speed of light through a laser optic, because they spend.

17:35
50 to 100 million dollars a year on fiber and SFPs. So if you think you spend a lot on SFPs, right? You know, and that dollar figure is dated. That was a dollar figure I got from somebody probably like five years ago. Who knows what it is today, right? I was gonna say 50 to 100 million is like three SFPs these days. Like I just. Exactly. That's exactly it. You know, so.

17:59
Timelines are completely different. I suspect it is likely, on their end too. Azure, AWS, Google, to just go stand up a whole new data center

18:25
Just start over. Just burn the whole thing down. No, that's interesting. Yeah. Burn it to the ground and start over. Yeah. And I'm sure that like, you know, you go talk to somebody from ABA does and they'll tell you, well, it's not quite true, but okay. You know, I mean, just at a high level, right? I think, you know, you think about some of those different challenges. You know, there's a lot kind of going on there, right? And to all of us, right, what they're doing is they're just like exposing a set of different services.

18:52
And I think sometimes that's the challenge and they're doing it in these kind of different ways, especially on the networking side. I've always thought that's pretty interesting. Like you make assumptions about maybe what's available to you to provision networking in the cloud. It's just not the same. So yeah, scale's a big one for sure. So the working definition so far is somebody else's data center that we can rent services from. We don't have to build our own. We're going to rent their network and their stuff. Yeah, and I don't know if.

19:21
people are familiar, like, I don't know if you all have heard kind of like the AWS story, how it came about, like, you know, because they were kind of the first ones to really do it. There's this idea out there. And I mean, I've talked to people before and they go, oh, we've been, you know, clouds existed for 30 years. And it's like, well, those people hosting services for you is not cloud, right? Like those are two different things. And so, you know, people can go look it up. I won't go too far down a rabbit hole. But basically, like Amazon was selling.

19:49
college books exceptionally fast, right? They started as a online bookstore. They were very successful. They started adding other products. Hey, we could sell other things too. And what was happening is like their business was being, you know, impeded by their ability to go build out new, you know, deploy new networking gear, deploy new services, bring those on new servers, bring those online, right? Like that was impeding their business.

20:15
So what they started doing was just over provisioning and over planning. And so they were like, okay, well, you know, we have to plan for the growth at the beginning of the school year when everybody's out buying new college books. And that's what we have to go build for. And yeah, in the summer, it might slow down and we don't need as many servers, right? But we got to build for those peaks, right? Their, their systems were being taxed at a very event driven pace. You know, it wasn't consistent the whole year round. And so what.

20:43
Then they went and looked at it and they were like, well, how could we monetize this? Let's go figure out a way to take all this extra capacity that we're not using part of the year, right? And go figure out how to monetize that. And again, oversimplifying it, but thus AWS is born and it's completely outpaced and blown away all the revenue from Amazon itself, right? From the retail side. So that's brilliant. Wow. Like this is the real invention, right? They couldn't keep up with the demand for their...

21:12
spiky seasonal stuff, right? Huh. Yeah. And so then they were like, you know, let's go figure out how to monetize it. So I'm going to go figure out a way to rent this back to people and let them pay by the hour. Because if we start getting busy again for something happens and we don't know why, like I'm going to take those servers back from them and kick them off of it and go use it, right? Like, you know, if you think about like really, really kind of like early days of that. So yeah, it's really, it's really interesting. You know.

21:39
The impact that this has had, I mean, think about if you were trying to start up a company and you had an idea and you had to go, you know, years ago, like you would have to go, you know, hey, I have this idea. I want to make this software. I want to do this thing. Let's see what it would take. You'd have to go drum up a bunch of capital and go buy a bunch of equipment and install it and try and now it's like, man, you know, throw your credit card and, you know, on, on Google cloud or whatever, right? Pick your public cloud provider.

22:04
Throw your credit card up there and let me go start provisioning some services. And let's see if the software works. Let's see if there's a market for it. And if it doesn't, I'm going to turn it off and stop using it. That's one of the biggest advantages, right? Is you can spin up capacity like almost instantly, right? I like, so real world example, I remember the company I was at when 2020 hit and everybody got sent home, the VPN was just overwhelmed. The stuff we had sitting in our data centers and like, I think 30 or 40% of the workforce could get on and the rest of us would just try to hack in all day. And then, yeah, they did, you know, the architects went out and, and, and.

22:34
spun it up. You know, I think it was the 24, like however long it was, it was really fast. And all of a sudden the entire company, which was rather large could now VPN in. And the time it would have taken us to build that in our data centers just wouldn't have been the 20. They might have done it in the night. Like whatever it was. Yeah, the time to get a PO cut to go buy a new VPN. Right, just all that crap. You know, yeah. So Andy. You gotta upgrade your circuits, you gotta buy the stuff and the licenses. Yeah, Tim.

23:02
Let's continue to kind of frame this up. What has really helped me really understand because when I first kind of started trying to figure this stuff out, it was really just, okay, if somebody's got a data center and they're doing something for me, like Sean was just saying, that's cloud, right? And really know there's much more to it than that. And one of the things I really liked was that NIST, the National Institute of Standards and Technology, has really framed up some.

23:28
some base characteristics for what they define as a cloud service. And we can just kind of run down the list. The first is on-demand self-service. So for a cloud service to be that, users need to be able to spin up and use these services without needing assistance from an IT department, without needing assistance from a cloud provider. And then you have broad network access. You need to be able to access that cloud service over many different kinds of networks using many different device types, client types. Resource pooling.

23:57
the cloud provider needs to be able to purchase and implement these resources, compute, storage, network in bulk and be able to dynamically assign that to people as they need it. Rapid elasticity, we were talking about the scale problem earlier. You need to be able to scale up and scale down quickly and many times dynamically. And then...

24:22
what we were just talking about, payment, paying by the hour, you gotta have a way to measure the usage that people are using of your service, and that's how you bill them. So once I kinda got a grasp on what those characteristics were, that's when the light kinda went off and said, okay, so for a cloud service to be a cloud service, me, I'm very logical, you gotta spell things out for me, I don't like the nebulous, well, it's just quote the cloud. Those characteristics really helped frame it up for me.

24:52
Yeah, no, that's great. I think that like, yeah, NIST has done a really good job of that. And I think those are some really good way to frame it. It's funny. I don't know if we want to get into like IaaS and PaaS and SaaS, right? Because we hear those from around. Yeah, I think that's a good place to start. Because Tim just teed it up perfectly. That's framing the cloud. And now talking about those different offerings are the different types of clouds that you could consume.

25:21
Yeah, yeah, I know. I think that's good. Platform as a service or software as a service. These are really like delivery models, right? Microsoft has a really good visual on it. there's like the whole idea about like, like pizza or, you know, getting stuff from the restaurant. Like.

25:47
Yeah, so it's like, here's what you manage, here's what they manage, right? So I think maybe we just start with SaaS, right? Software as a service, Office 365, for example, not all software is a SaaS platform, right? The whole idea around SaaS is that the provider is providing you with the software, and they're providing it to you as a service.

26:15
how you turn around and use that software. You basically have access to the software of the SaaS platform. you're using things like Slack, There's data analytics tools and those things as well.

26:45
You know, so it's like, okay, well, what's, what's platform as a service then? Right. And so when you think about like platform as a service, the way I kind of frame it up and the, the official, the official terms on it will have it like a lot more concrete, but the way I think about platform as a service is like, I bring my data to this platform, right? So I ingest my data into that platform and now I go do things with it. But what I'm not doing is I'm not installing an operating system, right?

27:12
I'm not dealing with like those underlying pieces of software there, but instead I'm bringing my data into the platform that the provider is giving it to me back as a service. Um, so there's some things here like, you know, I'd consider power BI to be kind of like a platform as a service. There's a handful of other ones that are out there as well. They're kind of all fall into that, to that category. And then infrastructure as a service.

27:38
You know, this is more around like, okay, hey, look, we have some servers, we have networking that's there as well, right? We have these different infrastructure components and we're basically going to provide those to you and it's on you to go install the operating system, right? You get to kind of pick and choose what you want to do here. So you, we're going to give you a catalog that's going to specify like.

28:01
You know, how many, how many cores the server has, how much ram it has, some of its networking performance capabilities. Here's some storage capabilities. Here's what you need. Go install your stuff. Yeah. Think about like, here's a hypervisor, right? If you want to like draw like the enterprise analogy to it, right? You could think about like, here's a, here's a VMware stack, right? They turn around and they say, here you go. It's on you to deploy the ISO image, right? With your OS on it the way you want. There might be a catalog that has all those in there.

28:30
But you select kind of like the OS and then it's on you to install it and then you to deploy the applications and everything on top of it. Right. So it's a little bit more of the, let's call that like the traditional kind of provisioning piece. Um, and there's really, you know, the pros and cons of it, it just depends on business requirements, right? Like what you want to do. That the classic one with email, right. Is so many organizations today are like, yeah, probably doesn't make a lot of sense to my business anymore to manage email servers and SMTP relays and.

29:00
That's not really helping my enterprise, People depend on that more than ever today. so we all think about Office 365, Gmail was probably it's still around, it's still off pretty early.

29:30
When you think about using those services and for so many people, you're hybrid, right? And meaning that, Hey, I got stuff in my data center. I have things inside my enterprise campus, whatever that is, right? I still have servers. I haven't moved everything to the public cloud. And so I have some things I need to talk to SAS and I'm probably going to go over the internet to do that. Like I would to any other, you know, public internet facing type of application. I have some other things that I need to talk to like the PaaS platform.

29:57
And if you remember when we talked about paths, right, like you don't configure the networking stack, so public cloud providers deliver a past platform over public IP addresses. And I think that's good to keep in mind, right? Like, like there's exceptions to all of these, but by and large, you're delivering paths over public IP addresses. Um, so how do I connect to that? Well, do I go over to the internet? Most people do, but there's options. Sometimes that's not the, sometimes your business needs are different, right? And so there's options to go get like.

30:27
direct connectivity into the PaaS service or Google and have them advertise those public IPs to you. they're like, here's the network, or in some instances today, your own public IPs as well.

30:57
the service models that we're talking about is in terms of control. So from a SaaS perspective, I think of that as the customer has the least amount of control with a SaaS service. The service provider is pretty much delivering you a turnkey solution, and you're really just responsible for leveraging the application and the data inside it. Then down at the other end of the spectrum, infrastructure as a service, that's to me where a customer has the most control. They have control over the

31:26
the operating system, the software on top of it, they have to deal with all of the licensing and everything that goes with that. I didn't realize that though with Sean, with the platform as a service, I had learned the concepts of that, but I didn't realize that more often than not, when you spin that up, you're just being delivered a service with a public IP. Yeah, so it's really interesting, right? Cause you can think like, you're like, hey, I'm gonna go deploy these VMs sitting inside my VPC. And I know I'm...

31:54
getting ahead a little bit, but I think, you know, a lot of people are familiar with some of these terms. Like, so like, I'm gonna go deploy these VMs inside of my VPC, but man, I'd love to connect to this blob storage over here, right? Or I'd love to connect to this S3 bucket. And so now it's like, well, well, okay, I just need to connect my VM with this private IP address to my S3 bucket. Well, that S3 buckets got a public IP. Oh, okay. Well, how do I route to that?

32:18
And the traditional way was like anything else that you would route from an internal network out to the internet. Hopefully you're putting some security controls in between that instance and that public thing you're accessing. Now you're not going over the internet to get from an EC2 instance to an S3 bucket. But there's nothing stopping that packet once you NAT it,

32:47
like at a network, it's only the application controlling, you know, the request to get out somewhere, right? So at a network layer, there's nothing stopping that packet from going out to the internet, you know, if you will, right? Now, okay, insert security controls and firewalls and all those types of things. But you can kind of see where like, the challenges that you would have inside of, you know, an enterprise with multiple different data centers geographically separated from one another here, it's not...

33:16
like you still have those challenges in the public cloud. You just have to kind of like think about it and frame it differently, right? Because you're not calling up a service provider and ordering a circuit, you know, and let me get some lit fiber between my data centers or maybe, you know, an MPLS circuit or what have you, right? So it's just like a different kind of perspective you have to have it on. But yeah, PaaS is delivered over a public IP address. Now there's all sorts of modern day advanced ways that they do really cool stuff to give you greater security controls around it.

33:46
to limit your exposure, reduce threat surfaces, all those types of things, to have a lot more control over what instances access that bucket and exactly how you do it. And this is where that's not always happening at the network layer, right? That happens a little bit. Give me the TLS certificate, give me a service account that can only access that bucket. You can start doing some other things here that are pretty interesting. Is networking wonky in the cloud? Is it a lot different?

34:16
Like you said VPC, right? Isn't that like a, isn't, isn't that a networking term? I think we're about to start a whole new episode. Cloud networking. Well, I mean, it's a thing, right? And I'm asking because from my experience for whatever reason, like I understand route switch and I understand that when my applications live in my data centers, where they are, and if a, if a sudden that becomes unreachable, if an application becomes unreachable, I know where it lives, I've cared and fed for it since it was a baby.

34:45
I know what circuits and what WAN routers it should go. Like I know where to look. Where does this thing live? And what's the connectivity I built with my hands that I can check to get it going? And what I ran into in my old job was we had services deployed in like six different cloud providers. So we'd get a call that something isn't working. We're like, well, first question, where the hell is this thing? Right? And then, okay, well, it's over there. Well, it seems to me like each public cloud provider does things differently. So it was really hard.

35:14
to have a holistic, even troubleshooting methodology of like when something breaks in one of the clouds, where the hell do we even start? I don't know if that's just my ignorance to cloud because I wasn't really trained well in it, or is that a common problem? Like if you're in multi-cloud, it's just complicated and the networking is- Yeah, yeah. I wanna hear Sean's answer, yeah. I had trouble. So is it a common, yes, it's absolutely a common problem, right? And you'll hear a lot of people discuss it, what's your right strategy?

35:42
multi-cloud, single cloud, you know, I think the reality is for the people that are the practitioners of this, whether you're in networking or whether you're in other IT roles, is that multi-cloud is a reality. There's a ton of different reasons multi-cloud happens that have nothing to do with technical reasons. It is simply a reality that like if you're in the enterprise space, you're dealing with it, right? And so- Is it a bad idea or are we not allowed to say that? Like multi-cloud seemed really-

36:10
I don't know. Here's what I would say, right? There's trade-offs to anything. There's no one cloud provider that's better in every single scenario than the other one. There's going to be trade-offs to all of them, right? To me, it's like, is it good? Is it bad? It's a reality that you're not going to get away from. That's just the world we live in, right? Yeah. You're going to be in multi-cloud.

36:38
But I don't think thinking about multi-cloud is any different than how you design any other architecture, right? You always design for high availability. And as much as those cloud providers try to scale, we've seen that they are not prone to incidences that would, you know, stop them from providing their services. So I think that multi-cloud architecture is no different than having two core switches, right? Like you have to have some high availability. Now, you can do that with In.

37:06
within a single cloud provider, you can have your stuff in multiple availability zones or whatever, but even then, there still might be an issue someday that would prevent you to get into those resources. Yeah, no, agreed. I mean, the most simplistic way that I would think about it, right? I'm sure that it depends where people are at on their kind of journey, their exposure to cloud. The way I like to think about it is like, to me, the fundamental element, if you will, is a VPC.

37:36
or in Azure, they call it a VNet, a virtual network. And so the way that I think about that is like, and again, super oversimplification here of what's really happening, right? But just think about, you took a switch, you took a 48 port switch and you took 24 servers and you went and connected them to that switch and you give them all IPs and they can all talk to each other and they're all in the same layer to broadcast, they're on the same VLAN, right? Now there's no VLANs in the cloud.

38:03
So it's not what I'm saying, but just think about like conceptually what that looks like, right? So, so you have your VPC and that's kind of what it is, right? And now there's like all these APIs that get exposed. There's all these tools that you can wrap around that, but it's basically like the self-contained virtual private cloud. That's what it stands for. Right? So I have this self-contained virtual private cloud. I can kind of do whatever I want with it. I give everything some private IP addresses, you know, stuff can talk to each other. Cool. Now it's like.

38:32
well, what happens? It's funny, in previous role, before Juniper, day to day I was working with customers when you go create a VPC, there's a wizard slash 16 and it's 172.3200 slash 16.

39:02
And I remember talking to these people and they had like 48 VPCs with the same subnet assigned each one of them. And now they needed their systems to talk and they couldn't figure out how to get it. They can't go back to their business and be like, oh yeah, we just have to rebuild everything from scratch. Like that, it's a non-starter, right? So long live Nat, right? So forever.

39:26
Nat forever, long live Nat. this is where the people that think like cloud is, I knew once I started getting a little bit of exposure Like, there's no risk to people doing networking jobs. Like, I know for me,

39:52
order up all my switches and routers, I get them delivered to the, to the colo. I get my change control in, right? I'd have my whole change plan, whatever I was doing. I drive out of the data center, badge in, go through the kit, to the turnstile, get in the cage, swipe in. And I knew where everything was in every single rack in that data center, right? There's like, I don't know, 25 rows of servers, right? I knew where everything was. I knew like, well, this server is next to this one and I have, you know, some nano second.

40:21
you know, latency between the two, right? And so I never really worried about like, at least for the systems that are next to each other, right? That are in the racks next door or even across in a different aisle. Latency was never a concern for us in our enterprise environment. Quite frankly, our applications were way worse than any of the network latency. Right? So that was never a problem. Well, now you take that, right? Think about this. You're, when you say, like, I'm going to go running cloud.

40:49
Right? Because again, this doesn't just happen overnight. You don't just pick everything up and move it in the cloud. So even if you do, we can get into lift and shift and refactoring our applications, those things, microservices, whatever. But if you, if you take that, and this is where like microservices comes in, really is to think about that way. What you're doing is you're taking all these little components and all these things that need to talk to each other and you're distributing them, right? You're, you're pushing them out. Okay. Well, I still have to get a packet from this thing to that thing. And so now latency is super important, right?

41:19
So now I have this system sitting inside my data center and I needed to talk to this, this instance in the public cloud and your mileage may vary, but I'm willing to bet that the application architect didn't take that into consideration as far as network latency goes, no fault of their own. Don't mean that as a knock. If you're an enterprise architect and you're used to, and you just are like, Hey, there's some people over there that deploy all the systems and I just architect the applications. You don't think about it. Who cares? It's not my problem.

41:49
They're the ones that provide me the infrastructure. run on somebody else's infrastructure somewhere. I took this NSX boot camp, I don't know, years ago, probably And I remember showing up and the guy starts off,

42:17
And he was like, you know, how many like sysadmins, VMware admins are here, right? Like 28 people raise their hand. It's like, how many people came to this NSX class because you want to know how NSX works because you're tired of the network team taking so long to provision your network. And you think like, I can do this. I don't need them anymore, right? Like I'm good. You know, like the 28 people raise their hand. He's like, yeah, none of that's going to happen. Your network team's not going anywhere. Like there's fundamental networking concepts here, right? Like

42:46
And then he starts deep diving into multicast, right? And like all the systems were like, oh shit, right? Like, okay, I'm keeping the network person around because it's just a skillset that that's being an artwork engineer, right? So that skillset still absolutely, you know, applicable in public cloud. It's more important than ever. Um, you know, whether it's public cloud or private cloud, it's more important. You just grabbed my next question. So everything we just talked about, does that only apply to public cloud?

43:14
Is private cloud the same thing except somebody builds their own? Like, cause they're two big buckets, right? That you can be a public cloud, AWS, GCP, whatever. And then the other one is private. And that means someone builds their own cloud in their data center. Is that an accurate definition of what private cloud is? Yeah, it is. And you know, there's a, there's kind of like a saying out there and I, I tend to gravitate towards it and says that cloud is an operational model. And like, I really like that, right? Because it's like, cloud's not a place. Cloud's not a thing.

43:43
Cloud is an operational model. And so when you think about that, the model of cloud is fundamentally an application level. I'm gonna turn around and decompose all these components that make up the applications that are important to me. And I'm gonna break them down in these services because I want them to operate individually and react to demand individually. So, you know, that's probably a bit of a whole other, you know, episode we could do. But, you know, if you just think about like, you know, hey, I got a Windows server.

44:13
I put my application on that Windows server, that Windows server, like just think about like old school, right? Like the way we've been doing things for 20 years. I has some VCPUs and some memory allocated to it. I have some storage allocated to it. I have my application that's here sitting on this VM. A lot of people tend to, at least in my experience, mileage may vary, a lot of people tend to run like single applications on VMs depending upon what they are, right?

44:39
And then, okay, well, I need a lot of those VMs, and now I need to go put a load balancer in front of it because I need those to scale up and down. But when they scale, right, they're gonna scale up and down to like the components that I've provisioned to it via the virtual machine manager, whether that's VMware or something different. And then, you know, I have limitations on network capacity. I have kind of like all these things, right, that I'm gonna take into account. But fundamentally, like that application though, still...

45:09
kind of, kind of like it's not actually elastic. It's just, I add more VMs to that pool. Well, in a microservices environment, instead of having that one application deployed on that one server, what you're doing is you're decomposing all the elements of that application and you're letting them run individually. Again, I'm going to oversimplify it. Application architects are probably like, what the hell is he talking about? You know, but you're, you're, you're decomposing it, right? Like individually. And so now it's like, well.

45:33
If I need this component of my application has greater demand, I want it to scale up on its own independent of the other components of that application. Right. So that's the advantage of microservices. And that's the advantage of getting to public cloud or private cloud. When you do a lift and shift model to public cloud, and I think this is really important, right? When you do a lift and shift model, when you say, look, I have these hundred servers that run in my data center today, they're always on.

46:02
I never shut them off because, you know, they just, why would you, right? They always stay on. I don't know what happens if I do shut them off. I don't want to find out, you know, and, um, they're just kind of like systems and services that are there for the business. And so I'm going to move those to public cloud. I would argue that's generally not a good candidate for public cloud. You're going to make the public cloud provider very happy. You're going to end up with a pretty big bill and you're going to be disappointed if you move to public cloud to save money.

46:30
Like you're not going to probably get the outcome that you're looking for. Yeah. It's not a money saving strategy, right? No, it's an agility. It's agility. Right. Um, all day long. Yeah. And I do, I do like how you frame the location thing where you were saying that, that cloud is not where something is. It's like, it's like a state of mind, man. One of the things I struggled with, um,

46:58
with Private Cloud is originally I thought Private Cloud was okay, it had to be a premises that I owned, right? It had to be all of my gear, it had to be all of my stuff. But one of the things that when I was doing some of this learning early on, Cloud Bart, we had had him on the show before he had a course. And I like how he framed it is he said that Private Cloud has nothing to do with location. It's everything to do with exclusivity.

47:25
So if I have a private cloud environment, that just means that all of those resources, all of that storage is exclusive to me as a customer and I don't share it with anybody else. So I like that you called out location and how cloud really has nothing to do with where things are necessarily. Yeah, I think that that's a good way to kind of look at it, especially when you introduce the concept of product, right? Because public cloud is like, okay, you're talking about all these data centers that get built and there's this thing out there.

47:55
Now you introduce private cloud and it's like, Yeah, like, what do I run AWS in my data center? And so yeah, I think that helps. I was working at this large enterprise,

48:23
you know, RHEL and Hadoop, right? So these are Hadoop clusters. Go do big data analytics. We would take in all this information, it's for our marketing team. And so what would they do is they could do a Hadoop scoop is what it's called, right? Where they're basically talking to our enterprise data warehouse. They're talking all these different systems that data lives in. They ingest it all. So they need lots of bandwidth. They ingest it all into these Hadoop clusters. And then they do a bunch of like computational analysis and go spit out info.

48:51
stuff that's beyond me. Most of the time those servers are sitting there We needed to expand. but a predominant large data center. and go lease another cabinet,

49:19
from the data center provider. And it was like, or we could take these elastic workloads that I don't need them to run 24 seven. I only need them to run at certain times, right? Maybe twice a week. We're gonna go re-architect that because if I just take those Linux servers and put them up at the public cloud, right? That's a lift and shift. I'm not getting a lot of value. Well, we brought people in, they turned around and they did a re-architecture of the application. They went and used what I'm gonna call services native to add.

49:49
chose Azure, services native to Azure. They were using Blob storage. Yes, there was some VMs involved. There's a bunch of other stuff too, is a mixture of PaaS and IaaS that was up there in that environment, right? And now I got, you know, 26 racks back in the data center that we could now use to add in new stuff that we needed. Our bill wasn't terrible in the public cloud because I wasn't running it 24 seven, right? I was running it when we needed it. And then we would just spin everything back down.

50:18
and kind of release those resources back to the public cloud provider. And so that's typically like, to me, this is like where you get, you know, if you think about it from a business perspective, right? It's about agility. It's about being able to move quick. And this is where like elasticity helps. Not all workloads, in my opinion, are suitable for public cloud. And that's where you'll see these things, the data repatriation, you'll hear about people.

50:43
that there's another one recently that like, hey, we moved everything back on premises and it saved us all of this money, right? And that's where you'll see those types of things. It can absolutely happen. There's like anything that's trade-offs. Andy, you had asked like a good question earlier. And I grabbed some notes. You'd asked something about like, is public cloud networking kind of weird? And I thought I would run through a couple of things because these are things that I always found interesting. In my experience, I did a lot of hybrid stuff. So a lot of AWS Direct Connects.

51:13
kind of helping customers out, get those provisioned. For a while I worked at one of the companies that kind of provides that type of, call it, software defined interconnects type of connectivity, right? Where they're an Azure ExpressRoute partner, AWS Direct Connect partner, Google Cloud partner, and they kind of built up their own network and they wrapped a bunch of automation around it. And so I used to work with customers quite a bit on standing these things up and had a lot of exposure to it.

51:43
You know, there's just like interesting stuff. So like AWS Transit Gateway, people are probably fairly familiar with that, especially if you're going to open AWS. We talked before about like, I have that VPC, I have these instances running in my VPC. Well, now I need those to get out, right? I need those instances to access other stuff. How do I do that? Well, you do that through a gateway, kind of like you would, you know, Hey, go spin up that, that RVI or that SVI, right? Now I need to get some, some routing in place. So you do that through a gateway.

52:13
the latest and greatest up in AWS, been there for a while. And so you can connect your Transit Gateway like over IPsec tunnels back to, you can connect multiple VPCs for inter VPC connectivity, but you can also connect it to like an IPsec tunnel back to your on-premises. You can also connect it to a Direct Connect, right? So let's just say that you're like, okay, I'm gonna stand at my Direct Connect, I'm gonna do a BGP peering from my router sitting inside my data center, and I'm gonna directly peer to the AWS router and to my Transit Gateway.

52:42
And so now I'm going to receive the routes that I've assigned my instances in AWS and my multiple VPCs. I now receive those over the direct kit, the direct connect. Right. And so now my, my data centers sitting inside my, by Colo or whatever, right. I now have consistent, reliable, high bandwidth connectivity. I'm not routing over the internet. I'm not dealing with congestion on my ISP.

53:06
I'm, you know, I, now I have a direct BGP relationship, right? I have a eBGP peering into my environment within AWS. I'm receiving those RC 1918 routes over that, that environment. Then I'm advertising my routes to them. So, so funny stuff here, right? Transit gateway. It can advertise 20 prefixes over the direct connect. That's it. Just 20. Plan wisely. You can summarize things, right? Like you can, you can go say I have.

53:35
200 VPCs. Why? 10, 0, 0, 0, slash 8. Go. These are the things that they expose to you. Yeah, you can do that. Right? So don't get me wrong. It's not like you're limited. But this is what they expose to us as the users. So it's something to take into consideration. I would never anticipate that. I'd never be like, oh, I wonder if there's some 20 peri. So if you think about that, though, to summarize all those routes, I'd probably better design my.

54:04
IP blocks in the public cloud pretty well, right? When I, when I give those to the infrastructure team, this is why networking is not going away, right? Like the DevOps team that's spinning up all that infrastructure in AWS probably like would never even think, why would they, right? They wouldn't take that into consideration. So what do you mean summarize routes? They don't know what the hell you're talking about. So, you know, that that's one. The other one is your BGP. So what you advertise to AWS or that Direct Connect, right? Over that virtual and they do these by virtual interfaces. You can spin up more than one, but.

54:34
which you can advertise over that virtual interface is a hundred prefixes. Okay. Well what happens if you advertise a hundred and one, the BGP session gets torn down. Oh, it would anticipate that. Right. Right. I would never think I stood up a lot of, that's some dumb shit, Sean. That's some dumb shit. You want to tear the whole BGP peering down because you advertise it. How about you drop the oldest one? I mean, come on. So, so Google cloud, right? Similarities here. I'm picking on AWS, Google cloud, for example. Look, they, they,

55:03
document these. These are just, there's, there's constraints they have. There's reasons that they have for doing this is, as a practitioner, as somebody using the services, these things you just need to take into account. Right. So I don't say this to try and bash any of the public cloud providers, but this things as a network engineer, I would never anticipate is very different. Right. And so with GCP, it'll keep the BGP session up. It will not advertise anything past a hundred prefixes. So just think about that. Like that it's hidden in the BGP table.

55:32
It never makes it into your routing table inside your VPC and Google. So when you're starting to wonder why, you know, people are complaining that my VMs inside my VPC and GCP going over my partner interconnect or over my, my direct interconnect, they can access some systems in my data center, but not others. Right. You're like, there's no, you know, the firewall is good. Right. Like, what do you

55:56
Yeah. What do you mean your application can't access these and it'll be like random, right? And what it boils down to is like, there's some routes that if you're advertising more than a hundred prefixes, never make it to the routing table on the VPC. You know, so, so again, it's just like things that you have to take into account that I, I wouldn't, I wouldn't expect, right? The tools they give you, can you check, you know, can you check the routes on the other side to see, like you can validate like, oh shit, it's not there or it's a hidden route or you have visibility into it.

56:24
You do. To troubleshoot. Okay. You sure do. Yeah. You have visibility into it. You can, you can see these things. It's, it's done differently, right? Like there's different tools and what we're kind of, you know, used to. This is why multi-cloud makes me sad, Sean, because each of them have these different rules and like, if one of them is going to tear down the entire session and the other one's like, oh no, you're cool. We're just not going to put that in the rib. And then you're trying to remember, well, which one does what? And it's two in the morning and it's an outage and like, it's, it just seems like a lot to try to. Yeah.

56:53
you know, figure out in your head, which is always my challenge. Yeah, there's design considerations you have to take into place. And a lot of these things in my experience, how do I know these? I know these because I ran into every single one. You know what I mean? Like, that's how I figured it out. Right. Well, it was like, well, this is, yeah, this is weird. What's going on? You know, what's going on here? Did you have to do a lot of cloud training? Like you were a network architect and then you got thrust into the cloud. I mean, did you have to go to each.

57:20
public provider and take all their training to learn all the stuff or were you just reading documentation? Like how does somebody navigate that? Great question. So, you know, it's too Andy. You can, you can like, a lot of those stuff is documented. It's a matter of finding it. I'll, I'll give it to like all the cloud providers have done like a stand up job over the years doing more and more documentation about, you know, how that stuff works. Right. And so, and their docs are pretty good.

57:49
You found? Yeah, I found that they're pretty good. Look, nobody's docs, you know, like nobody's docs are outstanding except Pete Lumbus. I think those are the only docs that are amazing, right? But there's only like one Pete to go around. So, you know, there's only so much you could do. You know, everybody, everybody needs more, more Pete Lumbus in their work. Right. So, you know, but yeah, look, I think they do, I think they do a pretty good job. There's been a much better focus on it for sure.

58:19
But just remember, the majority of these environments are DevOps application-centric. Everybody wants the same thing from the network. They want it out of the way. Public cloud's no different. I know we're getting toward the end, but you said something earlier I wanted to circle back on. The elastic workloads that you moved from on-prem out to the cloud, and then you said something, I don't know the terms, but they refactor the application to do it or whatever. Is that?

58:48
I mean, is that hard? Is that expensive? I know developer like, I know coding can be expensive. Like it is, is that something everybody has to do? Like, Hey, you know, you want to move your elastic workloads while we have 13 applications that are elastic. Is that a ton of rewriting of code to get them? Like for some reason, applications need to be written in a certain way for the cloud. Is that like what you're saying? Basically? Yeah, this is when you're getting into like cloud native development and you go look at like CNCF. Um, you'll hear about like, you know, Kubernetes, KubeCon.

59:16
CNCF, there's all these projects that are out there. The cloud native landscape. And so from an application perspective, So when you build your applications,

59:42
You're abstracting even further away the underlying hardware. And that's where the application has to be written in a certain way. Written in a microservices environment. If you do microservice, yeah. If you, if you build what would be called a monolithic application where like, Hey, I'm going to throw everything in this VM and give you a VM image. And you deploy that sitting in one place and sitting in it's all there. It can't be distributed all over the day. Exactly. What's, what's the name of that? Super cool. So you blew my mind.

01:00:11
when we were talking about cloud a while back and you showed me that picture in it. So what is it called and what is it? It's all the services that you would need to basically be a cloud. It's the CNCF landscape. And so, um, I'll drop a, I'll drop a link in the chat for, for the folks that are here, it's basically a compilation of kind of like all, most open source, a ton of open source projects. There's a ton of momentum behind.

01:00:37
the CNCF, the Cloud Native Computing Foundation, right? And so, you know, they just say here that like, there's a market cap of 21.1 trillion and funding of $66.8 billion to these projects. Majority of them are gonna be open source. This is where, you know, this is where you'd kind of come to to go develop and build microservices of your own. Doesn't mean this is the only spot.

01:01:06
So real quick, so as an application developer, when you tell me I have to build an application in a microservice architecture, my application has to be able to talk all these languages or it has to be able to like, what is this picture I'm looking at? We'll put the link, you know, in the show notes that people can pull it up, but yeah. What does it mean to be a microservice? So these are various different projects that are like, you know, call them on GitHub or whatever the idea is that these are, these are code projects. These are, you know,

01:01:34
code written to develop the software that run on containers. This is like behind Google search, for example. we talked about scaling problems, right? to my application residing on 5,000 containers, making it up. Everything's management issues, you know?

01:02:04
And that is the introduction of container management platforms, i.e. Kubernetes. And now we're way deep in the dark path, Andy. Yeah. So, uh, three hour session with you. But this is basically what microservices were to look like if you put it on one piece of paper here, right? Like this is distributed architecture, Kubernetes, containerization. It's all that crazy stuff that.

01:02:33
Makes me feel like an imposter. Well, just think too, this is a different space than we're all used to is like this. This is application development. This isn't network engineering at this point. I can't stand those people showing. I don't understand. They always, they always blame the network and they come up with this damn stuff, which is like, Oh my God, what, what is happening? But basically at your old job, you went to them and said, these three applications, we have to, I didn't go to them. They have to support. That's their.

01:02:58
They're chief architect, they drive that. We're putting this in the cloud. We can't just lift and shift. We need to make this able to work in a microservices environment. And then they do whatever the hell they do to make that work. Right. Exactly. So all the public cloud providers say they have all these services. They take all of these things and they develop services as well. And those public cloud environments that they turn around and offer as products for you to be able to use. And they wrap additional tools and things around it. They provide support.

01:03:24
and they do all these things so that you can go use them in their environments as well. And so, yeah, that's absolutely it. This is like the amount of technological advancement that we've been seeing for the last few years and that we'll continue to see, quite frankly, is being driven largely by these projects and people that are going on GitHub and elsewhere. They're writing code to these repositories and contributing to them.

01:03:54
and doing a lot of application software development here. And it's super impressive to watch what comes out of this. All modern applications you're going to see, doesn't mean all applications, but all modern applications are going to be built around microservices architecture. It's been going on for some time. It'll continue. Last question for me, because I know we're just about there. Can you put a monolithic application? So the opposite of microservices is a big monolithic, right? Could you put that in the cloud? Yeah.

01:04:23
but it'll just be so damn expensive because it can't be elastic. You could go run it in the cloud. You can run it on VMs just like you would inside of your data center. Right. But, but the, they're not going to be highly efficient. And so what happens is like you carve out and you reserve some CPUs and memory and you turn around and run those, run those VMs. You know, most of the time, like, you know, a lot of those like monolithic applications are meant to just always be on.

01:04:51
There's no concept that whereas like, you know, in microservices, right? It's like, Hey, there's more demand over here for this service. I have 50 containers supporting that. Well, I'm going to do this like scheduling stuff, and I'm just going to automatically spin that up based on some instructions you gave me at some point. And I'm going to spin that up to all the containers that I need. And, and then when the demand dies down, right, I'm going to, I'm going to draw that back down. Think about like amazon.com on prime day. Yeah. There's a ton of containers in the background that are like, Oh crap.

01:05:19
Tons of people are coming to our website. Tons of people are going to the cart. They're checking out all these transactions. It's different than what we usually do, right? What's happening is in the background, there's all these services. There's all these microservices that are turning around and spinning up independently of one another to handle that load. If you tried to do that with a monolithic application, like you'd break.

01:05:43
You just couldn't handle the work, you know, the demand in the workload. So, and because it's more efficient running microservices, I'm guessing it's, it's more cost effective, right? Because you're not running. Yeah. Balls out all the time. You know, the elastic, it spins up when you need it, it all stops. And when it stops, you're not being billed for usage, right? Yeah. That's the idea. As long as it shuts off. Right. And then you set up your parameters, right? That's the idea, right? And you think about like, well, what happens when a container fails? Well, it's the orchestrators job. Most of the.

01:06:12
the de facto standard today's Kubernetes to say, Oh, I'm supposed to have this container fail. Let me just start a new one replicates exactly the same one that was there. Oh, you want to update software that you just replace the containers that were there with the new code. There's no like, well, I go into that VM and I write new code that I add to the service. Everything is declarative and everything is, um, you know, it, it, it basically like gets deployed. It lives when it dies, it dies and gets replaced and you just, yeah, it's pretty impressive. Wow.

01:06:41
Sean, this has been such a fun conversation. I feel like there's so much meat left on this bone. We could probably go for episodes and episodes and episodes and episodes and episodes. But unfortunately we do have to wrap it up. If you've been listening to this conversation and you've been enjoying it, we would really appreciate you giving us a like subscribing, you know, smashing the bell icon, all those things really help us in our stats and helps to tell other people about the show. So.

01:07:10
If you could do those things, we would so greatly appreciate it. Sean, if people want to learn more about you and follow you, where can they find you? Yeah, you can find me on Twitter at Sean LV. Sean spelled funny, so S-H-E-A-N L-V. And I recently joined Mastodon, but I have not been on there very much, but it's the same or close to it. I don't even remember the handle. Yeah, it's in my Twitter bio. Awesome.

01:07:35
Awesome. And Sean, if people want to get started with Cloud, where's a good place to get their footing? Is there some good resources that you think you could recommend to help people understand a lot of... If there's people that listen to tonight's conversation, it was like, wow, are there some places that we could send people to kind of understand more of what we're talking about tonight? Sure. Yeah, great question. So I'm a pretty big fan of A Cloud Guru, right? I know they've been bought by Plurisight.

01:08:04
Go look at their content. They have some great kind of like intro to cloud content. Quite frankly, all the top cloud providers, AWS, GCP, and Azure have good intro courses as well. I tend to actually not, like I just gravitated towards the one in GCP and AWS, probably the most. Yeah, I would start there. I think GCP does a really good job of it. So that's probably where I would start. A lot of their training is free.

01:08:32
The other one too, like if you're not familiar with it, Coursera has some great courses. That's actually where I got like a lot of my certification studying done was through Coursera. The part that I like about it is they're directly integrated into Qwiklabs, which is owned by Google. So if you want Google courses, you basically get like, you're deploying stuff inside Google Cloud, and it's just an account that you don't pay for, right? So you pay for the Coursera class.

01:08:58
but you're not paying for it's basically like a, an account in GCP that doesn't get billed to you. And it has really good like follow along instructions, but you know, I'm very much like theory is great. Love theory. I also need to know how to implement it. I just like things that are tangible that can get touch and feel. Um, yeah, that's what I'd recommend. All right. Well, we will drop those links in the show notes. And if you're watching it on YouTube, you can get those links in the description and including the link that Sean was talking about earlier.

01:09:26
landscape.cncf.io. That is just a really cool page. So we'll make sure to drop that in the description and the show notes as well. Sean, thanks again so much for joining us and we'll see you on the next episode of the Art of Network Engineering Podcast. Thank you.

01:09:46
Hey there friends, we hope you enjoyed listening to that episode just as much as we did recording it. If you want to hear more, make sure you subscribe to the show and your favorite podcatcher. You can also give that little bell rascal a little ring-a-dingy so you know when we release new episodes. If you're social like we are, you can follow us on Twitter and Instagram. We are.

01:10:07
at Art of Net Inch. That's Art of N-E-T-E-N-G. You can also find us on that weaving web that is the internet at ArtOfNetworkEngineering.com. There you'll find our show notes and some blog articles from the hosts, guests, and other friends who just like getting their thoughts down on that virtual paper. Until next time, friends, thanks for listening.