Ep 17 - Breaking Down the Importance of Multicloud

Chris: 0:00

Welcome to the Cables to Clouds podcast. Cloud adoption is on the rise and many network infrastructure professionals are being asked to adopt a hybrid approach as individuals who have already started this journey. We would like to empower those professionals with the tools and the knowledge to bridge the gap. Welcome back to another episode of the Cables to Clouds podcast. My name is Chris Miles. I am joined with my lovely co-host, tim McConaughey, and Alex Perkins.

Chris: 0:40

We're going to start today with a little bit of a new show format. We wanted to keep this podcast topical, keep people informed. What we're going to do is not a new concept. We're going to cover the cloud and networking news of the last two weeks, give our takes on it and then we'll roll into the actual episode topic for this week. We're going to try to make this a recurring thing. If you have any feedback on this format, anything like that definitely let us know. First of all, let's get into the news of the last two weeks, probably the big announcement everyone has heard about. No one's been able to avoid this. This is huge news. In the networking community, we have learned that 95% of the NFTs in the world are now worthless. I know this is just crushing news. No one predicted this.

Tim: 1:36

No one saw this coming.

Chris: 1:37

Oh, my God.

Tim: 1:39

That means that there's 5% of NFTs that are worth something Exactly that's the real news.

Chris: 1:47

All my apes are worthless man. This is a bad day. No, no, no. Okay, let's get into the real news, obviously the one everyone's talking about. Cisco has agreed to acquire Splunk. For what was it?

Alex: 2:01

20 something billion 28 billion with a B yeah.

Chris: 2:07

A billion dollars, yeah. So obviously this one hits close to home for all of us, as we are very integrated with Cisco community and, by proxy, probably this Splunk community as well. Splunk has always been that kind of like the cool company. I feel like they always had the cool merch and all that shit, right.

Alex: 2:30

So this is huge. Everyone uses them.

Chris: 2:32

Yeah, exactly, not to say it's not worth it, but how do you guys feel about this one? What's going to come out?

Tim: 2:40

of this. I think they did not spend 28 billion dollars for the Splunk name. I think they spent 28 billion dollars for the Splunk data especially the AI stuff.

Alex: 2:50

Yeah, it seems to be the take that I hear a lot too. I'm super curious about how supposedly it's going to be under two separate orgs security and observability. Interesting Not to throw a whole lot of shade, but sometimes people complain about BU's not really talking at Cisco, and it's going to be very interesting to see how. I've never heard that complain.

Tim: 3:16

You should have, I've made it.

Chris: 3:21

Yeah, we've heard it directly from the horse's mouth on here. Yeah, Cisco's a huge company, right? Nothing's going to be perfect, but that's something they're going to have to tackle. I think everyone was hoping they were going to get the Maraki treatment and get that self-sustaining that the arms length treatment. But it's too much of a power play for Cisco to get into these other markets. Right with the XDR and things like that, right.

Tim: 3:55

I mean, look at the orgs, security and observability. It says everything you need to know, right there. Right, observability you're going to use your AI. Well, first of all, splunk's already there, right? So that's a no-brainer, that one's obvious from an AI perspective. And then look at security, security insights, actual insights, detection, all of that good stuff. Man, you're going to get to leverage all of that model training and stuff that Splunk's already been doing.

Chris: 4:21

Yep, definitely a huge play for Cisco. So we'll see where that one goes. Let's see, alex, what's up next?

Alex: 4:28

Yeah, so we got an article from Sequoia Cap. So, basically, talking about the GPU market, that is just absolutely blowing up. Right, with all the new AI language models that everybody's suddenly coming out with. Right, every company is trying to build their own or build something in the cloud. All the cloud providers are trying to scale up their infrastructure. The market is insane. Will Collins just did an episode that covered some of this stuff too. He was talking to a Bloomberg analyst about it. The market is nuts. It's supposed to be by 2028, something like a couple hundred billion dollars just in annual revenue. Like it's absolutely nuts. What do you guys think about that? Because those numbers are crazy.

Chris: 5:13

The theme is definitely follow the GPUs, right, that's where things are heading. I mean yeah, because even numbers from Microsoft in here are pretty nuts about just what open AI is doing. And what does it say? They expect to generate like 10 billion in revenue just from co-pilot alone, right?

Tim: 5:30

So that's like the Jesus dude, this is nuts dude, I don't want to be that guy, that the prepper guy that goes for the bunker, but sometimes you look at this stuff and you're like we are the architects of road destruction. It's not like I expect a Skynet, but from a privacy perspective and from an information perspective, we're racing, all these companies are racing to capture this money as fast as they can. You know they're blown past every sign on the road, every danger sign on the road, to do it.

Alex: 6:04

Yeah, and it's not even just that. There's also like all these new fabs that are being built everywhere. I think there's like one in Arizona that was just multi-billion dollar facility that's going to be stood up. The chip shortage really exacerbated everything, and then the AI stuff on top of that just made everything go nuts.

Chris: 6:23

Even with this, we had the announcement of Bedrock finally getting announced by AWS, right, which is interesting. I will say it's not actually what I expected it to be with this kind of marketplace of kind of pick your own model type of situation, right. That was interesting to see.

Tim: 6:43

Yeah, we always knew, I think, that models were going to be a product. But it's interesting for AWS to lean right into the model marketplace model, if you will. It makes sense for them right, like the AWS marketplace and that format. But I am interested to see, like, okay, here's your model marketplace and now, okay, you're going to license the models you're going to build, like, how that translates to building apps. That'd be interesting.

Alex: 7:05

Well, yeah, it's super interesting for a couple of reasons, right. One of the things I mentioned in that article is it runs all on serverless, so you don't even have to manage your own infrastructure, right. So it's my first thought was like the costs behind this are going to be astronomical, oh my God. Yeah. But also like the model thing is really interesting because it's AWS and you don't like they have their own model in that marketplace.

Alex: 7:31

So to me it's kind of weird because AWS doesn't really known for digging into their own their own stuff, no, like they release their own model, oh right, and then they're also opening it up for competitors to compete against them. It's just, it's kind of like a weird play for them.

Tim: 7:44

Is it even competition when we're talking about large language models? Though? Like, at the end of the day, like I think about it, I've been thinking about this and I'm like is there any way to even know from a competitive perspective, like, what the hell data have we? Have we been feeding these monsters?

Alex: 7:59

Yeah, it's whatever the marketing department tells you.

Chris: 8:03

I didn't dive too deep into the pricing model that they put out for bedrock, but it appears that, like you know, per the model that you want to use you pay a different per transaction cost type thing. Right, and obviously the I think the Amazon model is way cheaper than the other ones, which makes sense. But yeah, it's interesting, interesting to see how this gets leveraged after this point, can't even imagine the transactional cost of leveraging a line cards language model.

Tim: 8:31

Also interesting in the news, the Linux Foundation has thrown their hat in the ring and they are going to basically jump into the IAC thing and pick up OpenTF, which is now what been renamed to OpenTofu. It's a great name, by the way. My wife loves Tofu.

Chris: 8:49

Tofu a win for vegans everywhere. Brother, I've been waiting for this moment. You guys can bow to me, I am.

Tim: 8:57

I. Now we have to start a competitor, like you know, openb, for something.

Chris: 9:02

OpenMeatKerrit or whatever that Arby's thing was. You remember the MeatKerrit. No, I don't. Oh, dude, Arby's did. We're getting off track now, but Arby's did this ad where it was like they were. I guess they were like combating like these, like plant-based companies putting out meat-type products that they made. They made like a meat carrot.

Tim: 9:23

A meat plant. Yeah, I feel like.

Alex: 9:26

I remember that.

Tim: 9:27

It's so fucking stupid.

Alex: 9:28

Okay, I do, I do remember that.

Chris: 9:29

Like not even that's funny, not even offensive, just not Just like who needs this?

Tim: 9:34

bro, this doesn't benefit anyone Anyway so All right, let's get back on track real quick. So for the Linux Foundation to pick up OpenTF is interesting because of course we know HashiCorp kind of closed, the, you know, became a business license and it kind of closed the Terraform to open source and that's why the Linux Foundation is picking it up. I'm curious to see if the Linux Foundation will attempt anything Like. I mean, they're pretty open and free, but you kind of wonder if they'll build some kind of layering on top of OpenTF, like from a support perspective or anything like that, or I don't know, we'll see, right, we'll see if they go the way of red hat, but probably not. But I am interested to see from a support perspective, who's going to support OpenTF, who if enterprises start rolling it into their stuff.

Alex: 10:24

Yeah, I might get some hate from my opinions on this one here, but it's just weird to me that, like I wrote it in a comment, nine startups, nine startups are going to fund 18 full-time engineers for the next five years. For this. I just I'm very skeptical about that and it just it's a lot, it's all startups. Like anything can happen with a startup, they could all go under in five years, I mean or the opposite could happen, but it's just. I don't know. The whole thing is weird, like it was draw.

Alex: 10:56

Yeah, exactly Right. I mean that's a lot of money right, especially for startups that are already crunched for money. So it's going to be. It's very interesting to watch.

Tim: 11:04

Yeah, we'll have to keep our eyes on this one. And I'm also curious, now that they're going to have this as a competitor to Terraform, what other Terraform competitors or not just that, but just Terraform generally, closing the loop, if you will what other kind of Terraform competitors we'll see finally getting some traction out there?

Alex: 11:22

Well, crossplane, crossplane might get a win from this.

Tim: 11:26

Honestly, Actually they might, yeah, and they have the opportunity, if they seize it, to kind of come in and try to fill that vacuum before something like Open Tofu does. So we'll see.

Chris: 11:37

Yeah, I'd be curious if customers sway, or just by this conflict between the two. I'll be honest, I'm surprised the Open TF, open Tofu thing has gotten to this point this fast just by this outcry in the open source community, which I mean I'll be honest, I'm not as versed in the world of open sources as many people that have something to do with it, but it's like. You know, a lot of people seem like they were predicting like no, this isn't going to. This isn't going to get to this level, it's not going to be forked, and you know it's. It's making a lot of headway, man, it's. I don't know if that's going to cause people to want to go somewhere where there's not turmoil and there's not discrepancy, you know.

Tim: 12:21

But I guess we'll see, yeah A lot of enterprises have already heavily invested and I mean, and vendors too, have heavily invested in Terraform as part of either the offer or the infrastructure. Right, Right.

Alex: 12:34

Yeah, I mean that's, that's it exactly. And like I mean, I mentioned crossplane but also Palumi. Palumi's been going crazy on social media.

Tim: 12:43

If you guys follow anyone that works there.

Alex: 12:46

Man, they've been everywhere.

Tim: 12:48

I'm sure they've been sharpening their knives pretty, pretty hard yeah.

Chris: 12:53

All right, and then the round this out, because I think this is a good segue to our episode. Topic for today is we have a. We have an article from itprocom about the lack of cloud skills exacerbating rising IT cough for businesses. So, yeah, this is. This is kind of oddly enough, this came out after we recorded the episode, but it's a major point that we talked about with the, with the skills gap. So you know in this report that we found that you know the 70, they survey of IT professionals. 70% of the respondents said that cloud related costs for about 30% of their total IT budget, which is, which is which is growing.

Tim: 13:35

Yeah, it only goes up pretty much as people go into the cloud.

Alex: 13:38

I think there's another point in here from Oracle 98%, I think, or was that 98% of companies are going to multiple at least at least two, at least two right, which is like not limited. So we talked about this in the episode, but it's so weird that Oracle is like the only one that seems to have a pulse on this and is actually pushing to do something about it. It's yeah it's perfect for them, Like you know.

Tim: 14:03

Bravo to them, hats off to them, but man they were late to the game, so they have to play. They have to play the game with everybody else, but, but, but it's true, I mean good for them for actually getting it out there.

Chris: 14:14

They're lucky they got in when they did, because, yeah, if you, if you're one of these other major vendors now and you want to start a cloud, right you you're your bar of entry is huge, brother. You got to have a lot built into that, and I spend a lot of money that you probably don't have on hand, right? So, yeah, this is design.

Tim: 14:32

Do you still have a cloud? I don't know. Yeah, they do. I mean they're calling it cloud, but basically right.

Chris: 14:38

Yeah, there was an interesting topic on the on the cloudcast recently about whether or not Nvidia would would start a cloud just based on where they're going. So that's a close for them. I thought that was an interesting to do so.

Alex: 14:52

I totally like I'm not trying to do my own. I was talking to a friend about this like a year ago, as whenever they announced their A 100 or H 100, whatever they're like DPU, like their data center processor unit is, I was like, man, they're going to make a like an AI cloud.

Tim: 15:08

I could just see it.

Alex: 15:09

And it's not really going that way, but but I could definitely see them doing it.

Tim: 15:13

Could be another one. They could have sell it to everybody else. Yeah, yeah.

Alex: 15:16

That's the thing.

Chris: 15:17

Don't. Don't fuck up your supply chain. Stronghold right and might as well keep that where it's at All, right. So that's that's the cloud news of the week. Like I said, you have any feedback on on this segment? Let us know. But let's get into the episode.

Chris: 15:32

So today's episode is about the importance of multi cloud. I think this is something we've been we've been kind of preaching since since we started the podcast. Multi cloud is definitely a thing. Whether or not that, even what that means to some people is, you know, maybe you're hybrid cloud and you know, whatever it's, the, the terminology can can be debated all day, but nonetheless it's a real thing. So, without further ado, let's let's get into the episode.

Chris: 15:59

Welcome back to another episode of cables to clouds. Joining me today are Tim and Alex for a roundtable discussion. Let's get right into it, guys. Today we were talking about the importance of multi cloud, so we kind of wanted to do a show talking about. You know, multi cloud is definitely almost a buzzword at this point. You know plenty of people are talking about it on tech, social media, things like that.

Chris: 16:21

So we wanted to kind of dive into that and talk about what are, what are, the aspects of multi cloud. Why would you choose multi cloud and what are some of the drawbacks? What are the, what are the challenging aspects of it that make it hard to run an enterprise on multiple clouds? Right? So, first thing we're going to do is, before we can get into you know, you know what the benefits of multi cloud, let's talk about some, some terminology, right so, because multi cloud can mean a lot of different things, right? So? You know, we all these terms like private cloud, public cloud, hybrid cloud, blah, blah, blah, right? So let's, let's, let's dive into some of those terms and actually make sure we're on the same page on that. So, tim, you want to start off? So all right.

Tim: 17:03

So let's just start with private cloud, because that's the one we all, we all know and love, where we all come from. Private cloud and, honestly, nobody ever said I'm just got those out there.

Chris: 17:11

Nobody ever said private cloud before before you know there was no World War two. There was, or like there was, no World War one until there was one World War two. Right yeah.

Tim: 17:23

Yeah, yeah, okay, there's no World War One until there was World War Two, got it? That's a good point, very good point, all right. So so public private cloud, rather Okay. So I mean, what is private cloud? We're talking about some kind of virtualized environment, on-prem, owned by whatever organizations running it, like be it VMware, kvm, oh geez, what up? I mean, honestly, I just VMware, so ubiquitous. I'm trying to think, like what?

Alex: 17:50

Yeah, like Nutanix and there's other like HP has some stuff, Dell has some stuff.

Tim: 17:56

Yeah, so, so good point, right? So basically, some kind of virtualized compute slash, networking platform that is a you know ephemeral and run by the organization, so private. Everybody kind of understands the idea of private cloud in contrast with public cloud, right? So yeah, so let's leave that one. We'll leave that one there. And Alex, you want to once you cover public cloud, so let's just cover private cloud.

Alex: 18:21

Yeah, yeah, absolutely, and I'm glad we're doing this, because a lot of people have different definitions for things, especially the hybrid cloud and multi-cloud ones. So I mean, yeah, public cloud is pretty self-explanatory, right. It's public, it's made for mass consumption, Like anyone can just, you know, put in a credit card and start swiping and get services. So it's. Everybody knows about the CSPs, the big three or four, right? Oci, Azure, AWS, GCP, so it's really those big cloud provide the hyperscale cloud providers that are providing a cloud service to everyone else.

Chris: 18:58

Yeah, and I feel like at this point, like the term cloud, if someone just says cloud, that's what they're talking about. They're talking about public cloud, right, and then more.

Tim: 19:06

For the most part, yeah. Yeah, if they omit a specific type, yeah, you could just assume they were defaulting to a public cloud model, probably.

Alex: 19:13

Well, and I just real quick the private cloud one people. You might not even hear people call it private cloud, right, because I've heard this recently that some people with private cloud will say if you're not kind of doing the same kind of consumption model that a public cloud does, they don't really consider it a private cloud. They just consider it like you're on-prem data center right.

Tim: 19:33

Right, or like the automation model and that kind of self-service architecture right, yeah, absolutely.

Chris: 19:40

Yeah, All right. So next up, hybrid cloud. So this one is this one's kind of weird because it's not its own cloud necessarily. It's kind of just the implication that you're running both private and public cloud, right, and there's probably some bridge built between them. I would imagine that hybrid cloud is a subset of multi-cloud, but at the same time, I'm sure there are some people that when they hear multi-cloud, they only think multiple public clouds right. Hybrid cloud doesn't really come into their brain. I don't know how you guys feel. Would you classify hybrid cloud under the umbrella of multi-cloud, or is that kind of? Are we splitting?

Tim: 20:20

hairs. So I think there's like the technical, like the technically correct answer and then like the answer that if you were having a discussion with someone and use the term, what would they think you were talking about? Right? To me, the technically correct answer would be that hybrid cloud is really any two or more clouds connected in some way, right? Usually, when I hear hybrid cloud, it is specifically in context of an on-prem whether there's a private cloud or not, just some kind of on-premises to extra cloud. We'll call it extra cloud, right? Extra public cloud, connectivity to a public cloud is almost always the terminology I see used. What do you think?

Alex: 21:05

Alex, yeah, I agree, and this is the one that for sure people get in trouble with, because I mean, if you think about it, when someone says multi-cloud it can mean the same thing, because if you have a cloud on-prem, you're not saying right. But to me, hybrid is like you have your private cloud and your public cloud. Because it's a hybrid, it's not multi-cloud Like it's I don't know. To me, that's the difference between the two for sure.

Tim: 21:30

Yeah, I like the term extra cloud because we're talking about something where there may not even be a cloud on the other end of the line. Right, it's just something outside of the cloud connected to a public cloud and it doesn't have to be public cloud, right, this is where things really start getting to that whole technical versus what you would hear people talking about, because I've never heard anyone say hybrid cloud when we're talking about connecting their on-prem private cloud to their branches or some other you know what I mean.

Alex: 21:58

Yeah, yeah, that's true. And I mean, just think in the future, when we get things like distributed clouds on the edge right, someone's going to come up with a new term for that, and then it's going to be like, okay, well, what do we call this new model where you have an on-prem cloud and a hybrid edge cloud and a public cloud. So it's going to continue to evolve, for sure.

Chris: 22:16

But yeah, and to your own point about the private cloud, the consumption model and the self-service kind of nature of it anytime someone says private cloud or hybrid cloud, I feel like 99% of the time they are not doing that in their private infrastructure and do not have that type of model built out right, just because it's so difficult to do so. In my mind, when I hear multi-cloud, I think multiple public clouds, because there's the orchestration, there's the kind of almost vending machine options that you have built in there, right. So at least that's the way I interpret it.

Alex: 22:48

Yeah, there's a huge lack of maturity in the public cloud sort of consumption model, but in an on-prem kind of data center for sure, absolutely.

Tim: 22:57

Yeah, I think we've talked about this a couple of times. I don't think we've ever done like a show on it yet. But like the idea of how difficult it really is to take the consumption model and the automation model and the self-service model of a public cloud and actually bring that on-prem and build the. Nobody offers a true off-the-shelf offer to do that in your private cloud. What do you mean? Open stack dude? I mean?

Alex: 23:24

sure.

Tim: 23:24

Yeah.

Chris: 23:25

You want to build it all sure?

Chris: 23:27

Yeah, absolutely Just kidding. All right, so now that we've gotten that out of the way, we at least know what each of these different terms mean, right? So let's talk about the benefits of diversifying the cloud footprint. Right, because no one's going to do it unless there's some major benefit to it, and some of us even work for companies where multi-cloud is a pivotal construct to the entire use case, right? So let's get into that. Alex, you want to start us off. What would you see as some of the major benefits to diversifying your cloud footprint?

Alex: 24:01

Yeah, so I mean one that kind of pops to mind quickly is increased availability, right? There's been a bunch of issues all over the news lately about whole regions of public cloud providers going down. Of course you can also just do multi-region setups, yeah. Yeah, right, I'm not saying it's easy, but there's to me right. If you're going to start spreading across clouds, that's one of the things that you would think about is one provider's having a bunch of issues and you can kind of use another one to fill in that gap?

Tim: 24:35

Yeah, the availability thing is good. Increase availability, like you said. But I mean truthfully I mean I'm kind of poking fun, right, because everybody knows that US East One is kind of like the nerve center of all Amazon, like Amazon's Achilles heel, if you will, but the availability across regions is obviously vastly improved. But even when you start talking about multi-cloud, availability of different clouds is obviously on a completely different level of availability, right.

Alex: 25:04

Well, yeah, especially when you think about what regions are in clouds, like multiple data centers and multiple buildings. I mean, yeah, you're really talking about really moving up the scale. And something I forgot to call out the Azure. I don't know if you guys heard about this Azure issue where they had customers that could not use the East region, I think and they told them they had to use a different one because they were running into capacity issues. Oh yeah, I did see that article.

Tim: 25:30

I did see that article. That's crazy, though right, like capacity, like that's something you don't even like. I mean, I think we're going to see more and more of it as cloud adoption continues to ride, and we talked about this a little bit in our episode. We were talking about, like vendor silicon and the kind of hyperscale, of hyperscale, but yeah, no, that's, that's a very good point too. Like availability on a different level. Not just availability like is the data center there, but like availability like holy crap, can I actually build a resource in that data center? Yeah, absolutely.

Chris: 26:02

So yeah, so that's another one is kind of this, this phrase about avoiding vendor lock in, right.

Chris: 26:09

So I feel like this is this is always kind of like a tricky one because, like, like, there's a question whether or not you are actually avoiding vendor lock in, or whether or not vendor lock in is even that bad given the specific context, but obviously, diversifying across multiple CSPs that provide different SLAs, you know things like that. But that's the thing is like. While this is a benefit, it's also a drawback at the same time, because the least, the least amount of spend you're putting into one CSP, the less discounts you're going to get. I'm sure you know, if you, if you tell AWS or Azure that you're going to take all your workloads out of the upset cloud, put them in there, they're going to give you some some pretty nice discounts to do that. Right, although I'm never in the, I'm never in the actual position where money is exchanging hands, so I don't know exactly how those discussions go, but at least I would like to think that that's. That's what's happening. I don't know how you guys feel.

Alex: 27:08

Yeah, this is one you hear a lot right, avoid vendor lock in and everyone's kind of like yeah, is it really, though Right, because it's.

Alex: 27:16

I mean, there's so many, I don't know. I look at it like there's so many different services as well. It's it's not really, you know. It's not like you're picking a vendor and you're building everything like this, like there's so many different services as well. It's not like just I'm only using AWS for, like this one specific thing. It's just there's so many different pieces that integrate, so it's it's hard to sell that one sometimes. But I definitely hear what you're saying.

Tim: 27:39

Well, and you know one of the drawbacks and the vendors will be very quick to tell you this One of the drawbacks of avoiding vendor lock in is that generally doing so causes you to increase your complexity. You know, in design, architecture, all of that to get to get that avoidance of vendor lock in right.

Chris: 27:59

Yeah, especially because a lot of these services, how you consume them, differs so much, right, like because, like the, you know any serverless offering, like maybe like Lambda or something, the way you interact with that in AWS, it's not like you can just lift and shift that to Azure, right, that's there. There's completely different constructs. Oh yeah, to put that consumption into another CSP, right, so it's like. It's like yeah it, you did avoid lock in, but, like you, you just rub Peter to pay Paul kind of situation, right.

Tim: 28:32

I'm not even sure that, like cube clusters are easy to migrate Like there's. Actually seems like there's very little that's easy to migrate from one, even when it should be like a third party type of situation where it's very easy to take something from one cloud and move it to another cloud. So you're still going to end up locked in, right, you're just locked in. You've locked in less Curious to hear about that.

Chris: 28:53

Yeah, if you're out there listening and you've you've moved cube clusters between CSPs, let us know. We'd like that, we'd like to talk to you because I'd like to know how that, how that experience went for you.

Tim: 29:05

Yeah, I'd love to know how that went.

Alex: 29:06

Yeah, it's funny because you hear about plenty of people that use like within each cloud, they use like the native Kubernetes service. But yeah, I didn't hear anyone that's like, oh, we all used all GKE and then we migrated to AKS or something that would. That would be very interesting to hear about.

Tim: 29:22

I've heard of people saying that they're doing things like standing up cube clusters and then somehow like meshing them or connecting them across clouds, but I, you know it sounds like one of those things that you hear as a science project, like I'm. I'm amazed if you could ever get, like, from a latency perspective, if nothing else, like how the hell would that be a good idea? Like, if you're doing it, let us know, because I would love to understand that architecture.

Chris: 29:50

It seems like one of those situations where, like you get doomed to run on a refrigerator, you know you're like yeah, I got it to work. It's like cool, I mean yeah, but Well, that was fun.

Tim: 30:00

What's next Exactly?

Alex: 30:02

Yeah, there's some cool. There's some platforms that I can think about that are like I don't even want to use the term super cloud, Like you know this, because that's another term but like multi cloud Kubernetes, platforms like Snowflake I don't know if you guys know what Snowflake is. Yeah, it's like a multi cloud storage platform. They use, like Kubernetes, clusters stretched across all the clouds. So people are doing it, but I know for them they're using each cloud's native service. So I don't.

Tim: 30:30

It's not quite the same thing, but but actually that's a good segue because another reason to go for multi cloud would be, like the, you know, for whatever reason, the business or developers or wherever it is, is preferring certain tooling right to build their apps. You know, maybe they prefer Azure. You know, development environment in Azure versus development environment in Google or AWS or whatever, because the services as we've talked about, there's a lot of services that are pretty analogous. But, you know, I think it depends on where people started and what people are into and what they're doing. You know, there's lots of services where developers, like you know what they like, they're working in the cloud they like with the apps they like.

Alex: 31:09

Yeah, 100%. I mean, I think a lot of people think of GCP as like the AI tooling cloud kind of thing. So you know, if you have like a team that does AI development and then you have a team that just is like building public facing websites, like they're completely different, they might just be using whatever service is easiest for them.

Chris: 31:30

Yeah, I think that's going to be an interesting one with how that, how AI evolves, that who ends up having the best tool for developers to work that in? But yeah, it's funny. I mean, we've said this on the show many times like the infrastructure people, like ourselves, we're not the ones that generate the revenue, right, it's all the developers, right. So they get the say. But you know what I'm going to say this like, as many times as us, as you know, networking infrastructure people have been told hey, here's the vendor you're implementing, suck it up, you're doing it. You know, I wish, I wish people would tell the developers that. So it's just like made our lives a little easier, right, I don't know, I don't feel like anything's often shoved down their throats there. It's more like yeah, yeah, if that's the tool you want to use, we'll make it work, type thing. You know.

Tim: 32:17

Well, because they're building the revenue generating material.

Chris: 32:19

You know applications or whatever Right, so give whatever they want, right.

Tim: 32:23

So that's just the way that is, yeah.

Chris: 32:27

So tooling is also obviously a great thing, but so I feel like another thing that can be a great benefit is all these workloads that you're running in order to power these apps. Right, there are, at times, certain benefits to running them in a particular public cloud versus another one, right? Maybe you know, maybe this database service runs best on, you know, the CSP that developed it in the first place, right? Maybe that was the bread and butter for them. How do you guys feel about that workload optimization, like the letting the workloads run where they run best?

Tim: 33:08

Well, I mean, let's not forget about the private cloud we just talked about, right? So there's going to be tons of workloads We've talked about this on the show many times about you know what? About that 24 seven static workload that has to be on all the time? That's you know. Let's learn that in our private cloud and save ourselves a couple of million dollars, right?

Alex: 33:26

Yeah, and man, I'm trying to think so, like AWS, right With their. I always mix up. If it's Nitro or Graviton, which one's which, but they have like their. Is it their Graviton chips and their Nitro instances?

Tim: 33:38

So like they made the.

Alex: 33:39

You know they have custom silicon, so this is like a race forever that's going to be going on between all the CSPs over. Look how optimized our instances are because we build this custom in-house silicon right. So, that's definitely another thing.

Tim: 33:53

Yeah, I mean. And then you know this idea of run some more clothes in the private one. Run, you know, and have them be able to transfer data or interact with the, with the public, you know it gets into the whole hybrid cloud and multi-cloud piece of it as well Because of you know, you're very commonly. I remember at a company I used to work at they put the databases on on prem, you know, for security reasons, and then all the web front end that would reach back to the database was sitting there in you know AWS and so you had a tunnel running to the cloud to do, like you know, callbacks and updates and everything to the database from the web front end.

Alex: 34:29

Yeah, and you know another point on databases that I just thought of OCI, right. A lot of people use Oracle or have historically used Oracle for databases. Oracle is making a huge push lately around lots of multi-cloud stuff and integrating with other clouds, so that's another reason, right, like how Oracle does their databases. But your developers are using GCP, right. You already have a reason to use multi-cloud right there.

Chris: 34:54

Yeah, absolutely. Yeah, I think OCI is probably the number one case for multi-cloud, right? Because of just the amount of specialized workloads that either have to run on Oracle or have been running on Oracle for such a long fucking time that no one's going to try to move it to something else, right? So yeah, that's a totally right.

Tim: 35:13

very good point, yeah that's actually the bit of the poster child and unsurprisingly because of that, we've seen Oracle probably doing the most outreach to try to build that cross-cloud connectivity setup.

Chris: 35:28

Yep, yeah, they've got a huge multi-cloud push, which is a very cool thing to see. You don't see that coming from a lot of CSPs, so kudos to Oracle. I think that's a really good.

Alex: 35:38

I mean some won't even acknowledge that there's other clouds.

Chris: 35:41

Yeah, I know right. Yeah, I'm sure you guys have seen.

Alex: 35:44

One of the vendors always does their presentation and they have this really crappy hand-drawn cloud to represent something else.

Chris: 35:51

Yeah, anybody but us is the other cloud, All right. So any other benefits you guys want to list out?

Tim: 35:58

I mean there's tons right, but we should probably keep this under two hours. Yeah, we could be here for a long time, all right.

Chris: 36:05

so next, let's get into some of the challenges, right? Because obviously, while there are many benefits, there are just like you said, tim there's complexity to integrating Because, let's be honest, the public cloud is a complex environment and the more of them you run, the more complex it gets right, just by nature, right? So let's get into that. Probably we're a cloud networking-focused podcast, so let's get into the most obvious one the complexity of building that connectivity between all those clouds. What points you guys want to make on that? Obviously, there's many different technologies and things like that that come into this. So, yeah, how do you feel? Yeah, it's a lot right?

Alex: 36:47

Do we have a whole episode just for this one question?

Tim: 36:50

Yeah, right, we need one. We should have one.

Alex: 36:54

I just want to start it, tim, you can jump in. I just want to start it, though, by saying I mean, it's complex even in one cloud, right yeah? So just figuring out the right architecture. Do you use a hub and spokes style architecture? There's so much to figure out in just one and it just gets it's not linear, it just gets exponentially harder as you Logarithmic right.

Alex: 37:14

Yeah, logarithmic, exactly that's what I was looking for, thank you, yeah, it just gets way harder. The more you add into it, the more regions, the more clouds you add in, it just gets ridiculous quickly.

Tim: 37:26

So I'm writing a book on AWS with Chris and another guy named Steve and I'm doing a chapter on Direct Connect right now, and the amount of complexity just in that one networking construct could easily fill a book, especially when you throw in all the different type of virtual interfaces and then you throw in the DX gateway I mean I've got a diagram to show illustratively like hey, here's a taste of how complex it can get and it I can't read it. I'm looking at the diagram like, oh my God, I would never want to architect this, I would never want to deal with the looping and the routing associated with it. And that's one cloud and one connection type.

Chris: 38:07

I think that's why AWS created a specialty certification just for the networking piece, because it's very, very complex. Not only that, like the same way as we talked about, like certain you know, serverless services operate differently amongst the clouds. The networking services are also very different, especially from like what's implicitly going to happen when a route is advertised or something like that, right, what the limits are on routes and things like that. So it's the simplest thing can turn into the most complex thing that can completely hose your operation right. So it's integrating.

Alex: 38:46

If you wanted to connect CloudWay and to VWay and to, you know, network connectivity center, you know you have my blessing man, because I know that's going to be a tall task and if you do this stuff, please reach out and we want to talk to you about this, because there's so many different ways to approach this and the different things to think about and needs and use cases. So definitely reach out.

Tim: 39:11

And it needs to be use case driven right. We don't build this stuff for fun. I mean we do it in the lab, build it for fun, but there's always there's got to be a business use case for all of this.

Chris: 39:20

You're not having fun, but yeah when we talk about.

Tim: 39:22

No, of course you're having fun, but I'm just saying, like the business probably has some reason that they God only knows why they decided to do it this way, or whatever, or the developers or whoever it is that's dropping this on your desk and saying make it work. You know, the multi-cloud piece is so complex for the reason you said, which is you can assume absolutely nothing about the way things work between clouds. You have to do every like, almost down to the packet level, type of and routing level of, due diligence for any flow. You can't, because how many times have any of us been burned by setting up a very, very simple connection like something super easy right Between, and then, oh crap, it blew up because of this. This, you know, feature whatever it is, routing limitation packet acts differently in Azure versus AWS. You know, by default.

Chris: 40:12

It's like oh, it's like oh, there's, if you didn't know, there's a rule where you can't build GRE in this specific situation. You're like fuck man, like I didn't know that.

Tim: 40:22

Or in Azure at all. Yeah, that, that yes.

Alex: 40:26

I remember I think a while back, I think it was Daniel Dib on our Discord server was talking about something about AWS uses VXLAN and Azure uses Genev as well. So it's not even like, or maybe it's the opposite.

Tim: 40:41

GRE. I mean, do they use Genev in Azure as well? Actually, I don't know.

Alex: 40:45

I think, it's different.

Chris: 40:46

For Gateway load balancer yeah, for like the.

Alex: 40:47

Gateway load balancer for AWS uses VXLAN, right? No, it's Genev, genev, then it's Genev, okay. So then it's the opposite. Yeah, yeah, yeah. And then Azure uses VXLAN, so it's like there's not even, Not even standard encapsulation.

Chris: 40:59

There's no standard.

Tim: 41:00

There's absolutely zero standard, yeah.

Chris: 41:02

But that's why all these vendors have to build specialized images for integration with Gateway load balancer per CSP, right? So that's why you kind of see you see time like it takes these vendors time to put out these MVAs to integrate with these native services. Right, because they have to. They have to account for all the shit that's happening under the hood, right? It's not just plug and play with everything, right? Unless you want to heavily manipulate it to fit that environment. I think we've the perfect segue into.

Chris: 41:31

The next point is obviously every cloud is very complex, with their networking stack, with their services stack. Everything, and not only the operation of connecting them is a bit complex, but also you. That means the person doing this or the team doing this has to possess multiple skills to know if I'm the Azure guy and then Tim's the AWS guy and Tim's like, oh, just build the GRE tunnel and you'll be done, and we're like, well, no, that doesn't work over here. So you've got to be able to know, you got to have that skill set in multiple clouds and that's that can be a tall order depending on how big your team is. Right, you may not have people that are going to own entire clouds or certain aspects of a certain cloud, et cetera. Right, so yeah, you got to have these. What are they called? It's like the new 10X engineer or whatever the fuck it was called back a few months ago feels like. But yeah, you got to have this diversified skill set as well.

Tim: 42:36

Say, or you do the go the completely opposite way and you build a team or teams like per cloud and that gets insane right. Like it can get insanely expensive.

Alex: 42:46

That's how a lot of people do it, though that's like almost every customer I have that's doing any kind of cloud stuff. They have different teams for each cloud and it's just a mess, that's right. It's so expensive.

Chris: 42:58

And that's and that'll also be that'll also have a direct impact on hiring for your enterprise as well, right, because if you want to bring in engineers that are going to work on all three clouds, let's be honest, maybe there's a lot of engineers that probably don't want to work on all three clouds, right? Maybe they want, maybe they love AWS and they want that's what the thing that they want to own, and so you're kind of shortening your scope on the candidate pool that you're for the jobs that you're posting and things like that, right.

Tim: 43:29

Well, and let's be candid, there's probably not that many engineers out there that could build in all three clouds, either, or three, four, whatever, having a cloud.

Alex: 43:38

It's a special kind of person that has skills to go across all the clouds for sure, absolutely.

Chris: 43:45

And we can probably tell you. I know for sure, probably, tim, and I can tell you, as someone that works for a multi-cloud networking vendor as many times as I've learned something about a certain CSP, I've forgotten something else about a different CSP, right. So it's like there's constant research that you have to do. It's so true, yeah.

Tim: 44:06

You can't do that every freaking six weeks if you're lucky, yeah, I know. No, seriously, I don't want to sweep that one under the rug, right, keeping up with more than even more than one cloud and all of the changes and all of the services and all of the networking stack improvements or changes, it's a full-time job just to keep up with it. Okay, so what about, let me think, what about the common, I guess, the orchestration, automation, consumption models? We know that's different across. That's another big challenge, right, all of the automation engines are different in every cloud, like, for example, cloud formation versus bicep versus whatever. Terraform and things like that go to some degree to be Switzerland and just have providers that do all of them. But even within that, there's so much difference in the resources or the modules that are available per cloud because the cloud constructs are so different. To me that's another huge challenge just of dealing with multi-cloud.

Alex: 45:09

Yeah, that's a really hard one, and I think I've talked about this before. The trend of platform teams, right, You're seeing a lot of these things kind of emerging, like IDPs, their internal development platforms, I think is what it stands for. But they're meant so that you kind of have this front-end interface that everybody can consume and then on the back end, someone has written all this orchestration and automation. It's like you click a button and it's like, oh, in Azure I can deploy my VNet, right, and it's just click a button and drop down. But it's not that simple.

Tim: 45:48

Yeah, you're absolutely right. There are definitely people who build an application that does just that.

Chris: 45:56

Yeah, and it's like I feel like in this situation, specifically with the orchestration and automation, the way that things get consumed per CSP at least from the customers that I've seen it always depends which CSP they started with, and that kind of is the nature that they continue with onto the next CSP, the standard, right. But the funny thing is that's not always the best way to do it in the opposite CSP, but that's you trading the complexity for the simplicity that you already built out somewhere else, right? So yeah, there's trade-offs to everything.

Alex: 46:37

I'm really glad you said this, because I've been trying to think of how to slot this in Governance cloud governance. Man, if an organization starts in AWS and they build out this giant governance framework of how they're going to build different applications within a VPC and then they expand, how are you going to change that governance or adapt it to go to these other clouds? That's a super hard thing to figure out and I don't think I've seen anyone even do it well, because they don't map directly either. So it's very difficult to expand out that multi-cloud governance framework.

Tim: 47:13

Right and not to steal too much from what could be a potential future topic, because there's definitely a lot in here. But look at even the IAM options like the identity access management options between each cloud. They're completely different a lot of the times. The access policy is at all of that right. So if you're going to build governance around that, it's almost like you have to build it separately for each cloud and try to figure out what that overarching policy looks like. So yeah, huge challenge.

Chris: 47:39

Yeah, especially with this, focused on zero trust at this point right, it's integrated at all facets, right, and that's a difficult thing to do, even with native tools. But the CSPs are evolving in that particular realm but at the same time they're doing it in different ways, so it's like having it all under one umbrella is a tough task nonetheless. Yeah, so obviously there's an architecture constraint or difficulty there as well. We already talked about the use of the different cloud services, like we're using CloudWAN or Transit Gateway, and then VWIN Network Connectivity Center, et cetera, right, not to mention even integrating that with your own prem environment.

Chris: 48:31

Just building that architecture in the first place Not even getting into the nuts and bolts on how many routes can I advertise here? Et cetera, right, just building out the architecture in the first place is overly difficult because certain CSPs adopt different kind of topology models, right, maybe you do hub and spoke here whereas it's a different layout in the other CSP, right. So that's tough. But I feel like we're making so much more of a point to not be multi-cloud than we're saying to do multi-cloud, but I promise you that's not the case.

Tim: 49:08

We covered a lot of the benefits. The benefits are, I think, more well-known, but I think the challenges aren't necessarily saying you shouldn't do it, but I think we're trying to say is, hey, you should do multi-cloud and therefore you need to be aware of these kind of challenges that need to be solved.

Alex: 49:28

And we're also coming at it from a networking angle anyway. So for us things are more complex than a developer saying I just needed to deploy my app into a container, what service do I use? There's just different angles of this, so we just happen to see the much more complex side of things, I think.

Chris: 49:47

I thought you were going to say we're coming at it from a networking perspective, so we're just naturally cynical and jaded, and things like that.

Alex: 49:55

Most of us.

Tim: 49:56

Don't say the quiet part out loud man.

Chris: 50:00

All right, well, yeah, so I think that that'll wrap up for today. If you, like I said, if you are doing this in your day to day, we love to talk about the experience and the challenges, especially if you're using a lot of these large-scale network services from each of the CSPs and integrating those together. Be curious to talk about it. So, yeah, if you want to, please reach out to us. You can email us at cablestocloudsgmailcom. Reach out to us on any of our socials, that be Twitter, linkedin, et cetera. You can reach out to us personally one-on-one. If you want to talk to me, tim or Alex, feel free to do so. And just to let you guys know that we are open to potentially talking to sponsors. So if you have something you want to showcase on the show, we'd be glad to bring you on and talk through that. So, please reach out to us and be of the same means and, yeah, we'll see you next time. Thanks guys.

Chris: 50:58

Hi everyone, it's Chris and this has been the Cables to Clouds podcast. Thanks for tuning in today. If you enjoyed our show, please subscribe to us in your favorite podcatcher, as well as subscribe and turn on notifications for our YouTube channel to be notified of all our new episodes. Follow us on socials at Cables to Clouds. You can also visit our website for all of the show notes at cablestocloudscom. Thanks again for listening and see you next time.