Ep 16 - Cloud DeMISTified Series: AWS CloudWAN

Speaker 1: 0:00

Welcome to the Cables to Clouds podcast. Cloud adoption is on the rise and many network infrastructure professionals are being asked to adopt a hybrid approach. As individuals who have already started this journey, we would like to empower those professionals with the tools and the knowledge to bridge the gap. Hello and welcome to yet another episode of the Cables to Clouds podcast, which you know, if it isn't already, I hope, hopefully soon will be your favorite place to dive into the world of hybrid cloud networking. My name is Chris Miles.

Speaker 1: 0:43

I just want to give a quick reminder out there to the listeners that you know, if there's anything you ever want to reach out to us about whether it be, you know, a question about something we said, maybe a correction to make hell literally anything. If you want Tim to come over and help you build a, build an Ikea desk or something, reach out to us, hit us up. You can email us at Cables to Clouds at gmailcom. So yeah, literally any questions, any communication you want to send, hit us up. We would love to hear from you guys. So yeah, let's get going. So joining me today, as always, are my you know, beloved co-hosts, my, my cloud brothers from another mother, tim McConaughey and Alex Perkins. How are you doing, guys? How are you doing Tim? What's up? What's new?

Speaker 2: 1:27

Yeah. So I would like to tell everybody that I accomplished many, many things. But I'll be honest with you. My wife took my kids to a to Greensboro this weekend for a frozen musical or something like frozen, like the movie, the Disney movie. I didn't realize that years later they're still doing those, but apparently they are, and they were gone pretty much all of Saturday. So I sat on my couch and I played Diablo 4 from like when I woke up until like midnight, I'll be honest. So I didn't get oh it's, it's crazy, it's good. I got the early access sort of her. So now it's actually kind of laggy and I'm hoping they're going to fix it and whatnot. But now they let everybody, all the, all the plebs in. But but no, it was. It was amazing Diablo man.

Speaker 2: 2:15

I can remember when I was in high school playing the original Diablo and like Windows was it Windows 95 or something and it was such a great game and I definitely definitely recaptured the lighting in a bottle. I was playing with some friends of mine. I got on the PS5. So it's, I'm loving it. Dude, it's actually dangerous. I need to, I need to do one of those things where you lock the, the console or something. So I don't, so I don't find myself over there, I'm getting my work done. Anyway, it's been good times.

Speaker 1: 2:43

Nice, nice. Yeah, I was probably the other day and that was scrolling through the the the store and I saw it on there and I almost pulled the trigger. So maybe, maybe I'll, maybe I'll join you, maybe we'll see. We'll see, alex, what's new in your world. I assume you're also playing Diablo 4.

Speaker 3: 2:59

Yeah, no, no, no, it's funny. Actually, I usually don't play many of video games, but my son you know, tears of the kingdom came out pretty recently.

Speaker 1: 3:08

Yeah.

Speaker 3: 3:09

We actually haven't been playing that. He's never played Breath of the Wild, so he actually bought Breath of the Wild first play through it, and I started playing it one day, just on my own, and I could not put it down. That's a good game. It's so good. I couldn't believe how good it was. Man, like I've been missing out for a long time.

Speaker 1: 3:25

That's awesome.

Speaker 3: 3:26

Yeah, other than that man it's. It's been beautiful out here. I have been trying to spend like every second I can outside. It's been just absolutely gorgeous outside lately.

Speaker 1: 3:35

Thanks, thanks for rubbing it in my face. It's winter starting here, so it's getting a little chilly and gloomy every day, but that's fine.

Speaker 1: 3:42

Sydney, sydney, winter is so mild I can't even start to complain. It's really not bad at all. But yeah, so I have an update on the bird situation. So now I've had I've had Lorekeets now come to the window as well, rainbow Lorekeets, I've been feeding them at the window and cockatoos. But, tim, don't you worry, I'm going to, I'm going to get those cookaburras for you. I've seen them posted up at the crazy, crazy bird ladies balcony over the way and I'm going to steal them. She's even out there. She's like feeding them and petting them and I'm like I'm envious of this woman. I want that so bad. So hopefully that is that is coming soon.

Speaker 3: 4:24

You better start posting some pictures, Chris. It's like Disney princess.

Speaker 2: 4:26

Pictures of Chris, here covered in birds.

Speaker 1: 4:29

That would. That would be my dream. The house would be covered in bird shit, but you know it's, it would still be my dream, all right, so I'll update you guys on that next time as well. And yeah, what I'm trying to think, what else is going on with me? Tim and I have a very exciting project that we are working on. We can't can't really say much about it just yet, but hopefully, there will be hopefully there will be something exciting to reveal to you guys very soon.

Speaker 1: 4:56

So I'll be on the lookout for that. All right, so let's get into today's topic. So Alex and Tim and I were talking and we we wanted to start this series that we're calling cloud demystified. So you know, miss demystified, you know the jokes, you know misty cloud, the jokes always good if you got to explain it right. So this is the first installment of the cloud demystified series.

Speaker 1: 5:22

So what we want to do with this is we take a cloud networking concept or a product and we really want to kind of kind of unravel it, demystify it, right. So we're going to dive into the history, what it does, what challenges it addresses. The thought process was kind of a how it's made episode. And you know, sometimes we're not going to be able to get that deep with it being being the audio format. But you know we're going to do our best. But with that we've. We've also decided that, you know, we'll have the audio component and then and then we're going to come, you know, basically release a video component as well to kind of coincide with that, to kind of show you some visual demos, some some really cool stuff. So look in the show notes for this and we'll hopefully have some details about the, the audio component that you can view with every, every concept that we released in the in the demystified series. So yeah, so let's get going.

Speaker 1: 6:16

So this is the first installment, so we have a. We have a great topic. Today we're going to be talking about AWS Cloudman, which is a, is a product that's we're closing in on about a year old, that since it's been GA. So we thought you know, a very special topic warrants a very special guest. So we've brought in our friend, ruskin Dantra, who is currently with AWS and, I will say, our first ever Kiwi guest to have on the show. And I'm very, very glad to have someone you know on on the same time zone, roughly in the same time zone, on the pod today. So welcome, ruskin. How are you doing?

Speaker 4: 6:58

Hey, chris, thanks for having me. I am doing absolutely fantastic. So, yeah, super excited to be here. I'm just happy you didn't say someone from Australia, or what was that? East Australia? So I'm I'm happy with that. So thank you for applying that. I am actually from New Zealand, as you can see with my little blue pillow at the back. Yeah, I am in Auckland, being here several years, love it. It's just turning over to winter, but yeah, can't complain about winter compared to some of the winters they have over in the States. So I think Sydney and Auckland are a little bit mild, beautiful, beautiful day outside, but it's still a bit chilly.

Speaker 1: 7:39

We're a little spoiled. We're a little spoiled.

Speaker 4: 7:41

What's been happening with me? Yeah, we're a little bit spoiled. I think I love the beach, so, weirdly enough, you can still go to the beach in Auckland in the winter as well. I'm not quite sure if you can do that in the US. So yeah, it's, I don't know. Only in certain places yeah right Florida maybe I would like a seven mil wetsuit.

Speaker 4: 7:59

Maybe I don't know, but yeah, I'll be. What did I do on the weekend? I actually played some games as well. Nothing, nothing as cool as the upload and some of the other games you mentioned. I just got into Nintendo with my kids. I've got a Nintendo Switch. I played a lot of Need for Speed, bringing back the old days when we used to play with the Lamborghini Qutash. Oh yeah, all those games. So just keeping it low key right now, but yeah, I spent hours on it, way too much time than I would have liked. Weirdly enough, I got it for my kids, but I have clocked up more hours on it myself. You know how it is it's always an excuse.

Speaker 2: 8:36

I do.

Speaker 4: 8:37

That's awesome. Yeah, that's a little bit about me, and yeah, I'm currently a Solutions Architect at AWS.

Speaker 1: 8:44

Awesome, yeah, well, thanks so much for joining today. We are very pleased to have you on. So, yeah, let's maybe give a brief introduction to yourself. What's your experience been with your journey to cloud and things like that, and how did you get where you are?

Speaker 4: 9:05

Sure, why not? I started my background in software engineering, so you know those traditional C-Sharp developers started coding out of university, did a bit of C++, winforms, wpf you know all the good things from back in the day Started in the cloud, maybe around 2013, 2015. So it's been a while, been a while and back. I had no networking background back then. So you know how it is when you're an app developer and you're looking at all these networking constructs on premises or in your cupboard back at your work, you're like, oh no, let the ops people handle that. So that was my experience. As far as networking concern, my biggest thing I plugged in was a UPS into a service. That was the biggest networking thing I did back in the day when we did have UPSs and we managed our own servers. I did a bit of AD connectivity in terms of networking. But yeah, that was about it.

Speaker 4: 10:07

But, weirdly enough, when you start dabbling in the cloud, especially with AWS, in any cloud these days this networking is such a big part of it, right? So I had to start rolling up my sleeves and learn all about. You know VPCs, connectivity, routing, bgp and, as it starts growing, learning about direct connect and VPN. So I started a journey about two years ago and absolutely loved it, right. So it's just something.

Speaker 4: 10:36

Networking is just something that makes me feel like I'm closer to the physical world rather than living up in the clouds. You know, pun intended. So it takes away some of that abstraction, right? It's so physical. It's about physics, it's about how fast light travels. Some of those concepts are so grounded onto the actual mechanics of devices and things like that so it makes me feel like I'm actually doing something with real devices rather than, you know, coding at higher abstraction levels where I have no idea how it's converted to binary. So that's been my journey so far and, yeah, super excited about what we're doing in the space and a topic we're talking about today, which is CloudBand. So, yeah, a little bit about my history.

Speaker 3: 11:17

Real quick. What's the piano? Do you play the piano? That's a keyboard man. It is a keyboard.

Speaker 4: 11:23

Same thing, same thing. No, I don't play the keyboard. It's for my children, so they kind of tend to play. There's a saxophone and a guitar and a violin here as well, so I'm trying to get them into more musical instruments than I ever got my hands onto. So growing up I'm not sure about you guys, but I was told academics was the only way forward. Weirdly enough, not music or anything else. So that's, I'm trying to change their perception, with my kids especially. You know, studying is not the only thing. So far, so good.

Speaker 1: 11:55

That's beautiful. I love that Awesome. Yeah, I also found that very interesting that you moved to Cloud first and then got into networking, whereas we've started a podcast all about moving from on-prem networking to networking in the cloud. So that is somewhat reassuring to hear that. You know we preach about on the pod all the time about how you know networking is finally getting a seat at the table in the cloud world, because it just is a critical piece to every solution that you can build out and it needs to be considered, and it feels good to hear you hammer that home. So thanks for pointing that out. So, yeah, let's get into the topic at hand 100% yeah.

Speaker 1: 12:36

Yeah, so, yeah, topic at hand Cloudland let's get into it. It's like I said, it's been out for close to a year now, I think at GAID back in July 2022. So we're about a year in, so, let's, we'll get into. You know how customers have taken to it and things like that. But let's maybe start with maybe a brief overview of history of Cloudland and how it came to be.

Speaker 4: 13:01

Yeah, sure so it's. The history of Cloudland stems from customers wanting to connect variety of their infrastructure through different geographies, through different providers, through different ways, security patterns, etc. Amongst themselves. Right so customers wanted to have connectivity, branch networks, data centers, it could be whatever like covers in their, in their, in their office locations, and they'd offer that they're through MPL, mpls, through VPN, sdvan, etc. Right so it was a plethora of different technologies which they used to connect all of this together and the advent of cloud.

Speaker 4: 13:47

In the past few years a lot of customers have started moving to the cloud. Right so the cloud has become an extension of their data center, sometimes taking over their data center themselves. So the primary data center has become the cloud and slowly and surely, more of their center of gravity is moving towards the cloud. Right so they are moving a lot of the migrating, migrating a lot of the workloads, finding a little bit more around. How do we connect to the cloud? And as they start growing they might get a new branch location coming up or they might have another region expansion. They are looking at expanding their and growing their footprint as well. So every time they grow, there is an extra burden about how do we provision circuit? How do we sort out security? How do you provision the topology in the networks? And it's never the same, right? It's always different depending on which region, which locale you live in. Right, it depends on the rules and regulations. Timeframes are different. How do we connect up this new branch which is coming up? Do we connect into the data center? Do we go directly to the cloud? Do we use direct connect? Do we use VPN? Do we use SDVAN? A lot of questions came about.

Speaker 4: 14:56

So cloudVAN is essentially a managed service which helps customers to have this unified connectivity options in AWS. Right, so we help them connecting into AWS through whatever they are pleased to do. Right, so it could be SDVAN or it could be VPN or direct connect. We let them land into AWS and from there we provide a unified construct to expand through various regions. And one of the reasons customers ask us for this is essentially they were tracing our backbone all the way across different regions. So they wanted connectivity in AWS, so they would kind of trace it there into a particular region US, for example and they wanted connectivity in Singapore, so they would have connectivity coming into that, explicitly joining them together.

Speaker 4: 15:43

It's always a little bit manual a little bit disjointed. So cloudVAN allows them to have that uniformed global network across their real estate in the cloud, and it does it, giving them the tools they already know through AWS cloud and also gives them a way to kind of monitor it using a single pane of glass. So that, essentially, is a little bit about the history. To help customers have a unified approach, make it a little bit simple, give capabilities around dashboarding and also keep security at the forefront, right, because with all these different technologies, security becomes quite an arduous task. So how do you tackle that? So cloudVAN handles and helps customers with that.

Speaker 2: 16:23

This is interesting because when you hear the word cloudVAN, I mean that is what you think of. You think of the idea like, okay, we're going to use cloud as like a backbone, right, it's almost like a different use case than what you think of as traditional cloud, which is, of course, you know cloud is a. You know it's essentially a data center that you know AWS or another provider is running and we've got workloads there and really we're only interested in north-south type of connectivity where we have users trying to access workloads. But what it sounds like you're saying is that cloudVAN is actually more like, you know, a method to connect, almost like a provider, if you will, almost like a service provider type of connection. And so would you say that cloudVAN, you know, not that you would necessarily, but like you would connect, you know sites together and not even be concerned about you know how do I need to reach all these workloads? Or I mean, I assume the goal is really still to be connecting users to the workloads.

Speaker 4: 17:24

Yeah, 100%. So that's a good point, tim. So that's what I was saying earlier, right? So originally the workloads were in data centers and users were to potentially get access to these workloads by, you know, site-to-site VPNs or client VPNs directly into the data center. But as customers are starting to move these workloads on to AWS, what does the connectivity pattern look like over here? Right, as they're looking at disaster recovery or even multi-region expansion, they're moving these workloads across regions to, you know, reduce latency for the end users. So how would they connect various regions together through a single backbone, and we already have that backbone.

Speaker 4: 18:03

So AWS connects multiple regions together. We have multiple pops and why not let customers, you know, piggyback on some of that good AWS backbone technology we have and expose that for them to do that connectivity? So, as long as you can have a route into AWS, either via, as I say, route quite loosely via VPN or SDVAN, from that point onwards you can have east-west connectivity, I guess east-west from a cloud perspective, having multiple regions right so it's not out to the internet and you can have that connectivity through different workloads and it's still seamless. Right so you're not managing any hardware, you're not having big contracts with the NPS providers. You're not worried about 50 time frames. This is in a matter of minutes expanding out globally, right, as opposed to weeks or months where you have to negotiate big contracts with providers, even if they do exist, or even managed VPN device hardware on your on your branches and things like that. So, yeah, it really simplifies for for our customers through that connectivity across the cloud.

Speaker 3: 19:13

I love what you said, tim, because it's basically like you said, it's like a, like a virtual global on-demand network, right. It's almost like some kind of network, cdn, hybrid kind of thing, right, and it's cool. Though, thing I want to call out is you know, you guys could have easily just cloud-wan and just done the networking piece, but when it came out, it already had things like security built into it and a dashboard and you know, just segmentation, and it's just awesome that those are the things that were already built into it that you can just do from day one, and that's exactly what you would expect from a network. But I think if someone just came out with that, not everyone would think of adding all those things into it right from the jump. So I just think it's really cool that those are all added in there as well, yeah that's a very good point, alex, right.

Speaker 4: 19:58

So, as with anything with AWS, right, security is our top priority. Networking is no less. What we found with networking is that our customers often wanted routing domains. So like when you land in the cloud or even your data center, how do you establish who can talk to which networks can talk to which network's fine, and we wanted to make that a first class citizen in cloud-band itself, right? So essentially like intent-driven networking. So it wasn't about low-level things like routes and subnets. It was higher than that, like it was a slightly higher abstraction layer.

Speaker 4: 20:36

And the reason we did that is like if you're looking at a global network and if you're looking at thousands of VPCs, thousands of ciders, thousands of routes, etc. You don't want to manage it at that level, right? I mean, maybe you do, maybe you don't. But for those who don't want to manage it at that level, how do you kind of group the groupies into intents, right? So how do you say that my finance domain will never talk to my engineering domain, for example? Or it will, but these are some exceptions. So how do you drive that intent through your network fabric, right? And how do you make it globally available across your real estate, not only for things which are inside AWS, but also for your infrastructure which is in your data centers as well, or your branch offices, right. So that kind of flows all the way through that and it really makes it easy in terms of that unified approach so you can apply the same policy across a variety of your connectivity, across your cloud, and it really makes it easier to the unified approach as well.

Speaker 2: 21:37

Yeah, so do you have a lot of customers that, oh sorry, you were going to say something, chris, no, you're good, go ahead. Okay, so do you. This is just fascinating to me. So do you have customers that are using Cloud WAN more in an east-west type of capacity than just to access workloads? Is there anybody that's trying to basically use AWS as their service provider, for whatever reason? I'm kind of curious about this because I think about it today and, of course, you buy a direct connect and you connect your data center to a region or on the other side of the globe. You do the same thing. I've got another direct connect and I've connected it to AWS, and what you're saying basically is with Cloud WAN is that, rather than have a really complicated MPLS or whatever, some kind of private circuit or whatever it looks like, you basically use Cloud WAN to stitch that together so that these two data centers could use AWS as like a backbone to connect to each other as well.

Speaker 4: 22:37

Yeah, 100%. And I guess to answer that we have to start looking at the use cases which Cloud WAN kind of targets do. So there are three main use cases. So the first one is what you alluded to, tim is essentially, how do you connect MPCs? So you have a couple of data centers and you've connected up to the AWS and you're using AWS backfiring to have that kind of East-West connectivity. So there's definitely a use case where you're just connecting up your VPCs inside Cloud.

Speaker 4: 23:08

So this allows you either a flat network or, to Alex's point earlier, you could set this to your heart's content, right. So deal fraud engineering with this finance, whatever it might be staging with this fraud, it could be anything. So this one use case. The second use case is where you're using it essentially to give you that branch connectivity. So you have your SDVAN from your branches going up into Cloud VAN and then you have those connectivity across so your branches can communicate to each other. So you could leverage things like VPN, for example, where you don't want to put SDVAN appliances, and there are a few ones like the higher bandwidth. You might be using direct connect, like you mentioned, and get that connectivity across. So that's yours essentially your second use case.

Speaker 4: 23:51

And finally, we have other use cases where customers are looking for full hybrid connectivity right, so, they want your data centers. They have AWS. It could be for disaster recovery, for example, where they have connected to one AWS region but they want to expand to other global connectivity options across different regions and also overlaying segmentation on top of that. So, yeah, short answer, correct, we do offer that and yeah, think of it from a perspective of three different use cases, which are ones fit into these. And, given that it was released last year, we are continuously working with our customers as well to look at other use cases. And what else can they come up with? To do cool stuff with networking, which always amazes me.

Speaker 1: 24:38

Yeah, lord knows, they'll find the use cases right. That's kind of technology gets designed right. So, yeah, that's very cool. So, given the kind of core fundamentals of CloudWan and what it was brought to solve, so in my mind I'm thinking, you know you are, aws does already have a product that has been a pretty tried and true networking product for the last several years, which is AWS Transit Gateway. So maybe can we dive into what CloudWan differentiates from Transit Gateway, because you know, I'm sure there's many, many, many customers out there that are using Transit Gateway today. What benefits do they get by incorporating CloudWan? Or you know what are the differences between the two? I guess yeah, 100%.

Speaker 4: 25:32

So that's a good question and we get that from our customers all the time, right? So I already have transit gateway. Do I need to move to CloudWan? So the short answer is no, unless you need to kind of, you know, have that expanded global availability or global reach right? So Transit Gateway from a technical perspective is still required. So it's got multicast support. It's got this fine grain routing, routing, routing, domain management where you're actually managing your routes yourself. So it's all managed by the customers themselves, which is a slightly different way for CloudWan, where the routing and all of that is kind of managed under the hood by us, where you kind of interact with CloudWan using Siemens and policies. So that's the difference there.

Speaker 4: 26:23

But having said that, we always talk to our customers. We try and understand the use case right. So if we can, you know peer Transit Gateway is into your existing CloudWan as well. So if you so want to use Transit Gateway, you already have a worker in Transit Gateway and you want to start using CloudWan for some of your newer workloads, you can keep your Transit Gateway and you can create a peer in connection into CloudWan. So that's one possibility.

Speaker 4: 26:49

And we also have customers who go down on migration parts. So they're like okay, we want to move away from Transit Gateway into a more of a managed option, which is where CloudWan comes into play and there are migration parts for those customers as well. And we also have sort of like a third approach where customers make the explicit decision that we want more of a federation approach where we can manage each of the Transit Gateway autonomous systems separately and we kind of just peer into the core network. So we'll use the core network for the connectivity, but we'll still manage our Transit Gateway and the smaller networks on that side explicitly. So in that case, kind of, you can think of CloudWan as a provider. Each time you've alluded to the fact that CloudWan just becomes a provider. So yes, and your Transit Gateway essentially becomes your customer age, or your spoke age, if you can call it that. So yeah, there are quite a few places where you can use CloudWan, continue to use Transit Gateway, that both work happily together, or there are migration options available as well.

Speaker 3: 27:53

It's like a Transit Gateway for Transit Gateway. It's like a higher abstraction up that allows you to do a lot more on top of it.

Speaker 4: 28:01

That's great.

Speaker 2: 28:02

Was that actually? Was that a conscious thing? We're seeing so much the trend towards application networking these days. For example, we'll talk about VPC Lattice in a totally different episode, but CloudWan isn't VPC Lattice. They're completely different products. I think that's obvious. What I mean, though, is that we're talking about, or you're talking about an extra layer of abstraction, specifically like an intent base, a move towards intent based networking, away from traditional routing, traditional networking. We don't care as much, it's hidden under the hood, it's kind of managed, I guess. Is that intentionally to get away from the networking piece of it and make it more accessible to the development side? Or is it more about just the management? Orchestration of large networks just has to come with more abstraction, I guess.

Speaker 4: 28:59

Yes, I think with AWS, we always preach and practice that using the right tool for the job. There is no real intent to move away from one towards the other or going away from routing to fully managed or abstracted ways of doing things. It just depends on the personas and the scale at which you're operating. Obviously, translocateway is trying to true Customers love it, we love it. We have seen a lot of customers use them in a very cool way. Cloudbrain is, like you said, intent based. That creates an abstraction layer. So there are pathways and possibilities and use cases for where each of them are needed and used. And, yes, I think you're right, there is a move towards catering for more application based networking out there in the real world these days. So, like you mentioned, vpc Lattice, there is a prime example. So we are seeing just like security and app development was back in the day. I think that slowly bridged the gap.

Speaker 4: 30:02

I think networking and app development needs a little bit of a bridge as well and what we're doing is we're helping create that bridge. So it might be VPC Lattice or it might be intent based routing, where a developer can go and have a chat with a networking person and say, look I need. This is a prod VPC. I want to talk to other prod VPCs and this XYZ workload. Can you please make it happen Before? That conversation was painful, right, there will be like oh, what routes do you need to open up? Oh, I don't know what routes, what are routes? The conversation is really hard. But then again, yeah, like I said, routing is always going to be there. It's just not going to go away, but it just helps those developers be a little bit more open, have those communication channels across, create a single kind of single language, which is your intent, and start bringing them a little bit closer.

Speaker 1: 30:56

It's not like the networkers and it's thoroughly being phased out or anything when we're talking about a managed service versus letting the developers integrate that as well. Because I would encourage anyone out there to go watch the routing loop that you guys do on the Twitch stream Some of those technical details on integrating CloudLand with hybrid networking. With CloudLand you can deploy some very complex architectures that definitely need the professionals to come in and know how to manipulate routing and how to play with the, the BGP communities, to get things to operate. So it's not like the use of managed service pulls all the control out. It very much still is warranted.

Speaker 3: 31:50

I got to just pile on a little bit to this topic. So application networking is something I love talking about, but it's a really great point, especially with CloudLand, because you tag the attachments to apply the automation like the intelligence behind it. So it's much more putting the intelligence into the tool than it is like you are actually automating it as you're doing the connection and that's very service mesh like yeah, that's a great call out, tim, that was a really good question.

Speaker 1: 32:21

Thanks, okay, yeah, so let's see, we've kind of talked about what CloudLand is, what the major pain points it's been meant to solve. So I don't know how deep we can actually go into this, how much of the of the onion we can peel back. But can we kind of talk about what elements went into the actual development of CloudLand, like what happened behind the scenes and what all had to come together for that to make it a full-fledged product?

Speaker 4: 32:53

Yeah, I'll do my best. So obviously, we have very, very, very smart service teams in the background doing some very, very smart things which I'll pretend I understand, but maybe I don't, but I'll do my best. So, with AWS and Amazon, we always start with our customers first, right, so, what they wanted was, just like I mentioned earlier, that unified view into it, right so, and then wanted to leverage our backfine. I think that that's one of the key things. Right, so we already have this connectivity across heaps of regions, like 25 growing regions. Every time there's a region coming up we have one coming up in Auckland as well and customers wanted to say look, you have this region, you have this infrastructure. Why can't we just use it? Right, and we already are using a lot of this ourselves in AWS, so we connect our regions across through low latency, highly available networks. So we're like how do we expose some of this functionality to our end users? So we provide them with this concept of like a global network, right, so they can create a container so similar to like we see where they come out of, kind of like a software defined boundary around their virtual private cloud. We provide them like a container which is called a global network and within that, we expect the users to create, or the customers to create, something called a core network, which is where AWS will start applying these things called policies, which we talked about, and that is how it came about. And the customer talks and manages this core network policy.

Speaker 4: 34:36

Right and behind the hood, we have like a policy language which describes this in JSON, which describes what the intent is, and we essentially, when the customer makes changes it's similar to how cloud formation works as well right, so you create a cloud formation stack and you make changes to it. We have a stack updates and they get applied. So with policies as well, we go through the same process. So when you make a change to the policy, how do we apply it? So we show what the changes to the policy are and then we allow the customer to choose when to apply that. Right, so it's not about is there a big policy and they just go and apply it to all the distributed routers and we'll let work as expected. So we give the customers some view into what the changes will be, what gets modified, which segments, what's getting added, what's getting deleted, before they actually go and apply it. So we are looking after, like security from that perspective as well.

Speaker 4: 35:33

So say, for example, you want to ensure that there is segregation of duties, so someone who's making changes to the policies is not someone who can deploy them as well. So we kind of catered for that as well in the background. And then it goes ahead and makes those changes across to these things called core network edges, which are essentially these edge constructs which are deployed into each region where you want to use CloudVan, and that's quite a distributed. Think of it as a I'm not sure if router is the best way, but it's actually a construct which manages the BGP connectivity and the communication between all your network edges. So you could have three regions and each region will have a core network edge.

Speaker 2: 36:15

Sorry, Ruskin, is it just a managed transit gateway under the hood? Is that really what I see? Any is.

Speaker 4: 36:20

It's very similar to a transit gateway, but yeah, it is managed on top of it. It might be different at my top I don't have privy into that information and that would be very cool to kind of dive into as well. But yeah, you can see it from a perspective of a managed transit gateway. Yeah, and it goes and updates those routes and away you go and yeah, you have this intent based policy gets applied to your things, and then you go into your VPCs and you essentially say I want to send my traffic to this core network, core network edge, and it handles all the routing for you. Yeah, so this is very simple from a user, from a customer perspective. You just kind of end point to a point to an endpoint which is your core network edge and yeah, that's it.

Speaker 3: 37:09

You mentioned how you can kind of see your policy before you apply it. Where is that actually shown? Is that just in the dashboard somewhere?

Speaker 4: 37:16

Correct. Yeah, so policies are version documents, right. So when you, when you go and generate a policy, you can go and manipulate it using AWS console or you can do it using JSON. You could use whatever CI CD tools you wish to use, right? So you can even put pull request on top of that to manage that if you so wish to choose to do that. And it's just in the console. So then you go, it goes into certain phases, so it goes into like a execution, it goes into a really phase and you can execute it, and when they execute it it actually tells you what steps it's doing. And then it applies to the different edge locations, core network edges, rather, and you can see all this is in the CloudBrain console, if you go into that. So there are a few tabs on the right and one, like if you do a demo down the line, we can definitely demonstrate that aspect to you, how it actually applies it, for sure, okay, and one thing you can configure right.

Speaker 3: 38:13

Is it only in the dashboard or can you have like the output somewhere, you know, like a Terraform plan or something like? Is there a way where you can see it added into a CI CD pipeline to like see your changes or something? Is there anything like that?

Speaker 4: 38:27

Oh right, I actually don't know whether the chain set can be seen from a CLI. I can have a look for you and get back to you at the demo perhaps. But yes, I guess the question is can I see the chain set and can I send it to a networking guru who can validate it?

Speaker 3: 38:43

Yeah, exactly, yep.

Speaker 2: 38:44

That's a good question, I think. Definitely seeing it, we'll definitely have you back so we can actually get a video portion of this and see some of this in action. I mean, I've poked around with CloudWin just in my AWS account in my console and it's even for a network guide. You know it's daunting to, I guess, to start with. So I think one thing we kind of skipped over though a little bit is kind of like what is the alternative, right? And so a lot of people that are listening may not have felt the pain of trying to orchestrate. You know four different types of connectivity and get everything connected you know in AWS before. So maybe just a quick shout out for, like, how did we solve this problem before? And like, therefore, you know what was the, what was the real pain that people were running into so that we could solve it with CloudWin.

Speaker 4: 39:34

Yeah, 100%. So a lot of the pain arose from customers looking at expanding themselves. Right, so new branch comes up. How do you connect that into your data center? Do you need to connect to the data center? How do you connect it to your workloads coming into AWS? Right, so you would have. Do you need to go to the data center to connect to AWS? Your data center hasn't direct connect into AWS. You still need connectivity from your branch into the data center.

Speaker 4: 40:07

So you would kind of maybe deploy a VPN. Or, if you want to deploy a software defined network device onto your branch, connect that across to your data center through to AWS. That's okay as well. So that was essentially the path you would follow in the past. Right, you would go into a branch. You would say cool, what location you're in? Right, what's your? What's your NPS provider here? Is there a provider? Can we deploy a VPN? Do you have some IT staff here? How long will it take? Can we provision some hardware? So you start having these conversations continuously. Right, and that's true for one branch.

Speaker 4: 40:44

Imagine you're creating lots of different branches. Put the extra overhead of remote users as well. Right, so you have VPNs. You have different applications needing connectivity as well. Your users are no longer in your branches now. They are remotely dispersed because of COVID and they need to. You know work from different geographies or different remote locations.

Speaker 4: 41:04

How do you create this connectivity, Right? Do you constantly need to go to the data center, or is there potential of your branch connecting directly to AWS? So that's essentially what we're trying to solve here, Right? So if there is, there are a lot of pain points there, like it would take a lot of time. You would need expertise in those areas as well, and when you connect into your AWS location, your workloads could be on other side of your other planet. Right?

Speaker 4: 41:28

So you're creating a branch in the US, but your workload might be somewhere else. You need that connectivity as well across regions and periods and things like that. So how do we solve that? How do you make it a little bit easier? How do you monitor across these distributed networks as well, Right? So, which is really hard sometimes and how do you put a single lens of security across this? So you're creating a new branch, you're getting into AWS, but hang on a second you should not be able to see other branches, communication, et cetera. You should not be able to get to their workloads or their workloads in a different VPC or whatever it might be. So it gets complicated, and so CloudRend. Hopefully it solves a lot of those challenges for you as a company.

Speaker 2: 42:12

Sounds like the big one is that we get the ability to orchestrate connectivity together, rather than saying here's a site to site VPN going to this VPC and I got to go build that and I got to go manage the routing for that, and then over here I've got a direct connect and I have to build that and I have to manage that separately. And over in another region I've built a VPN between these two sites and I've got to manage the VGW connections and all of the 10,000 different ways that we can connect things to AWS. Before CloudRend pretty much had to be managed more or less one off each one. And let me land my VPN on a TGW or whatever that is. Let me land the direct connect on a TGW and it seems like, if I'm hearing correctly, what you're saying is that basically, cloudrend is a way to use the word, but my mind is failing me. The whole single plane of the glass type of approach to managing and orchestrating all that connectivity Is that fair?

Speaker 4: 43:15

Yeah, that's fair. Yeah, 100%. Every time you bring a branch online or a data center online, even a user online, you have to consider is it a new way of connecting or are you using some established, tried and true method? And a lot of times it might be a new way of doing things right for a variety of reasons hardware changes or provider changes. So how do you manage all of these? How do you manage all of the plethora of different communication styles, visibility, observability, contracts, even right and exactly right? So, once you land the database, you can use your CloudRend to get that unified, simplistic view of the networking world and, yeah, establish who connects to what in a much simpler way.

Speaker 3: 44:05

Yeah, all that centralized policy is just. That's so helpful and convenient.

Speaker 4: 44:10

Like.

Speaker 3: 44:11

Tim was saying, the sprawl that you have to do, just doing it all manually before that is a nightmare.

Speaker 4: 44:17

Yeah, and you can build some really cool patterns and potentially do a demo of some simple patterns in the next episode, right, when you can say we want to create some isolated networks where even things within a segment can't talk to each other. So I have a production segment, but even within that you shouldn't be able to talk to each other. Or I have a segment which is PCI compliant and I want to make sure that none of my PCI workloads can be accessed by anything outside of the segment. You can even do fine grained sharing as well. So you could say I don't want to advertise this route, I don't want to. I do want to share this, but not this part. So we're really excited as to what customers can do with these policies, right, so they're all in JSON and hopefully I can show you guys a demo. I want to make it too complicated, obviously, and, yeah, we can see where we can have some fun with the policy.

Speaker 2: 45:16

Awesome Sounds great.

Speaker 1: 45:18

Yeah, actually, piggybacking off Tim's question, something that just came to mind talking about how we used to solve the problem, we can go back just not even that far to just AWS TGW. Like you know, tgw gives you this option for, like, a security service insertion, basically, so you can have an appliance, vpc, that lets you, you know, manage inspecting your East West traffic as it goes through TGW, which we which you know I know a lot of cloud cloud customers are using, how we even we even do the same thing at Aviatrix. We know that's a very critical service for people. So how is that, how is that addressed within cloud when, like, let's say, if a customer can, can customers today do security service insertion using any of the AWS products or a third party service to do that East West inspection with Cloud WAN alone, or does that need to be done still through TGW?

Speaker 4: 46:16

No, so you could. You could insert your security inspection appliances right right through your cloud as well. Right, so you could. You would have an inspection VPC which could just be a extra attachment into your cloud bin segment and you could build policies around that and I think you put you touched on an interesting point there as well. So how do we kind of partner with existing appliance providers as well? So we work very closely with people like your Aviatrix you mentioned that and allow them to kind of hook into these right in a lot of blogs available out there as well, which you know, leverage, cloud ban and show possibilities on how you can create firewall VPCs or inspection VPCs where you can plug in your network firewall or appliances which get come from the provider to help you with that East West navigation or inspection as well. So, yeah, it just kind of plugs into your cloud band and you can do your inspection through your policies and your, your routes and your intents.

Speaker 1: 47:15

Yeah, that's that's. Yeah, it's very good to know because I know that's kind of a concrete piece that a lot of a lot of people are using TGW for. So that's nice to know that that was directly integrated there. So I know we're we're getting close to time on here, so let's we'll kind of hammer it home with one last point that we can cover here. So, given it's work, like I said, we're closing in on 12 months. That cloud ban has been GA. How is it fair with customers? How are people using it? A lot of people migrate like actually, you know, say okay, you know, we're off TGW, we're moving to cloud ban or, you know, is it more of a hybrid approach? What's what's been the kind of the feeling you guys have gotten from customers so far?

Speaker 4: 48:04

Yeah, so it's a new product. So it's been G8 since July. So we're seeing a lot of customers use them in a variety of ways. So customers who have their full networks built around transit gateway. They're looking at parts of how do we augment the existing capabilities with CloudVan. So, yes, we can build new stuff. So I talked about three use cases before. So we want to build new stuff in CloudVan if there is a need be expanding into multiple regions. We have transit gateway here. We are happy with that. How do we bring CloudVan into this journey?

Speaker 4: 48:38

so that there is that set of customers. We have customers who are still moving into AWS, right? So there are lots of stats out there where we are saying there are customers still on-prem and still doing that migration onto AWS. So how do we position CloudVan for them? So, if they have needs to expand globally across multiple regions, multiple geographies, how do you envisage CloudVan helping them? Right, because they are essentially a green field in AWS. So can CloudVan help with that?

Speaker 4: 49:12

And then we have other sets of customers where they've essentially made a decision to say we are happy with our TGV, we're not going to be migrating. Can we just use CloudVan and federated across? Right? So use that kind of keep CloudVan as the hub and create these TGV networks on the sites, as they spoke. So yeah, that's essentially what we've seen in the field and yeah, we're still exploring that part as well. So how are customers using CloudVan? So, yeah, we continue to kind of explore that and see what cool use cases customers are coming up with and, as I found, find more definitely share them with you.

Speaker 1: 49:51

All right. Well, yeah, that's great. Like I said, we're closing in on time here, but we don't want to leave anyone hanging. Like I said, we understand this is a visual meeting and we're talking about a technical topic here. So we think we would only do your right if we can bring Ruskin back and we'll do a visual component to this. So we will be having a AWS CloudVan demo that we'll be putting on the YouTube channel as well. So, if you can take a look at the show notes for this episode, we'll make sure to put all the details in there and we'll maybe list out a set of things that we cover in the video demo, so you know what you're in for. But I would definitely encourage you to go take a look at that. Do not miss that. It's very valuable. So, yeah, any closing thoughts? Any closing comments? You guys have Tim Alex.

Speaker 2: 50:45

No, I'm really glad that you were able to come out Ruskin and explain CloudVan and that you could be here for our inaugural. If you will, demystified, are we going to get sued by Jennifer, do you think? Demystified?

Speaker 1: 50:58

I really don't know. You can't miss. That's a general term, that's OK.

Speaker 2: 51:05

Anyway, no, no, really, thanks for coming out. This has been really, really informative. I'm going to probably find an excuse to play with it myself, and I can't wait to see the demo and get that on our YouTube channel, because I think people will be really excited about it. Yeah, 100%.

Speaker 4: 51:20

So easy to get started as well. Yeah, go into your consoles. Create a global network. Start creating a core network, even if you just join VPCs together. See how it works. Get your hands dirty. This is how I would always recommend it.

Speaker 3: 51:36

Yeah, it's just awesome. Thanks for coming on, ruskin. This was great. It's another one of those topics. You could go for hours and go super deep, but this is a great overview and, like Tim and Chris have both mentioned, I think getting that demo out in a YouTube video is going to be super helpful for anyone that needs to see it. This is something I feel like you will grasp much easier when you can actually see it and see how it works and kind of get an idea of what it solves.

Speaker 1: 52:03

Absolutely. It's a powerful tool, so we definitely want to showcase the strengths there and show people how they can do it in their own environments as well. So we'll definitely have that coming up. So, yeah, thanks again, ruskin, for coming on. We'll definitely have you back, like we said for the demo, shortly, so I'm sure we'll be talking soon. But to all the listeners out there, thank you so much for tuning in for, like I said, another episode of the Cables to Clouds podcast. This has been the first installment of the Cloud Demystified series. There will be more to come. So, yeah, definitely. Like I said before, feel free to reach out to us, cablestoclouds at gmailcom, if you have any questions concerns comments, anything at all, if you just want to say hi, you know, if maybe you think.

Speaker 2: 52:46

Twitter is too.

Speaker 1: 52:48

Yeah, we do have Twitter, so Twitter Cables to Clouds, a1, discord. Anywhere you want to hit us up, feel free to do so. We would really like to hear from you. So with that we will wrap it up and we'll talk to you next time. Thanks a lot, guys.

Speaker 4: 53:02

Thanks, all Appreciate it.

Speaker 1: 53:05

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.