इस एपिसोड के बारे में
Ever wondered how to design a cost-effective cloud network? Buckle up as the Cables2Clouds team, along with the ever-insightful William Collins, shed light on the labyrinth of cloud pricing. We'll dissect the costs associated with data, requests, and additional resources, providing you with tools to anticipate and contain expenses. More than just cost, we delve into the resources your applications are using and the implications of scaling. Our aim? To save your budget, while ensuring smooth sailing for production applications.
Keeping tabs on cloud costs, especially for larger businesses adopting the cloud, can often feel like acing a mind-boggling puzzle. Don't worry, we’ve got you covered. Alongside our guest, we tackle the challenges of being cost-conscious in network design, and explore the necessity of understanding how applications communicate to optimize costs. We discuss the pros and cons of various models and delve into the emerging automation tools and cost calculators that can help you become more cost aware. With over-engineering in cloud networking design being such an easy thing to do – is it really necessary, or just an expensive habit?
Venture with us as we explore the differences between how the different CSP's handle high availability and disaster recovery, and the associated cost implications. We’ll also take a look at the ever-changing landscape of compliance requirements in cloud networking. Spoiler alert: these can significantly bump up costs. Arm yourself with insights about understanding cloud documentation and communicating requirements and solutions to your business. Join us for an enlightening, no-nonsense discussion on cost optimization in cloud network design
Links:
Infracost- https://www.infracost.io/
Nick Matthews Twitter thread about VPC Lattice- https://twitter.com/nickpowpow/status/1645493575189430272?s=20
Where to find William Collins:
Twitter: https://twitter.com/WCollins502
LinkedIn: https://www.linkedin.com/in/william-collins/
Blog: https://wcollins.io/
Previous episode with Will: https://www.cables2clouds.com/2129055/12609925-ep-7-terraform-for-the-network-engineer
Purchase Chris and Tim's book on AWS Cloud Networking: https://www.amazon.com/Certified-Advanced-Networking-Certification-certification/dp/1835080839/
Check out the Monthly Cloud Networking News
https://docs.google.com/document/d/1fkBWCGwXDUX9OfZ9_MvSVup8tJJzJeqrauaE6VPT2b0/
Visit our website and subscribe: https://www.cables2clouds.com/
Follow us on BlueSky: https://bsky.app/profile/cables2clouds.com
Follow us on YouTube: https://www.youtube.com/@cables2clouds/
Follow us on TikTok: https://www.tiktok.com/@cables2clouds
Merch Store: https://store.cables2clouds.com/
Join the Discord Study group: https://artofneteng.com/iaatj
इस एपिसोड में
नोद्स दिखाएं 🔗
अनुलिपि 🔗
00:00:00.180 --> 00:00:02.540
Welcome to the Cables to Clouds podcast.
00:00:02.540 --> 00:00:23.484
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.
00:00:23.484 --> 00:00:27.827
We would like to empower those professionals with the tools and the knowledge to bridge the gap.
00:00:28.821 --> 00:00:31.969
Hello and welcome back to the Cables to Clouds podcast.
00:00:31.969 --> 00:00:35.448
My name is Alex Perkins and I will be your host for today's episode.
00:00:35.448 --> 00:00:41.009
Joining me, as always, are my two illustrious co-hosts, chris Miles and Tim McConaughey.
00:00:41.009 --> 00:00:42.411
Chris, how's your week been?
00:00:42.612 --> 00:00:43.093
It's good man.
00:00:43.093 --> 00:00:45.026
Yeah, man, not much going on.
00:00:45.026 --> 00:00:50.926
The World Cup the women's World Cup is going on here, which is nice, so I've been watching a few of those games.
00:00:50.926 --> 00:00:57.604
There's obviously been a lot of tourism people come to support and things like that, which is super cool.
00:00:57.604 --> 00:01:01.670
So, yeah, I guess, go team USA.
00:01:01.670 --> 00:01:05.468
I usually don't root for the USA, but in this scenario I will.
00:01:06.239 --> 00:01:06.641
Will allow it.
00:01:06.641 --> 00:01:19.043
The women's World Cup is funny because it has the double negative of being soccer in the US and also being a women's sport, so it's like double.
00:01:19.043 --> 00:01:20.245
Nobody watches it, right?
00:01:20.245 --> 00:01:27.472
If you look at the women's US national team, they crush every World Cup man.
00:01:27.472 --> 00:01:28.984
How many times have they won now?
00:01:28.984 --> 00:01:32.584
They kill it dude, and people just don't watch.
00:01:32.584 --> 00:01:34.406
It's really kind of sad actually.
00:01:34.626 --> 00:01:35.248
Yeah, it's crazy.
00:01:35.248 --> 00:01:40.602
They're like world-class athletes that absolutely run the game but on their game and don't get any clout for it.
00:01:40.602 --> 00:01:41.265
It's crazy.
00:01:41.265 --> 00:01:44.766
Yeah, they're insanely talented.
00:01:45.239 --> 00:01:47.007
Yeah, compared to the men's team.
00:01:47.007 --> 00:01:53.043
Right, you watched the men's team and I can't remember the last time we made it past the semifinals in the men's World Cup.
00:01:53.043 --> 00:01:53.745
Anyway.
00:01:54.126 --> 00:01:55.549
All right, Tim.
00:01:55.549 --> 00:01:55.990
What about you?
00:01:55.990 --> 00:01:58.847
I know your trip to Japan is coming up quick, right.
00:02:00.563 --> 00:02:05.808
Yeah, actually that's why we're stacking these right, Because we want to make sure we have enough content to cover it while I'm out of country.
00:02:05.808 --> 00:02:10.770
So Chris mentioned we're recording a few of these kind of back-to-back.
00:02:10.770 --> 00:02:17.669
So yeah, there's not going to be a lot new to talk about, but yeah, I mean, I'm like a week out now, so it's getting real.
00:02:17.669 --> 00:02:20.304
We're getting all the stuff.
00:02:20.304 --> 00:02:28.126
Doing our last-minute Amazon shopping for stuff that we forgot to need to throw in the luggage and all that stuff.
00:02:28.126 --> 00:02:29.187
Man, I'm excited.
00:02:29.588 --> 00:02:29.870
Nice.
00:02:29.870 --> 00:02:34.987
Well, I hope it's awesome and I'm sure you're going to have plenty to talk about when you get back and we record an episode.
00:02:34.987 --> 00:02:36.169
Yeah, all right.
00:02:36.169 --> 00:02:41.330
So we also have a returning guest today that will be joining in our roundtable discussion.
00:02:41.330 --> 00:02:43.545
His name is William Collins.
00:02:43.545 --> 00:02:51.164
If you want to know more about Will, he was a guest on episode 7, which was Terraform for the network engineer.
00:02:51.164 --> 00:02:54.508
So, will, what have you been up to since last we spoke?
00:02:54.508 --> 00:02:55.129
Anything new?
00:02:56.039 --> 00:03:05.068
I think you might know, but my summer break kids are out of school and my in-laws are in Pennsylvania, so my wife flew out there spending some time there.
00:03:05.068 --> 00:03:06.645
So I've got the house all of myself.
00:03:06.645 --> 00:03:11.191
So I'm ripping out carpet, putting in vinyl plank, trimming painting.
00:03:11.191 --> 00:03:15.691
It's been such a not-relaxing quiet house.
00:03:15.691 --> 00:03:17.626
So, yeah, I keep in busy.
00:03:18.100 --> 00:03:18.562
I was going to say.
00:03:18.562 --> 00:03:23.849
I keep seeing you posting pictures of, like, tearing everything out and your workbench all ready to go.
00:03:24.695 --> 00:03:25.180
Exhausting.
00:03:25.180 --> 00:03:34.691
I've been starting at like 8, 9 PM and just kind of like working until midnight, like on the weekdays, and then this last weekend I just killed it Saturday and Sunday all day long.
00:03:34.691 --> 00:03:40.207
So trying to get finished, I'm going to drive up and pick them up, probably spend a few days there.
00:03:40.207 --> 00:03:44.304
Get some sun, nice Take at least some time to relax.
00:03:44.664 --> 00:03:46.127
Yeah, yeah, all right.
00:03:46.127 --> 00:03:52.211
So today's roundtable episode is about being cost aware when designing cloud networks.
00:03:52.211 --> 00:04:06.850
The cloud is not cheap, as we discussed in our recent episode around economies of scale, so the plan today is to talk about some of the things we should be looking out for and maybe some of the compromises that may have to be made in the name of saving costs.
00:04:06.850 --> 00:04:14.445
So to kick it off why is it important for network engineers to think about cost when designing cloud network solutions?
00:04:14.445 --> 00:04:17.827
And since we're the guests, we'll go ahead and kick it off with you.
00:04:18.309 --> 00:04:26.206
All right, Cloud is not cheap at all and just like on-premises.
00:04:26.206 --> 00:04:43.543
We came from the world of building data centers and we had a good idea of OK, we got circuit costs, we have our hardware, we have our procurement, we kind of know what's going on and we're planning till we have like a six-year refresh cycle on something it's not a lot to keep track of.
00:04:43.543 --> 00:04:44.827
So you get into cloud.
00:04:44.827 --> 00:04:45.610
It's different.
00:04:45.610 --> 00:04:53.293
You know VPC, Lattice, recent AWS release at the last year's re-invent comes to mind.
00:04:53.293 --> 00:05:07.569
If you look at the just understanding the resource costing, you know you have the charge of, you know, data that you're moving, your gigabit charge but then you get charged per hour and per the number of requests as well.
00:05:07.569 --> 00:05:10.608
So you have three different charges that you're dealing with.
00:05:10.800 --> 00:05:14.329
So if you're a network engineer, you've got to understand.
00:05:14.329 --> 00:05:16.466
You've got to understand that foundation.
00:05:16.466 --> 00:05:18.807
You got to understand what you're building.
00:05:18.807 --> 00:05:21.247
There's going to be a lot of applications running on it.
00:05:21.247 --> 00:05:25.369
You're going to have just to worry about the scale.
00:05:25.369 --> 00:05:29.470
You're going to have to worry about these costs inflating and blowing out the spend.
00:05:29.470 --> 00:05:32.468
And you know, once that's in place it's like concrete.
00:05:32.468 --> 00:05:36.129
Good luck ripping it out because you're going to have production applications running.
00:05:36.129 --> 00:05:45.247
So, yeah, being aware of how the resources work and how the charging for the resources you know works, and understanding what you're going to use them for as well.
00:05:46.422 --> 00:05:49.511
So you know solving the right problem with the right solution.
00:05:49.800 --> 00:05:51.687
So so a quick question on that right.
00:05:51.687 --> 00:05:56.752
So you mentioned under VPC, lattice and understanding, like the requests and stuff.
00:05:56.752 --> 00:06:01.151
Do you think that that is going to be the responsibility of the network engineer?
00:06:01.151 --> 00:06:03.901
I know the answer is it depends, right, and it's going to be.
00:06:03.901 --> 00:06:05.889
Every organization is going to be different.
00:06:05.889 --> 00:06:07.841
But in your mind, what do you think Like is that?
00:06:07.841 --> 00:06:15.269
How do you bridge that gap between the network engineer doing that and then talking to the application owner that should be giving you that information?
00:06:15.649 --> 00:06:16.831
That's a good question.
00:06:16.831 --> 00:06:20.252
Yeah, it depends, but the you know VPC lattice was.
00:06:20.252 --> 00:06:26.656
I mean it was ultimately invented so devs or cloud platform teams didn't have to worry about the network.
00:06:26.656 --> 00:06:36.264
There was a thread ages ago I'd have trouble trying to dig it out, but it was from Nick Matthews a long time ago about you know a long thread about why VPC lattice.
00:06:36.264 --> 00:06:47.151
Because I think he was on the product team that you know started teasing that out and building out the requirements for it and yeah, I mean it's you know, these, these network folks, these salty network folks, are slow.
00:06:47.190 --> 00:06:49.853
They always just say, no, we want to get moving.
00:06:49.853 --> 00:06:56.819
So it's supposed to empower devs to really, you know, move on their own without having to worry about the network.
00:06:56.819 --> 00:07:09.230
But every time I've seen something like that released into the wild and devs take over, yeah, there's always some gotchas and some catches that someone else should have caught that spilling mayonnaise on it.
00:07:09.230 --> 00:07:10.211
You know, it just happens.
00:07:10.973 --> 00:07:15.456
I'm glad you said it, because this isn't a, this isn't, obviously not a VPC lattice episode.
00:07:15.456 --> 00:07:19.740
But when you asked that question, Alex, I was thinking the exact same thing.
00:07:19.740 --> 00:07:23.343
Actually, the first I was thinking it was well, the question really is, who's going to own VPC lattice?
00:07:23.343 --> 00:07:25.225
Is it going to be the developers or is it going to be the network engineers?
00:07:25.225 --> 00:07:25.605
But that's a whole.
00:07:25.605 --> 00:07:26.485
It's a whole different episode, right?
00:07:26.485 --> 00:07:26.725
But yeah, so.
00:07:26.725 --> 00:07:32.151
So I like what you said about the, the, the concrete, the foundation and all of that, and it's, it's, it's a whole different episode, right, but yeah, so.
00:07:32.151 --> 00:07:40.321
So I like what you said about the, the, the concrete, the foundation and all of that, and it being just a pain in the asterisk up once you've laid it.
00:07:41.141 --> 00:07:56.021
But to get for your original question, Alex, about, like you know, network engineering and specifically being cost conscious in the cloud, you know it's, it's, it's like the data center, it's like when we were in the data center, but it's so much different, right, Because now you can't see the cables.
00:07:56.021 --> 00:07:56.600
You're not.
00:07:56.600 --> 00:07:59.365
You're not, you're not filling racks of gear, right, You're not.
00:07:59.365 --> 00:08:02.550
There's not 32 rack units, rack units to fill up with gear.
00:08:02.550 --> 00:08:04.432
It's.
00:08:04.432 --> 00:08:08.278
It's worse, right, Because it's like the ultimate micro transaction game.
00:08:08.278 --> 00:08:09.680
Now you know so.
00:08:09.680 --> 00:08:12.245
So do I have to pay, and you start stacking the charges.
00:08:12.245 --> 00:08:23.302
Right, that's 0.005 cents per gigabit per hour, oh, but if you go across availability zones, you know, tack on an extra 0.001 per gigabit per hour, and you know if you're going to egress.
00:08:23.302 --> 00:08:27.005
I mean it's, it really is just like the stack, stack, stack, stack, stack.
00:08:27.589 --> 00:08:32.221
It sounds small at first, right, but you start adding all these pieces together that nobody's thinking about.
00:08:33.211 --> 00:08:34.532
Yeah, no kidding, yeah, it's, it's.
00:08:34.532 --> 00:08:52.376
It's like this purely consumption model where you didn't have on prem right Because, you know, while you know, certain hardware vendors might be licensing you to, you know, use specific ports on the, on the kit that you've already bought from them, but it's they're not charging you egress on how much you push through that port right.
00:08:52.376 --> 00:09:01.570
That's, that's a foreign thing that we've, all you know, had to adapt to, to, you know, invest in whenever we design these networks right.
00:09:01.570 --> 00:09:04.600
We got to we got to consider cross AZ traffic.
00:09:04.600 --> 00:09:07.570
We had to consider cross read and traffic egress on prem right.
00:09:07.570 --> 00:09:22.932
And the number one question is I work with customers all the time and one of our main questions we ask at the beginning is you know what, what, what are your, what are your expectations as far as you know throughput and you know egress and things like that, like what are you pushing today?
00:09:22.932 --> 00:09:25.519
And most of them are like no idea, they have no clue.
00:09:25.538 --> 00:09:39.570
So, true, yeah, it's, it's it's it sucks because it's something you obviously have to do, because it's something you obviously have to consider when you move to the cloud, but you don't have the, you don't have the data to project what it's going to cost in the first place, and I think that's that might be why people have that sticker.
00:09:40.272 --> 00:09:41.456
You don't know what you don't know.
00:09:41.736 --> 00:09:42.158
Exactly.
00:09:42.198 --> 00:09:45.052
Yeah, yeah, and so I'm just going to add a point here.
00:09:45.052 --> 00:09:58.942
That's kind of like an underlying theme is right, it's really important for network engineers especially to understand how all the other things interact, because, like we were talking about with lattice, nobody really knows where things get handed off right.
00:09:58.942 --> 00:10:15.203
It's kind of just, as you notice, we all have something to say about this, which means a lot of the time things just get thrown onto the network and, oh, they'll figure out how the applications talk to each other, and that means we're expected to know how to optimize cost as well, and sometimes that's that's much more difficult than it sounds.
00:10:16.272 --> 00:10:16.993
Yeah, for sure.
00:10:16.993 --> 00:10:36.644
I mean, and and you know, not only do we have to optimize and try to figure out how the app works in order to optimize it and in the cloud that might be a little bit easier because of the whole loose coupling model should, in theory, make it break out the monolith a little bit more, even though it makes networking even more important than it ever was.
00:10:36.644 --> 00:10:47.482
You know, on prem, for even just the basic connectivity that an app used to be monolith, you put it all in one server and you only had to care about oh, it's got to reach out to a database or behind a firewall or whatever.
00:10:47.482 --> 00:10:54.162
Now it's like loose coupled, so you have to know way more about the app than you ever did before and how the app communicates.
00:10:55.789 --> 00:10:58.634
I don't see how large businesses can do it's so hard.
00:10:58.634 --> 00:11:08.549
If you have like multiple lines of business or business units and you're adopting cloud rapidly, how in the world can you do like accurate forecasting?
00:11:08.549 --> 00:11:12.566
It's yeah you the simple answer is really can't.
00:11:12.566 --> 00:11:13.570
It's difficult.
00:11:14.792 --> 00:11:18.977
I feel like I haven't mentioned this word in many episodes, so I'm glad I finally get to bring it back.
00:11:18.977 --> 00:11:23.125
But service mesh this always brings me back to I.
00:11:23.125 --> 00:11:26.570
There's got to be some kind of tie in, especially, like, tim, you were mentioning microservices.
00:11:26.570 --> 00:11:39.278
There's got to be some kind of way that someone will come up with to tie in you know, like service registry type stuff into cost is going to happen at some point, so I will continue to stand on that.
00:11:40.139 --> 00:11:40.380
Yeah.
00:11:40.750 --> 00:11:44.293
All right, so what options do people have to gauge cloud spend?
00:11:44.293 --> 00:11:52.081
And you know, feel free to touch on this can be single or multi cloud and specific products.
00:11:52.081 --> 00:11:57.206
You know non cloud native will call them, versus, like, a CSP native solution.
00:11:57.206 --> 00:12:01.821
What are, what are some of the things you guys see, tim, you want to start with yourself this one.
00:12:02.570 --> 00:12:06.115
Yeah, I mean so I forget what the acronym is.
00:12:06.115 --> 00:12:10.182
I think it's what CFN or something like that the cloud financial, something or other.
00:12:10.182 --> 00:12:11.123
There's there.
00:12:11.123 --> 00:12:11.604
There are.
00:12:11.604 --> 00:12:13.270
What am I thinking of?
00:12:13.270 --> 00:12:14.351
Is it apt to you?
00:12:14.912 --> 00:12:28.666
I forget the name of some of the ones out there that basically, will go dig through your it's not up to you, will go dig through your AWS cloud watch logs and like ingest it and spit out reports about how you know how you're spending and stuff like that.
00:12:28.666 --> 00:12:39.780
I remember before, before too long, I kind of just forgot the name, but there's several out there that that's all they do, right, they take, they take the telemetry that you know, say AWS or Azure or whatever.
00:12:39.780 --> 00:12:47.134
You're capturing it and you're sending it to the cloud native log ingestion engine, whatever is they'll, they'll pull it out or you export it or whatever.
00:12:47.134 --> 00:12:57.570
You have a job exported to them and then they produce some rich reporting about you know, hey, you're, you know these lines of business or these accounts are spending this much and there's I mean, it's a big industry.
00:12:57.570 --> 00:13:00.614
There's actually quite a lot of money in the money, if you will.
00:13:00.974 --> 00:13:02.676
Yeah, and you also got to pay for those services.
00:13:03.256 --> 00:13:03.537
Oh yeah.
00:13:03.837 --> 00:13:05.158
Yeah, I can come in here next.
00:13:05.158 --> 00:13:06.160
I've got a few thoughts.
00:13:06.160 --> 00:13:27.683
So the one one good thing is, of course these cloud providers have they're like, api, first, you know, with everything that they're doing, whereas, like on premises, you have, like, maybe, different vendors some are CLI based summer, some might have API, like you have all these different pockets of stuff that operate so differently, but in cloud you have these API.
00:13:27.683 --> 00:13:33.109
So there's a lot of you know like CSPM, cloud security, posture management.
00:13:33.109 --> 00:13:40.418
I know this isn't necessarily a cloud like a costing tool, you know, but something valuable that I've learned and I've seen.
00:13:40.418 --> 00:13:46.085
You know a lot of enterprises you know come to the conclusion of is it's good to know what's out there?
00:13:46.085 --> 00:13:57.340
A lot of times, because cloud it's just so easy to deploy things and things were getting deployed way back like 10 years ago and you've got all these AWS accounts, you've got resources everywhere.
00:13:57.421 --> 00:14:00.024
Okay, like, how many internet gateways do we have out there?
00:14:00.024 --> 00:14:03.009
Or how many you know security groups do we have out there?
00:14:03.009 --> 00:14:03.570
How many not gateways?
00:14:03.570 --> 00:14:09.235
And a lot of times you know you might have a ballpark guesstimate.
00:14:09.235 --> 00:14:20.768
But when you take that a step further and you're like, okay, maybe I'm multi cloud, you know how, how is this working across multiple clouds, how many gateway types everywhere, and those things have a tendency to.
00:14:21.308 --> 00:14:22.350
And then, and then you see these.
00:14:22.350 --> 00:14:27.297
You know these tools come in and they get all this data, they bring it back to and they show you.
00:14:27.297 --> 00:14:30.741
You can build some queries and okay, I have this many internet gateway.
00:14:30.741 --> 00:14:33.785
And you can say, okay, I don't need this many internet gateways.
00:14:33.785 --> 00:14:34.908
That's actually a problem.
00:14:34.908 --> 00:14:39.033
You know securities sweating they're gonna gonna sleep good that night and you know.
00:14:39.033 --> 00:14:41.054
So you want to get that under control, and that you know.
00:14:41.054 --> 00:14:43.298
It's always important to know what's out there to.
00:14:43.298 --> 00:14:45.299
And then you know the cost.
00:14:45.299 --> 00:14:59.976
And another thing too, it's I'm not a big advocate of just the percent or the approach of saying, hey, we'll just buy something off the shelf to do that after we've got millions of dollars of cloud stuff running like the.
00:14:59.976 --> 00:15:05.381
The real focus and the real strategy has got to be, you know, whatever they call it, shift left.
00:15:05.602 --> 00:15:09.466
You want that to be integrated before things are getting deployed.
00:15:09.466 --> 00:15:10.932
So you want to get that under control.
00:15:10.932 --> 00:15:15.356
That should be the number one focus, unless there's some security events you're dealing with.
00:15:15.356 --> 00:15:23.505
So get it under control before it gets deployed because, like we sort of tease out earlier, once it's deployed, good luck.
00:15:23.929 --> 00:15:26.552
Well, how do you think that impacts the the whole?
00:15:26.552 --> 00:15:39.548
You know what sort of looking for the value prop of agility though, because I agree with you, by the way, I do agree with you, especially as a network engineer, I agree with you with the idea should be that it should be an iterative process.
00:15:39.548 --> 00:15:45.614
You know, we dip our toes in, we get a good idea of, especially we don't already know for what our apps are doing, for example.
00:15:45.614 --> 00:15:59.331
You know we need to find that out and we need to do it before we're committed to a certain architecture and before we've spent $10 million, but it seems like that would necessarily slow down the, the whole agility and the value prop for the cloud there.
00:15:59.731 --> 00:16:01.854
Yeah, it does, and that's the thing.
00:16:01.854 --> 00:16:15.145
Like I was having a it was a good spirited debate, I would say with someone about automation in the cloud and my my take on it was, yeah, automation can make you go fast.
00:16:15.145 --> 00:16:28.509
But I see, like the real value proposition of like automation is building in standards into that code and like locking certain things down so you're deploying the same thing and you know what the security posture is, again and again and again.
00:16:28.509 --> 00:16:29.671
So you know it's.
00:16:29.671 --> 00:16:42.258
You have that reference architecture, like I'm not doing it to go really fast, I'm doing it to have really good standards that marry back to some blue printer design, like a design pattern that I have.
00:16:42.258 --> 00:16:51.840
So that going that direction, yeah it's, you're not doing it with an agility first approach and just like with cloud, you've got the benefits of scale.
00:16:51.929 --> 00:17:08.175
You've got the benefits of, ok, you can make DR happen much quicker, like if we're doing DR like 15 years ago, it's like, ok, we're ordering circuits, we've got to, you know, spin up another data center Maybe we have another data center and be their active standby, maybe we want to go active, active.
00:17:08.175 --> 00:17:10.198
We've got a lot of different things happen there.
00:17:10.198 --> 00:17:12.490
You know Zerto is doing circuit grooming.
00:17:12.490 --> 00:17:17.198
We've got some outages, we've got all this stuff going on, that's just.
00:17:17.198 --> 00:17:19.643
You know it's it takes forever.
00:17:19.643 --> 00:17:28.980
So when you kind of like looking back and, you know, looking at perspective, if you look at like where we were versus like where we are now, we're still really agile.
00:17:28.980 --> 00:17:41.640
But we want we don't want to go so fast and create a mess that impacts the business in the bottom line because you still have to sell or whatever your, your market is, and you've got to be efficient and you have competitors in your market.
00:17:41.640 --> 00:17:46.442
So you've got to, you know, stay in that that competition, stay in the hunt.
00:17:46.750 --> 00:17:47.959
Yeah, I mean, these are all.
00:17:47.959 --> 00:17:49.710
These are all awesome, awesome points.
00:17:49.710 --> 00:18:06.982
So, Chris, do you have any, any specific products that come to mind, or anything you know if customers are using and again, that's single or multi cloud, and they can be non CSP vendors that that provide them, or or CSP native tools?
00:18:07.769 --> 00:18:10.118
Not necessarily not nothing that hasn't already been called out.
00:18:10.118 --> 00:18:13.925
I think that is a is a space that is, I mean.
00:18:13.925 --> 00:18:14.690
I mean it's not lacking.
00:18:14.690 --> 00:18:22.130
There's definitely plenty of companies are going to tell you how much you're spending, but that forecasting and that design pieces, it's hard, to hard to incorporate.
00:18:22.130 --> 00:18:24.198
So, no, not not much to add there.
00:18:24.691 --> 00:18:40.099
If you Google, like cloud financial management, I think, which is the M I could remember with the most for do there's so many companies you've never heard of but, like there, they all say like you know, we'll look at your cloud, we'll ingest the details and we'll tell you where you're wasting money.
00:18:40.099 --> 00:18:41.375
We'll tell you how to save money.
00:18:41.375 --> 00:18:47.499
Like I think of, like the CSP native ones, like what is it and is it inspector or advisor?
00:18:47.499 --> 00:18:48.454
It's advisor?
00:18:48.454 --> 00:18:53.980
I think that does the that'll look at your like, running instances and make recommendations on sizing and stuff.
00:18:53.980 --> 00:18:54.703
Like that too.
00:18:55.527 --> 00:19:03.469
Yeah, yeah, and the one that comes to mind for me that you were talking about we'll look at through all your contracts and stuff is a duck bill group Right.
00:19:03.628 --> 00:19:03.809
Oh yeah.
00:19:03.910 --> 00:19:20.604
You always see Corey Quinn on everywhere just posting things, and they had some tweet recently I think the CEO posted it that they saved like some hundred millions for customers over like a quarter or something.
00:19:20.604 --> 00:19:24.039
That's how insane, which is insane costs balloon.
00:19:24.789 --> 00:19:28.181
More than the GDP of a nation in the cloud savings.
00:19:29.171 --> 00:19:31.711
And then there's only one more thing I wanted to call out and will.
00:19:31.711 --> 00:19:34.700
I think you might have told me about this a long time ago.
00:19:34.700 --> 00:19:37.198
There's like a tool called in for cost.
00:19:37.198 --> 00:19:45.210
So is this it's like a CLI or not a CLI like a automation tool, right that you add into some of your automation pipelines?
00:19:45.210 --> 00:19:45.551
Is that?
00:19:45.551 --> 00:19:46.455
Am I understanding that right?
00:19:46.810 --> 00:19:50.000
Yeah, so the my, my idea of what the value prop is.
00:19:50.000 --> 00:19:58.582
So look, developers, you know honestly they're not going to care about cost, it's not the first thing that they're thinking about, or even your cloud platform teams, like they're.
00:19:58.923 --> 00:19:59.990
They're building infrastructure.
00:19:59.990 --> 00:20:03.881
They're trying to support the business, trying to support product teams or something.
00:20:03.881 --> 00:20:08.172
And you know another thing that I know about developers is they don't like spreadsheets.
00:20:08.172 --> 00:20:09.516
They're not going to be.
00:20:09.516 --> 00:20:13.756
You know tallying cost and you know looking at price sheets and stuff.
00:20:13.756 --> 00:20:16.574
They just you know it's not their world, they're not accountants.
00:20:16.574 --> 00:20:22.796
You, you hired these Rockstar developers to write Rockstar code that is going to transform your business.
00:20:23.289 --> 00:20:32.152
So one of the you know, I got really obsessed a long time ago because I had this idea that, again back to my point of like, trying to catch things before they get in there.
00:20:32.152 --> 00:20:36.113
But like, how, how can you inform, how can you enable?
00:20:36.113 --> 00:20:40.458
Like, instead of instead of ringing them over the neck like, look, you spent this much, you left this on.
00:20:40.458 --> 00:20:41.954
You did these things.
00:20:41.954 --> 00:20:57.042
You know how do you empower your, your technical staff, with the tools and the know how to see how much something is going to cost, so what Infra cost does, and you can stick it in your pipeline, like if you use GitHub actions, or like Azure DevOps.
00:20:57.042 --> 00:20:58.268
That's not DevOps.
00:20:58.268 --> 00:20:58.789
I don't remember like.
00:21:01.163 --> 00:21:02.349
Azure Intra DevOps maybe?
00:21:02.349 --> 00:21:04.619
Yeah, like the 5003 name.
00:21:04.619 --> 00:21:08.076
But yeah, you can just build another stage in that pipeline.
00:21:08.157 --> 00:21:23.202
So the infrastructure you're going to deploy, maybe you accidentally you choose the biggest instance possible and then it'll calculate how much that's going to be over a given period of time and pop up for the person that has to do, like usually if you're doing some sort of code review you're not going to do your own.
00:21:23.644 --> 00:21:33.067
You know, pull request, You're going to have two or three other reviewers, so maybe either you see that and you're like, oh, that's so expensive, I don't want to do that, or you know the reviewer does.
00:21:33.067 --> 00:21:41.145
You know AKA, you get, you know, you catch it before it gets pushed into an elevated branch and makes it out in the wild.
00:21:41.165 --> 00:21:41.690
That's a really cool idea.
00:21:41.690 --> 00:21:42.219
That's what it does.
00:21:42.228 --> 00:21:46.307
It just sees what you know the costs are for the infrastructure out there and what you're going to do.
00:21:46.628 --> 00:21:50.681
Yeah, maybe you have like a finance person doing one of the approvals or something you know.
00:21:51.436 --> 00:21:54.116
It's kind of if it hasn't happened yet, it's coming Recently.
00:21:54.660 --> 00:22:06.369
I don't know how long they've had this feature, but there's also an estimated cost, like if you're using a service like Terraform Cloud, like whenever you run your speculative plans in Terraform Cloud there's an estimated cost for the infrastructure you're deploying.
00:22:06.369 --> 00:22:09.326
Don't know how accurate it is and don't know.
00:22:09.326 --> 00:22:12.576
You know where that data is actually pulled from, and etc.
00:22:12.656 --> 00:22:13.558
Yeah, estimate it.
00:22:13.940 --> 00:22:25.699
Yeah, right, but yeah, so that's another cool thing where it's incorporated into the deployment pipeline right, where you see it ahead of time, which is, you know, that's very useful to have, assuming that it's correct.
00:22:25.951 --> 00:22:27.659
Yeah for so much using OpenAI.
00:22:27.659 --> 00:22:35.993
There there's a lot of tools that are piggybacking on the AI revolution and I've it's getting better and better, like some stuff.
00:22:35.993 --> 00:22:37.720
You know I've tested a ton of stuff.
00:22:37.720 --> 00:22:46.536
You know some of it started out pretty rough but it's getting better and I think in you know you're going to see the accuracy you know just continue to climb For sure.
00:22:47.790 --> 00:22:49.416
Yeah, those tools are only going to get better.
00:22:49.416 --> 00:22:52.369
Okay, Chris, we'll give you this next one.
00:22:52.369 --> 00:22:57.481
So how do we design a cloud network with minimizing costs in mind?
00:22:57.481 --> 00:22:59.516
Like what are some of the strategies there?
00:22:59.938 --> 00:23:11.642
Yeah, I think the easiest thing to call out is that you do need to kind of be aware of that consumption model that we've touched on already whenever you're developing these designs and things that you're doing.
00:23:11.642 --> 00:23:27.442
Right, because I've seen common deployments where you know customers just think, oh, you know, we're deploying this many different VPCs across this many regions, et cetera, right, you know each one of these VPCs we're deploying needs access to you know, s3.
00:23:27.442 --> 00:23:29.535
So we're going to throw an S3 endpoint in there.
00:23:29.535 --> 00:23:33.354
You know they need access to the internet for patches, so we're going to throw Nat Gateway in there.
00:23:33.354 --> 00:23:40.435
Right, but if you're doing all these things on a per VPC basis, you pay hourly for all these services, for all these endpoint services, for.
00:23:41.057 --> 00:23:42.401
Nat Gateways things like that.
00:23:42.401 --> 00:23:47.582
So obviously the price of that can scale up very quickly, right.
00:23:47.582 --> 00:24:07.097
So, you know, I think people need to maybe consider this kind of more centralized model where there's you know, you need to consider what goes into your shared Services piece of your network versus, you know, scattered across all your entire landscape, right, just to bring down those hourly costs.
00:24:07.097 --> 00:24:14.038
I feel like that's the easy grab bag, so I'll throw that one out there, but yeah, yeah, yeah, that's interesting.
00:24:14.710 --> 00:24:26.317
Specifically, you talk about the Nat Gateway model as egress and then like a centralized model, because I was actually thinking of something very similar and getting into the cost aware piece of it or designing for costs.
00:24:26.317 --> 00:24:37.280
There's just so many different ways that the cost is figured into it that it makes it very difficult, even when you know what the flow is going to be, to actually accurately predict.
00:24:37.280 --> 00:24:41.983
Like, for example, I've got 10 VPCs, I've got workloads in every VPC.
00:24:41.983 --> 00:24:48.344
Is the cheapest thing to do to put a Nat Gateway in every VPC and have that Nat Gateway?
00:24:48.344 --> 00:24:50.412
You know, do egress have those workloads?
00:24:50.412 --> 00:24:51.556
Egress directly to the Internet?
00:24:52.171 --> 00:24:56.560
Let's set security aside for the moment, because obviously that is a whole other thing, right?
00:24:56.560 --> 00:24:59.538
Or, you know, should I centralize it?
00:24:59.538 --> 00:25:09.121
And if I centralize it, should I centralize it in such a way that you know I'm trying to minimize VPC peering or am I using VPC peering?
00:25:09.121 --> 00:25:11.156
Is there a transit gateway that I need to be involved?
00:25:11.156 --> 00:25:16.672
You know, am I worried about cross AZ and egress charges and like?
00:25:16.672 --> 00:25:22.382
It's actually extremely challenging, even when you know the end to end flow.
00:25:22.402 --> 00:25:33.919
Sorry, the transit gateway thing is awesome, a good call out, because maybe people don't know this, but there are actually regions that don't even have transit gateway yet.
00:25:33.919 --> 00:25:52.675
This is really my point is, you know, you have to also keep pay attention and like, keep up with new products and how things change and future announcements that come out because of things like whatever region that doesn't have a transit gateway, they're going to be doing things differently and then one day it's going to become available.
00:25:52.675 --> 00:25:57.121
You know, somebody's got to remember to change the architecture after.
00:25:57.351 --> 00:25:58.494
Oh yeah, that's huge.
00:25:58.776 --> 00:26:04.973
Right, like that's a big one, that, and there's no way to standardize that, so that's huge.
00:26:04.973 --> 00:26:06.318
Going back to it, yeah.
00:26:07.150 --> 00:26:23.300
I think, thinking to I most companies I talk to have some sort of direct connect, interconnect, express route, fast connect thing which is, you know, you're led to like, hey, we're not going to use internet for everything, we want to have this private network and we want to, you know, bring that back.
00:26:23.300 --> 00:26:34.443
Usually, most of the time, I see it as a they have a lot of data on premises, they're going to do like migrations, they need some like a big pipe to, you know, pipe everything up to the cloud.
00:26:34.443 --> 00:26:41.454
But a lot of times it's like, oh, we're going to start with 10 gig, we're just going to, you know, it's just like in the days of the VMs.
00:26:41.454 --> 00:26:54.246
I mean, I, I'm guilty of this when I, when I would request a VM in the data center, it's like, oh, I'm going to dial up the specs on this and make sure that you know I'm taking care of it, because I don't know how long it's going to take for them to update it If I need it.
00:26:54.246 --> 00:26:56.170
Up to, you know, change management.
00:26:56.371 --> 00:26:56.932
Overbuild it.
00:26:56.932 --> 00:26:58.816
Yeah, we've all done it.
00:26:58.816 --> 00:26:59.758
Yeah, yeah.
00:27:00.125 --> 00:27:01.670
He'll abuse that power a little bit.
00:27:01.670 --> 00:27:04.428
But with express routes and direct connects.
00:27:04.428 --> 00:27:15.053
And you got to think, if you're you're co-loaning it out to connect to cloud, you want to be mindful of all the hardware that you're you're putting in that co-load because you're going to have to refresh it.
00:27:15.053 --> 00:27:20.851
Um, and if it's just you know like, look, if you need to drive to the grocery store, like you don't need to go buy a Ferrari.
00:27:20.851 --> 00:27:24.224
You know you can ride a bike or get a Toyota Camry.
00:27:24.325 --> 00:27:25.746
They're great cars, you know.
00:27:25.746 --> 00:27:26.869
I haven't a long time ago.
00:27:26.869 --> 00:27:28.647
It lasted forever Reliable.
00:27:28.647 --> 00:27:29.913
Is you know anything else?
00:27:30.125 --> 00:27:31.551
That's that's a good point.
00:27:31.551 --> 00:27:44.553
So, uh, this is like a sub point, but and anyone can chime into this Do you do you think there's a tendency to over engineer solutions Because it's so easy to do in the cloud and you literally just click a box, like we've talked about this before?
00:27:44.553 --> 00:27:46.683
You click a box and you have a global CDN Right.
00:27:47.567 --> 00:27:50.718
It's so easy to to overdo it on purpose.
00:27:50.718 --> 00:27:53.673
Yeah, I mean, I don't think there's any question, right?
00:27:54.393 --> 00:27:55.909
No, definitely no question they.
00:27:55.909 --> 00:27:58.384
They for sure make it very easy and inviting for you.
00:27:59.088 --> 00:28:05.981
Yeah, and it depends on who's clicking the button to or who's doing what Cause in like what level of you know control.
00:28:05.981 --> 00:28:10.462
They have to do it without, like change management and a proper set of eyes on things.
00:28:10.462 --> 00:28:12.464
You know, the more that gets deployed out there.
00:28:12.464 --> 00:28:14.071
And here's the thing.
00:28:14.071 --> 00:28:17.627
Like, whenever you deploy, you have stuff going out in the cloud.
00:28:17.627 --> 00:28:22.704
Networking oftentimes is like the last team to know about some stuff going down.
00:28:22.704 --> 00:28:25.699
It's like, oh, we're the last people invited to the party.
00:28:25.699 --> 00:28:26.644
You know, stay away.
00:28:26.644 --> 00:28:26.904
That's true.
00:28:27.869 --> 00:28:32.664
So then, when we get invited to that party, there's a lot of stuff that's already going on and they don't want to have to go back and do rework.
00:28:32.664 --> 00:28:42.099
So then, just like in the data center days, we're expected to come in and we have to do what we have to do to make it work, and part of that is a lot of times.
00:28:42.099 --> 00:28:46.984
Overengineering is something that should have been simple from the beginning, but hands are tied, can't do anything about it.
00:28:48.028 --> 00:28:50.842
I worked for a company that had a homegrown.
00:28:50.842 --> 00:29:12.144
It was a homegrown app that was a full CRM like did everything in it, and that app was written so poorly that we had to build our infrastructure to be the whole network infrastructure, pretty much, and all the server infrastructure as well pretty much had to be like one and a half times what we actually needed, just to just to like it was a hog, right.
00:29:12.144 --> 00:29:16.988
So like you had to overbuild it and this was in the data center with real, with real gear, right, so that it's it's.
00:29:16.988 --> 00:29:17.369
You know.
00:29:17.369 --> 00:29:20.929
So let's, let's not forget that that happens in the cloud as well.
00:29:20.929 --> 00:29:27.768
You know, like, if you're in a cloud, you know you're in a cloud, like especially with the lift and shift, where you're going to take an app, you haven't refactored it.
00:29:27.768 --> 00:29:31.146
You're going to pick up that monolith and that hog and drop it in the cloud.
00:29:31.146 --> 00:29:37.914
You're going to have to overbuild quite a bit, actually, even at the network layer potentially, you know, to deal with that.
00:29:37.914 --> 00:29:38.916
That's it.
00:29:39.265 --> 00:29:43.036
God, the dumpster fire lifting into the cloud man.
00:29:43.036 --> 00:30:02.551
People don't realize that a dumpster fire on-prem is one thing, because you at least can kind of finagle things, but yeah, you lift it into the cloud and it's like some things just might not even work, some things you really have to get super creative to find a solution to make it have that same behavior.
00:30:02.551 --> 00:30:03.959
That's, that's a good one.
00:30:03.959 --> 00:30:04.484
I like that.
00:30:04.969 --> 00:30:23.944
And it's going to cost like 10 times right, because it's all consumption model based and you've got something like, for an example, you have at this app say like I don't know it's a CRM or whatever, and say to retrieve customer data, instead of being efficient about it it's got to go talk to the database, like 30 calls to bring up one page of customer data.
00:30:23.944 --> 00:30:27.135
Like you know, that's all egress or not egress.
00:30:27.135 --> 00:30:29.724
Sorry, potential cross AZ charges.
00:30:29.724 --> 00:30:31.625
You're going potentially through load balancers.
00:30:31.625 --> 00:30:36.136
There's like a thousand little micro transactions happening every time you make a database call.
00:30:36.787 --> 00:30:38.662
Yeah, throw DR in there and you're really up.
00:30:38.662 --> 00:30:42.865
Oh yeah, because like okay, are the resources going to be deployed at half master?
00:30:42.865 --> 00:30:47.585
They're already going to be running, or are they not running and we're just going to turn stuff on if something happens?
00:30:47.585 --> 00:30:54.304
You know, because if you're running a whole bunch of stuff that isn't getting used in like an active standby scenario, you're eating that cost, you know.
00:30:54.304 --> 00:30:55.371
Or is it active?
00:30:55.371 --> 00:30:56.598
Active, you know?
00:30:56.598 --> 00:30:57.545
Just, it depends.
00:30:57.545 --> 00:30:58.585
It's expensive, though.
00:30:59.509 --> 00:31:02.224
In this same vein, I'll ask the next question.
00:31:02.224 --> 00:31:07.684
So it's about how do we weigh availability against cost, as we would on prem.
00:31:08.212 --> 00:31:08.865
I'll let you all go first.
00:31:08.865 --> 00:31:10.444
I got a lot to say on this one.
00:31:10.987 --> 00:31:12.614
Yeah, as I say, you're talking about it a lot.
00:31:12.614 --> 00:31:21.730
I guess you know, like I said well, you've made a lot of good points on this is you know there's a lot of hardware lifecycle.
00:31:21.730 --> 00:31:26.565
There's just a lot of things that are already established that you have to think about.
00:31:26.565 --> 00:31:32.151
There's like a cadence to how things work on prem right and I guess, in the cloud.
00:31:32.151 --> 00:31:36.353
It's just so different you really have to think about.
00:31:36.353 --> 00:31:41.684
You don't have to worry about the refresh cycles, but you have to worry about things that are going to change in the future.
00:31:41.684 --> 00:31:46.290
There's just so many different things to think about.
00:31:46.290 --> 00:31:54.505
Cross AZ traffic, you know availability, zone going down, region's going down, so it's really just a lot different yeah.
00:31:55.788 --> 00:32:03.655
And a lot of times I see a lot of designs that aren't using like availability zones the right way within a single region.
00:32:03.655 --> 00:32:09.306
You know, because you think about it, high availability is like in the cloud world.
00:32:09.306 --> 00:32:15.279
High availability is like what would be on premises with two switches sitting next to each other.
00:32:15.279 --> 00:32:19.615
You know active standby or firewalls, active standby, active active, whatever they are.
00:32:19.615 --> 00:32:21.763
You know you have one, it goes down.
00:32:21.763 --> 00:32:25.065
Well, then you have another one and that's cloud with AZs.
00:32:25.065 --> 00:32:27.625
It's, you know, high availability.
00:32:27.625 --> 00:32:30.500
It's not DR, even though they're separate data centers.
00:32:30.541 --> 00:32:44.464
It's, it's a there's a big distinction to make there, but then when you want to go DR, you have to go to another region, and even the way the cloud providers do this is different, because AWS is like building with Legos.
00:32:45.651 --> 00:32:49.364
I remember that one blog from I think it was Netflix back in the day, but it really is.
00:32:49.364 --> 00:33:04.545
But if you go to like Azure, okay, like we're dealing with paired regions now that go back to the cadence of them upgrading and doing things within their environment, so there's not shared fate there, so there's a lot of different things that you have to consider.
00:33:04.545 --> 00:33:12.545
And then doing this again like there's a big distinction also with hey am I look, I'm designing the next Twitter.
00:33:12.545 --> 00:33:22.484
I need this sucker to be available everywhere all the time with, you know, capacity, you know imagine that that the Twitter app that wasn't flaking out all the time.
00:33:23.528 --> 00:33:28.521
I was going to say if somebody needs to design it, if you're going to do it, you better get to it quick.
00:33:28.521 --> 00:33:29.464
We need it yeah.
00:33:31.031 --> 00:33:32.137
But I mean the enterprise side.
00:33:32.137 --> 00:33:33.545
It's much more difficult because you're not.
00:33:33.545 --> 00:33:36.525
You're not, you're not developing the next Twitter.
00:33:36.525 --> 00:33:45.288
A lot of times you have a, you might have the bread and butter your bread, bread and butter of your business that needs to be available, like across the U?
00:33:45.288 --> 00:33:50.881
S or maybe the East region, but then you have a lot of low hanging fruit and really it has to be a thing of you know.
00:33:50.881 --> 00:33:51.525
What do you want to pay for?
00:33:51.525 --> 00:33:54.537
What is the availability that you want to pay for?
00:33:54.537 --> 00:33:56.545
What are your DR requirements?
00:33:56.545 --> 00:33:58.452
There's a lot of metrics there.
00:33:58.452 --> 00:34:00.172
We need to sit down and understand them.
00:34:00.172 --> 00:34:06.400
Usually, the answer I would always get is we need it to be up a hundred percent of the time right, we can't pay for five nines.
00:34:06.746 --> 00:34:09.534
We can't pay for five nines, but we need a hundred percent uptime.
00:34:09.534 --> 00:34:13.371
I mean, that's a tale as old as time, right that that just followed us straight into the cloud.
00:34:13.371 --> 00:34:18.606
That has always been the infrastructure builders like dilemma, right the business.
00:34:18.606 --> 00:34:21.934
Once five nines of uptime, they give us the budget for like three and a half.
00:34:22.596 --> 00:34:27.990
Yeah, and you can say that you can show them like hey, well, actually just take this and double or triple your cost.
00:34:29.588 --> 00:34:30.009
There you go.
00:34:30.409 --> 00:34:36.193
That's your cost, that's how much it costs, and then usually the response is well, actually, let's think about this.
00:34:36.233 --> 00:34:41.213
This isn't in the budget, so yeah, and then the whole region goes down, and then everyone blames you anyway, right.
00:34:42.585 --> 00:34:52.356
When I worked for that same company actually there was we did this thing with hybrid cloud because they didn't want to pay to put you know like a direct connect in or whatever.
00:34:52.356 --> 00:34:54.391
So it was all like site to site VPN stuff, right.
00:34:54.391 --> 00:34:58.135
So like the web web front end was in the cloud but all the databases were on prem.
00:34:58.135 --> 00:35:09.150
And I remember there was a critical P one incident where you know, like it broke, essentially like the VPN broke, it was it wasn't on our side, it was on, I think it was AWS.
00:35:10.166 --> 00:35:17.974
Anyway, long story short, I'm doing the, the after action report, like the, the, whatever you want to call it, to see process improvement.
00:35:17.974 --> 00:35:24.545
And I went in there and I was like you know this, this is what, this is the level of service you paid for.
00:35:24.545 --> 00:35:29.545
So you know, there's never really I have, no, I have no process improvement.
00:35:29.545 --> 00:35:37.378
We know what we, we, we told you what it would take to get better redundancy for this or high availability, whatever you want to call it.
00:35:37.378 --> 00:35:44.103
You know, essentially, the business signed off on the risk by not investing it and you know, made the financial decision, but it's the cloud.
00:35:45.226 --> 00:35:49.132
I think I actually said I think I actually said welcome to the cloud when I was done.
00:35:49.132 --> 00:35:50.094
Thank, you.
00:35:50.275 --> 00:35:50.637
You know what.
00:35:50.637 --> 00:35:53.085
To that point, I got one more point on this question.
00:35:53.085 --> 00:35:57.304
So one of the things I really were I spent a lot of time doing this.
00:35:57.304 --> 00:36:00.739
This was several years back and it kind of went nowhere, which was unfortunate.
00:36:00.818 --> 00:36:09.648
But in in cloud, everything had like every individual thing has an sla, but then when you put those slas together, you get a bigger sla for something.
00:36:10.210 --> 00:36:26.228
So when you think of in terms of what a business cares about like they don't care about the sla for a direct connect, they don't care about the sla for a circuit or a you know some component in the cloud so most applications out there, if you're in the enterprise, it's hybrid.
00:36:26.228 --> 00:36:29.400
You have something that it's talking to back in your data center.
00:36:29.400 --> 00:36:33.556
You've got something it might be talking to in another cloud or a service somewhere.
00:36:33.556 --> 00:36:55.097
So, you know, trying to build like what I, you know we refer to it as compound sla there's probably a correct term for that but trying to do the best that we could to actually measure and combine all these things and put together a view of what it would look like for the business with this application, like where all the different components are, because that's what they, you know care about.
00:36:55.097 --> 00:36:56.340
Is the app down?
00:36:56.340 --> 00:37:03.019
Yes, that's, that's the problem and that's what'll get scrutinized yeah, and you know, obviously there's.
00:37:03.340 --> 00:37:16.315
There's been points made about the bad design where things are just broken, um in that capacity, but also like, related to that is I think people have difficulties mapping dependencies correctly.
00:37:16.315 --> 00:37:18.059
Um, in that you know.
00:37:18.059 --> 00:37:27.159
You, let's say, you're deploying resource a and resource b and resource b depends on resource a and when you're deploying b, you're like, oh, we need to build this.
00:37:27.159 --> 00:37:32.541
You know, you know five nines, you know to the gills, right, you know it needs your redundancy, needs all this built in.
00:37:32.943 --> 00:37:44.023
But if it relies on something that doesn't have redundancy built in or can't have redundancy just by the way the, the system operates, then you know either you need to fix both of them or to fix none of them, right, you know?
00:37:44.023 --> 00:37:50.565
I mean you, like you can only have have what, what, what, the, what the system is capable of in the first place, right?
00:37:50.565 --> 00:37:55.909
So it's important to make sure that you're um, you know that don't design.
00:37:55.909 --> 00:38:07.751
You know the last piece of the puzzle with the, the biggest um or the most redundancy that you can, when you know the beginning can't, can't, uh, you know, account for that anyway, exactly, and it's so.
00:38:07.831 --> 00:38:16.260
It's got to be so hard to be on a dr team because a lot of stuff is out of your control and you're just trying to pick up the pieces and get teams to change things.
00:38:16.360 --> 00:38:27.541
Yeah, that's a really good point, chris just use microservices, man, and then everything, just you know, will work, and don't worry about the cost, because yeah, kubernetes is just so easy.
00:38:27.842 --> 00:38:34.202
And serverless, yeah, very yeah, server lock in with serverless, don't even need a server I got another interesting one.
00:38:34.242 --> 00:38:38.998
So compliance requirements, um, and I know I don't know will you might want to take this one.
00:38:38.998 --> 00:38:51.719
I know you've worked in, uh, some healthcare organizations, so are there any specific compliance requirements, uh, that they've seen that kind of force cost clouds to go or cloud costs to go higher?
00:38:52.240 --> 00:39:01.865
uh, I could answer this with one word, and it would be firewall yes, so good of course, uh, there's a lot of uh.
00:39:01.865 --> 00:39:15.750
Yeah, I mean so working on like government a little bit, a government contract side and the healthcare space, versus also working on the business, the proper side like we're, you know, even on the the, the, you know, commercial side.
00:39:16.130 --> 00:39:17.896
Really there's so many different.
00:39:17.896 --> 00:39:24.905
Like one of the things that I battled that I never could really get a good handle on is a lot of time security comes to you with requirements.
00:39:24.905 --> 00:39:28.378
They say, hey, this, you know x, y and z has to be done this way.
00:39:28.378 --> 00:39:31.429
And you're like, wow, that maybe doesn't make any sense.
00:39:31.429 --> 00:39:32.833
Why, why is it this way?
00:39:32.833 --> 00:39:38.197
And then like it's a requirement, and you know, I got to the point to where I'd start asking like okay, where's that written?
00:39:38.197 --> 00:39:39.298
Like, where is that at?
00:39:39.579 --> 00:39:40.862
right what, where is that?
00:39:40.862 --> 00:39:42.686
And and start chasing it down.
00:39:42.686 --> 00:39:50.197
And what I found on the you know the, the private side essentially is a lot of times it wasn't actually a requirement.
00:39:50.197 --> 00:39:58.664
It was like, oh, we did this thing for a while and we're just gonna keep doing that thing that way, um, but when you get on the, you you do anything with government.
00:39:58.664 --> 00:39:59.768
That's a different story.
00:39:59.768 --> 00:40:11.813
All together, there's a lot of writing, there's many things in writing and you're, yeah, a lot of things you might not make, you know, may not make sense to you, but you've got to follow them anyway.
00:40:11.813 --> 00:40:31.181
You got to do your best to make sure they're followed, because if you know something slips underneath the cracks, that means some big hits, you know, financially for that company potentially I have some, you caught some things to add to this, but I'll I'll let uh, chris, if you want to jump in or tell him go ahead well, I mean, I think the big.
00:40:31.201 --> 00:40:44.818
I think the big thing is that, uh, like you said, well, there's a lot of compliance stuff, and then what you find a lot of times is that, uh, if you actually chase that rabbit down, depending on who you're talking to with government, it doesn't matter, there's nobody to talk to, it's the government.
00:40:44.818 --> 00:40:54.956
You might as well just walk to talk to a brick wall about why that requirement exists, because somebody passed a law, and then it is 30 years later 30 years later, we have this requirement.
00:40:55.018 --> 00:41:08.702
They have nothing to do with each other, but that's that's why, um, but in a private organization, you know, a lot of times, security teams will, you know, quote certain, you know, pc I or sock to you know, whatever, the whatever.
00:41:08.702 --> 00:41:09.445
That is right.
00:41:09.445 --> 00:41:11.811
Um, but what?
00:41:11.811 --> 00:41:28.672
I think, just real quick, touching on the cost thing as well, um, what I find a lot is in the cloud, security patterns or requirements tend to, you know, just like on prem, uh, affect a lot about how the traffic patterns go.
00:41:28.813 --> 00:41:40.485
And then we've already talked about the, the, you know, the security plus traffic, plus weird traffic patterns that are required to make security work can equal a just a shit ton of money, right?
00:41:40.485 --> 00:41:47.530
So, uh, we need to be able to justify that beyond just saying, oh well, security set its requirement, right.
00:41:47.530 --> 00:41:48.373
I think we're.
00:41:48.373 --> 00:42:08.088
We have to be the good stewards, and a lot of times, of course, infosec may not like to be questioned about it, but you have to be able to say like, yeah, but if I'm using adibus firewall or azure firewall, plus all these traffic patterns, and I'm using, you know, load balancers and all this other stuff, I mean, there's, there's a serious amount of money involved in running that through this.
00:42:08.088 --> 00:42:11.277
Uh stack, you know, and it's just the right way to do.
00:42:11.277 --> 00:42:13.860
It is what is the true requirement here for the business?
00:42:14.340 --> 00:42:15.202
I got to jump in here.
00:42:15.202 --> 00:42:26.769
So do you think you just had a curiosity that security and network teams are going to consolidate at least network security teams networking and consolidate into a single team in the future?
00:42:27.983 --> 00:42:28.585
I think we should.
00:42:28.585 --> 00:42:30.251
I think we should.
00:42:30.251 --> 00:42:31.454
I do think it's a little question.
00:42:31.454 --> 00:42:35.472
I do think we should because I don't think you can have security.
00:42:35.472 --> 00:42:49.681
I mean, you can have physical security, obviously, but if we're talking about IT security or whatever you want to call it data security, every bit of it has to include the network, unless we're talking about, you know, burying a server and disconnecting from the network or something like the network has to be involved.
00:42:49.681 --> 00:42:55.253
So I hope that we will see more blending of the security and network teams.
00:42:55.320 --> 00:43:00.521
personally, Well, I completely agree, yeah, and you know to kind of give them a little bit of credit.
00:43:00.521 --> 00:43:05.112
You know the CSPs things like you know AWS has like gateway load balancer right.
00:43:05.112 --> 00:43:07.003
It actually helps a lot.
00:43:07.003 --> 00:43:10.811
I mean, it makes it very complicated, so that's a different conversation.
00:43:10.811 --> 00:43:20.489
But at least you don't have to worry about adding a firewall to every single VPC or you know just weird things that are going to seriously balloon the cost.
00:43:20.489 --> 00:43:24.240
So I think those are good things on the whole.
00:43:24.822 --> 00:43:25.184
For sure.
00:43:25.184 --> 00:43:27.052
I mean, there's major like that.
00:43:27.072 --> 00:43:52.726
I remember one point to talk about that, like you know that obviously gateway load balancer is a concept that was recently integrated, so it makes me this isn't really, you know, privy to the question, but just kind of the thought that I had is as it makes me wonder about the constant churn that customers have to be experiencing, with new products coming out that you know fill a use case for them, but you know they moved to the cloud when that use case wasn't there, right?
00:43:52.726 --> 00:43:57.322
So are they just in this constant cycle of migrating to new services?
00:43:57.322 --> 00:44:08.815
And and obviously your security posture, or how you're implementing security, can have a big, a big influence on how you implement.
00:44:08.815 --> 00:44:11.722
You know, your networking across the cloud right, until you can.
00:44:11.722 --> 00:44:17.847
And then, if you integrate services like this, then you know it's obviously hard to shoehorn that thing in afterward.
00:44:17.847 --> 00:44:25.775
But I mean, cloud is definitely more fluid than it is on prem, so it's probably easier said than done, but I don't know.
00:44:25.775 --> 00:44:27.099
What do you guys think about that?
00:44:27.862 --> 00:44:28.746
That's, that's great.
00:44:28.746 --> 00:44:30.652
I just lost my thought.
00:44:30.652 --> 00:44:34.266
I had a point I was going to add on, so feel free if anyone else has something.
00:44:34.608 --> 00:44:36.054
Yeah, I went through the trans.
00:44:36.054 --> 00:44:47.688
I mean just thinking of all the different network and the gateway designs, like going from just VPNs to transit VPC to transit gateway, all in like six years, like like just like PTSD.
00:44:47.688 --> 00:44:50.231
It was terrible and it was very expensive as well.
00:44:50.650 --> 00:44:51.713
Yeah, that was the point.
00:44:51.713 --> 00:44:58.467
So yeah, tim, or sorry, chris, to your point about the customer having to handle these things.
00:44:58.467 --> 00:45:05.710
It's not really the customer, it's the network and security teams, right, Like the devs don't care if transit gateway came out, okay, who cares?
00:45:05.710 --> 00:45:06.431
Right?
00:45:06.431 --> 00:45:08.382
So that's another thing.
00:45:08.985 --> 00:45:09.365
Exactly.
00:45:09.989 --> 00:45:13.481
And then super quick and then we're going to wrap up the government stuff.
00:45:13.481 --> 00:45:23.789
So like tick, tick requirements, man tick 3.0 is all about kind of having like distributed points of presence, with adding the cloud into this.
00:45:23.789 --> 00:45:32.179
That basically means that you do have a firewall everywhere and it's just like the government's always behind on these things.
00:45:32.199 --> 00:45:38.240
But yeah, I mean, it's part of the mandate, it's just how they designed it and it makes sense why they did it.
00:45:38.240 --> 00:45:49.153
But man does it require just some serious ballooning costs and thinking about the architecture and weird ways and it's just some mess your tax dollars at work.
00:45:49.996 --> 00:45:54.990
Yeah, and banking industry right, there's so many other industries that have weird compliance requirements, like banking too.
00:45:54.990 --> 00:46:01.335
Yeah, okay, so let's, we're going to go ahead and wrap it up here.
00:46:01.335 --> 00:46:04.567
I know we could talk longer, but we've got to cut it off at some point.
00:46:04.567 --> 00:46:07.980
So, real quick, we'll go around and get any last points.
00:46:07.980 --> 00:46:10.849
Whoever wants to kick it off will.
00:46:10.849 --> 00:46:12.452
Or Chris, do you guys want to chime in?
00:46:12.813 --> 00:46:16.849
Sure, yeah, just kind of like with getting certifications.
00:46:16.849 --> 00:46:19.420
Don't ask me how that made its way into this conversation.
00:46:19.420 --> 00:46:22.346
But you think of you just want to go so far, so fast.
00:46:22.346 --> 00:46:24.510
You like, okay, I'm studying for CCNA.
00:46:24.510 --> 00:46:28.748
Oh, you know, I'm going to get my CCIE in like two years or something.
00:46:28.748 --> 00:46:31.923
It's kind of like with cloud, like you've got to start basic.
00:46:31.923 --> 00:46:36.784
You really need to learn the foundations and the documentation is gold.
00:46:36.784 --> 00:46:38.693
The cloud documentation is actually very good.
00:46:38.693 --> 00:46:41.123
I have so many things bookmarked that I refer back to.
00:46:41.123 --> 00:46:43.797
They're always updated, well, usually up to date, you know.
00:46:43.797 --> 00:46:48.253
So learn those foundational things and learn TCPIP while you're at it.
00:46:48.253 --> 00:46:50.922
Like really learn it and that'll that'll take you far.
00:46:51.402 --> 00:46:52.324
Awesome, chris.
00:46:52.324 --> 00:46:53.987
Do you got any any last points to add?
00:46:54.349 --> 00:46:56.532
Not much to add, I will say.
00:46:56.532 --> 00:47:09.286
Typically, when doing designs and talking about solutions and things, cost is my, my the bane of my existence is the thing I want to talk about the absolute least, but thankfully you guys have made it fun today, so I appreciate that.
00:47:09.728 --> 00:47:10.469
Awesome Tim.
00:47:11.715 --> 00:47:47.592
I think the main thing, the main takeaway, if you will, is that you know, when we left on prem, we didn't leave behind the same fight that we've had to have, which is, you know, the business still has to get an outcome and they have, you know, budgeted a certain amount for it, and we have to be really good about making sure that they know essentially what they're buying, like what level of of DRHA you know, makes sense and and at the end of the day, it's not really our call and we need to be okay with that and we need to just make the business aware of that.
00:47:47.612 --> 00:47:48.838
Tim, yeah, absolutely you.
00:47:48.838 --> 00:47:56.465
Definitely you need to know how to articulate it, which brings back to the point we made a couple of times, where you really just need to keep up with this stuff.
00:47:56.465 --> 00:48:06.505
It's changing so rapidly and there's always new, new features and products coming out and new designs and new security requirements and new apps, and just goes on and on.
00:48:06.505 --> 00:48:09.213
So I think I think that's good All right.
00:48:09.213 --> 00:48:13.351
So thank you all very much for tuning into the Cables to Clouds podcast.
00:48:13.351 --> 00:48:16.724
If you liked this episode, please share it around to anyone you think might be interested.
00:48:16.724 --> 00:48:22.726
Give us a five star rating on your favorite pod catcher and hit those like and subscribe buttons on our YouTube channel.
00:48:22.726 --> 00:48:24.170
Till next time.
00:48:24.710 --> 00:48:29.409
Hi everyone, it's Alex and this has been the Cables to Clouds podcast.
00:48:29.409 --> 00:48:31.032
Thanks for tuning in today.
00:48:31.032 --> 00:48:42.282
If you enjoyed our show, please subscribe to us in your favorite pod catcher, as well as subscribe and turn on notifications for our YouTube channel to be notified of all of our new episodes.
00:48:42.282 --> 00:48:45.672
Follow us on socials at Cables to Clouds.
00:48:45.672 --> 00:48:51.063
You could also visit our website for all of the show notes at Cables to Cloudscom.
00:48:51.063 --> 00:48:54.429
Thanks again for listening and see you next time.