Ep 19 - Cloud DeMISTified Series: AWS VPC Lattice

Chris Miles: 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 back to the Cables to Clouds podcast. You know the deal. We are back again with another great episode for you guys today. Today we're talking about VPC Lattice, so we've got some individuals on from AWS to talk about this relatively new service and I will say we had a great conversation. Prior to that, let's get into the bi-weekly Cloud News of the Week. Alex, you want to start us off with some news about AI. It's going to keep probably popping up every single time. We release this now, but let's hear it.

Alex Perkins: 1:02

Yep, it's going to be the thing every time. It seems like. Yes, this is from the Google Cloud blog. It's about Falcon, which is a new. They call it a reliable, low latency hardware transport. What I thought was really interesting about this article is that they talked about how in the past, they've released things through the IETF and ACM, and this time they decided to skip that and just release it with Open Compute Project. So it's just interesting. I don't know if this is like a sign of changing times, where people are going to start trying to get things through quicker, but it's got a bunch of backing, especially like we talked with Peter Jones from the Ultimate Ethernet Alliance. It's got a bunch of backings from them. There's all kinds of quotes about all the different companies backing this. So I just think it's cool to see industry giants if you will coming out with these new standards. And then next we got NVIDIA and OCI, chris, if you want to talk about that one real quick.

Chris Miles: 1:59

Yeah, so we have an article not surprising here two tech giants starting an AI services offering. But yeah, so we have an article from SDX Central that NVIDIA is now launching an AI service offering on OCI. So probably very good for OCI to make this agreement and get their name in the game a little bit. So, yeah, I don't know if this is going to be exclusive to OCI. From NVIDIA's perspective, I feel like they might be locking themselves in if that's the case. But I don't know. It's nothing surprising here. Just wanted to call that out. Yeah, next up we have some interesting news from Well, we have CSP news next, but this last two weeks has pretty much been all AWS. So let's hear about it, tim.

Tim McConnaughy: 2:51

Yeah, no big announcements actually on the cloud networking front from AWS. Huge ones. The first one is that now AWS CloudWin supports Tunnelis Connect, which is to say before CloudWin being kind of the managed WAN service. We had an episode where we talked to Ruskin Dantra about it and we have a demo of CloudWin on our YouTube channel, so make sure you check that out. They've just introduced a new way to connect to CloudWin without using any kind of tunneling or GRE, which is going to boost throughput and it's going to make networking a lot simpler. So I've been actually playing with it at work, just trying to lab it up, and it's really interesting. I think it could change the CloudWin game and get a lot more adoption. And, surprisingly, a lot of NVA vendors pretty much anybody with a nick has announced that they now support Tunnelis Connection with CloudWin. So yeah, it's pretty much everybody on the list.

Tim McConnaughy: 3:51

You can check out the news in the show. We link you to the biweekly news in the show notes. It looks pretty good, is all I can say. So there's another big one, and I think, was it Chris? Chris, are you going to cover this one?

Chris Miles: 4:02

Sure, this is potentially a game changer for players in the especially in the networking market for AWS, but kind of just a big one for Cloud Networking in general. Aws has also made an announcement that they now support multi-VPC E&I attachments. So just to kind of break that down typically whenever you deploy anything in AWS that belongs to a VPC, all the network interfaces that belong to that particular instance have to be maintained in that single VPC where it's deployed, right. But now they've announced that you now have the option to attach secondary network interfaces that can belong to a different VPC. So that's like it sounds very simple, but that's huge and can kind of completely change how you build out networking, especially across VPCs, right, because you could just have an NVA or just an instance of your choice sitting between two VPCs. You know they mentioned in the article that you can overcome, you know, side or overlap limitations, things like that.

Chris Miles: 5:12

Really funny that they just kind of squeezed this one out and it was kind of like not a big deal, because that's pretty huge and I don't know. I'm wondering if they put this out. The timing is weird, right, we're at the end of October and I'm wondering if they're putting this out just so it can coincide with something else that comes out at re-invent. I could be wrong, but that's, I'm hopeful anyway. I hope it leads to something cool. This is.

Alex Perkins: 5:39

It's so weird because even this link is so short and it seems like it should be such a bigger deal, right, but it's. I mean, this is like the first thing you learn, like if you've ever taken any kind of training course, or even Amazon's materials or AWS and materials right, it's like this is one of the first things is that the Nick is in a specific VPC and you can't like have them split. So this is I don't know, there's so many weird things to think through with this that new architecture changes and it's almost like I don't know if this is just to open up like possibilities for more people to use the cloud, because one thing they mentioned is like a cheaper makeshift HAA deployment. You know, I don't know, it's weird. It's like it takes away from use of some of the other products that have come out, but at the same time, like it kind of opens up the door for new things. I don't know, tim, you got any more thoughts?

Tim McConnaughy: 6:28

Yeah, no, I mean it's big, and what I find interesting is how low key the announcement was and how low key the actual. When I say the announcement, I mean not only the announcement itself but, like the and I hesitate to even say article right about that. This is not a thing that we're supporting. I don't know, maybe you're right, maybe it's just bearing the lead on something that's going to be announced to reinvent, but this is a huge deal that changes fundamentally the architecture of networking and AWS, or at least gives you the ability to change fundamentally that architecture. You know we can, all we can. We can get NVAs in the data path now without having to do like kind of weird service insertion routing, and I think there's just so many like. My brain was blown up since I saw this and I'm already excited about all the options. What do you think, chris?

Chris Miles: 7:17

Absolutely. Yeah, I'm hoping this leads to something bigger, but even on the surface is, if this is it, this is still huge. This will definitely change the game, for sure. All right, and then the wrap out the news we got some growth and earnings reports from each of the top three. We got AWS, microsoft and GCP. So let's see, let's get into it. How did they fare this go?

Tim McConnaughy: 7:42

around. So Alphabet, which is a parent company of Google, pretty much went a little less than flat, like they miss the expectations. All the expectations are missed, although not a huge amount. That was the first. That was the first one I managed to see. Of course, amazon or AWS announced theirs just what just yesterday. So I had to kind of wait for all three to really draw any conclusions. Surprisingly maybe not surprisingly actually Azure completely crushed their number, like absolutely blew it away. The expectation was like 23.6 billion and they came in over the top, or 23.6 billion, sorry, they came over the top with 24.3 billion, so like a full 700K over revenue expectations. But then their growth is absolutely nuts. They expected 27%, got 29%, and all I can think of is in this economy, Just a slight correction not 700K over, 700 mil over.

Chris Miles: 8:39

Oh sorry, I said so. Yeah, good call.

Tim McConnaughy: 8:42

I said K yeah, sorry, yeah, I should learn how to.

Alex Perkins: 8:46

We're talking big boy numbers here too.

Tim McConnaughy: 8:48

These are CSP numbers, not enterprise numbers, right, Exactly. And then AWS. So here's the thing AWS is like the 800 pound gorilla of CSPs, right? So when you get to that size, any growth is hard one, and here they grew their revenue percentage by about 12%, but the actual revenue number stayed almost exactly flat with what it was. The growth number is the same as it was in Q2. So we're just seeing basically just kind of treading water. Keep it going from Amazon, from AWS, rather yeah. What do you guys think about that? Alex?

Alex Perkins: 9:23

Yeah, I mean, obviously the Microsoft one to me is just crazy. I mean, that's is this? I guess I haven't been paying attention like historically, but they more revenue than AWS, right, like is this? Like a new leader? This is a weird moment, it seems like. And 12% growth for AWS compared to 29% growth for Azure. Those are insane numbers. The Wall Street is like if AWS okay, we'll take GCP right their stock fell after they missed by 200 million. Yeah, like Azure beat by 700 million. That's just, the numbers are just insane. So it's crazy. Chris, you got any more to add?

Chris Miles: 10:10

Yeah, I think it's very interesting, especially because I don't even think I mean, I'm by no means a financial guru or anything but I don't even think we really have time, or we've had time, for these generative AI services to even have an impact on the bottom line in these earnings reports yet right.

Chris Miles: 10:27

So, it's like this is drastically probably going to change in the near future. But I mean, with the Google thing I feel like we talked about this earlier, I think on our episode with Peter Jones is like that generative AI market is definitely eating into Google's ability to deliver on all fronts. Right, they've got bigger fish to fry. The cloud market is kind of like not an afterthought, but it's obviously their I would say their side project the advertising and everything is their main market, right, and they're even, and now they're dealing with the anti-compete restrictions and things like that. But, tim, you said people are acting like this was the end of the world for Google, like on social media, like everyone was blowing up. But yeah, I mean, it doesn't seem that subcuse, I was surprised.

Tim McConnaughy: 11:17

Well, maybe the expectation was higher, I'm not sure. Right, like I'm not a wall, I don't watch Wall Street, so there's, like you, right, I got real work to do, you know. But no, I mean, it's true, like everybody was kind of like, oh my God, you know, this is it? Like you know, has Google peaked and everything.

Alex Perkins: 11:36

Here comes Google Yep, they're going to cut the service If you're on. Gcp watch out, it's going to get, you're going to get killed.

Tim McConnaughy: 11:44

Well, that's the problem is that Google's kind of like, you know, made their own bed, you know, with their willingness to just kill stuff.

Chris Miles: 11:52

Okay. So yeah, let's get into today's episode. So, as I mentioned at the top of the episode, we have a very detailed discussion with Justin Davies and Alexandra Wiedes from AWS. I will say, if you're plugged into the cloud networking world on LinkedIn at all, you've definitely see Alexandra's name come up. She's always posting about new and exciting stuff. She's always on their Twitch stream talking about networking. She's a great advocate for it.

Chris Miles: 12:20

So it was really exciting to be able to have them on the show today and talk about the BC lattice, which is, you know, a game changer for not just cloud networking but specifically application networking. And you know, there's kind of been this unsureness amongst networking people about you know, does this, does this take away, you know, some of the capabilities and things for network engineers, and we definitely cover that in the episode and I think it they were very transparent and it turned into something really good. So hope you guys enjoy it. Coupled with this episode, we also do have a video demo that is part of the cloud demystified series for VPC lattice. So really cool stuff.

Chris Miles: 13:01

Aws actually provided us with some exclusive content. Two of their cloud networking solutions architects provide a demo of deploying multi-stack applications multi IP stack, I should say applications on VPC lattice. So check the show notes if you after the episode, if you want to get a little bit more meat off the bone, so to say, for VPC lattice, and see some actual implementation and it's yeah, it's really cool. So hope you enjoy it.

Alex Perkins: 13:31

Hello and welcome back to the Cables to Clouds podcast. My name is Alex Perkins at Bumps in the Wire on Twitter, and I will be your host for today's episode. Joining me are my two co-hosts, tim McConaughey at Juan Golbez and Chris Miles at BGP Main. How are you guys doing today, chris? What have you been up to lately?

Chris Miles: 13:50

Not much, man. It's a very early day for me today Luckily we were talking about this earlier, but I'm up before the birds, so hopefully we don't get too much chatter from them. But yeah, we have some lowerkeets that love to come and eat sunflower seeds and grapes and stuff like that off of our windowsills, so hopefully they don't show up right in the middle of this. But otherwise I'm doing good.

Alex Perkins: 14:12

Awesome. All right, tim. How about you? What are you up to?

Tim McConnaughy: 14:15

Well, not much. We had Father's Day yesterday. I went to the Ashboro Zoo with the family. You know, we did the whole Zoo Fari thing we ride around in one of the zoo buses like inside the enclosure and get side-eyed by rhinos and stuff like that. It was all right, it wasn't too hot and we had to head home early because I had to let the dog out and everything, but it was good.

Alex Perkins: 14:41

Nice, I have yet to go, but my wife's like entire family that lives out here goes all the time, so I'm sure I'll be going sometime this summer, real soon.

Tim McConnaughy: 14:50

It's a good zoo, man. You should go yeah.

Alex Perkins: 14:53

I know our last recording. I was just talking about how the weather was so beautiful out here. It is supposed to rain Today's Monday. It's supposed to rain until Sunday, so there goes that weather no-transcript. That was so great, all right. Well, today we have two very special guests Alexandra Juarez and Justin Davies from AWS. Why don't you guys go ahead and introduce yourselves and then we will jump into today's topic? So, alexandra, why don't you go first?

Alexandra Huides: 15:20

Awesome, thank you, thank you. So, yeah, happy to join you folks today on the podcast. My name is Alex Juarez and the second Alex here on the podcast, so we should make sure we don't confuse each other. I'm a networking specialist solutions architect with AWS and strategic accounts, and one of my areas of focus and interest is how to help AWS customers simplify their network architectures. And we are here today to talk about one of my favorite services. So, yeah, I'll keep the suspense of it, not share the name.

Justin Davies: 15:59

Hey everybody, I'm Justin Davies. I'm a product manager in the EC2 networking organization in AWS.

Chris Miles: 16:07

And I focus on kind of the higher level stack of networking, so we call it application networking.

Justin Davies: 16:12

Vpclatis is one of those. And I've been at Amazon for about seven years now, but I think traditionally I'm more of a regular networking person. Cisco, juniper, all those kind of things are my background. But Amazon obviously turned that upside down and I had to learn a whole different kind of fake networking. So that's the stuff I work on now.

Alex Perkins: 16:32

Well, good that you guys both come from more traditional networking backgrounds, right, because that's really the point of our podcast is bridging that gap. And yes, as Justin called out, so today's topic. So really, it's another installment of our Cloud Demystified series, as we're calling it, and the topic this time is another AWS product called VPCLatis, and it's pretty new, was it just announced? Last re-invent?

Justin Davies: 16:58

Yeah, we announced it as a preview in November at re-invent and then we took a GA end of March, prior to the end of the month.

Alex Perkins: 17:10

And this product, I guess, really has taken a lot of ideas and meshed them all together into one and I think it's changing a lot of the ways that people are looking at networking. I know the three of us talk about it all the time, about all the cool possibilities and ideas and designs you can come up with. So the goal today isn't really necessarily to do a deep dive as much as we'd love to. It's going to be kind of hard to do in an audio format, but it's really more just to get a handle on kind of how it was made and what it's designed for and the things it can do and the architectures you're seeing come out, stuff like that. So I guess why don't we get started with a brief history of VPCLatis?

Alexandra Huides: 17:50

I think Justin here is the person who can share that from the beginnings.

Justin Davies: 17:56

Yeah, so I mentioned earlier before been at Amazon for about seven years now. And when I originally came on, I was a solutions architect, like what Alex is working on, and a lot of the time it was really deep networking stuff.

Chris Miles: 18:09

It was like how do I connect my?

Justin Davies: 18:11

big, big data center with your big big data center and how do we do all these kind of complicated things for really advanced customers? And that was kind of like a fun little journey up front because everybody was kind of just figuring out can I trust the cloud, Can I move to the cloud, Can I do this kind of thing, that kind of transitioned? There's not many customers that are scared of the cloud anymore I'm sure there's some but most customers are like OK, cool, I can kind of trust Amazon, this is OK. And so when you do that transition, a lot of the time people went with that whole what we call lift and shift model. They just take whatever they know, they move to the cloud.

Justin Davies: 18:39

It's great. It allows you to move really fast, Gives you an API for a lot of the things that you're used to. But when you get there, then you've got to try to figure out OK, is this optimized? Chances are it's not Doing the same thing you did back in the day in a traditional network. If you did it the same way in the cloud, it probably would be more expensive. It probably would be even all the things that just not good. And so usually they use that as a migration pattern, and then they try to figure out how can I optimize this over time.

Chris Miles: 19:04

Now. So this is the one step.

Justin Davies: 19:05

It's just like, ok, moving to the cloud, getting there, getting used to things. And we built a lot of the primitives to help customers get there. Vpcs it's kind of like the virtual data center with an API. It's got route tables, it's got subnets, it's got network ACLs and security groups, which are like little firewalls that you can put on instances. And then customers didn't just build one virtual data center, aka VPC, they built a ton, they built hundreds of thousands. So they needed to connect these kind of things and dealing with them onesie-toosie with VPC pairing is kind of crazy. So then we built virtual routers, things like transit gateway and a lot of customers that do all this kind of stuff, and that was kind of solving these network level tasks. So now there's that part.

Justin Davies: 19:47

But when you look at what these people are bringing to the cloud, the applications that they're bringing to the cloud, it isn't just routers and switches. There's an application on the ends of these things. The internet with a bunch of routers and switches but no application on the other end would be super boring. So you need something on the other side and this is where you need some higher level stuff. Service discovery could just be DNS things to actually figure out where I'm going. So they have a DNS URL, application load balancers. How do I actually load balance, the scale up, scale down, all that kind of stuff? If you're more advanced and you're more security conscious things like authentication, authorization, all those kind of things this is all kind of what helps build application network. You got that networking underlying stuff and then you got the application portion that helps actually build an application, and so over the years we've handed off a whole bunch of permits.

Justin Davies: 20:34

We did the trans-gateway, like we already talked about. We've had the Elastic Load Balancer portfolio, like we haven't really talked about, but it's basically the load balancer functionality. We've got network load balancers, application load balancers, gateway load balancers, which is a whole different animal, but it's all these different bits and pieces. On top of that we've got service discovery mechanisms like CloudMap and Route 53, dns versus API driven stuff A little bit of a different approach, but still service discovery and these are all puzzle pieces. But over the last several years we figured out like hey, if we combine these kind of things, can we simplify this with a customer so that it is just one managed solution? And so that's the direction and kind of where this came from is can we build a product that helps solve a lot of these things without making a customer deal with onesie, twosie APIs just to build this whole thing from scratch? If everybody's doing this and everybody needs it, can we build a solution that just does this thing out of the box? And that's kind of the place we wanted to start.

Alex Perkins: 21:23

OK, yeah, that's a lot there.

Alexandra Huides: 21:27

To add a bit to that from the perspective of I think we keep having these conversations with the different personas, the network folks who are used to building or putting together those puzzles and those primitives to achieve network connectivity, as well as with the application folks who are dealing with the higher level primitives, right, the elastic load balancers and API gateway and all that stuff there.

Alexandra Huides: 21:54

So having these conversations with these two different personas, we've noticed over time that there is maybe a perpetuation of that siloed approach from like network and applications and like the network people do their network stuff and we put together transit keyways and we put together VPCs and VPC peering and privately and can points and so on, without really really really knowing how application folks are using those and what are the application patterns and what would be that optimized approach, because Justin mentioned at the beginning a step into the migration processes to actually try and see where you can optimize. So that was kind of a gray area. So I think probably this is what makes VPC Lattice one of my favorite services is that it brings these two personas together, probably for the first time. I don't know if the first time the first time, but for this cloud journey that means togetherness, right, instead of having the siloed approach and each team building their own stuff and trying to figure out afterwards if they actually interoperate.

Tim McConnaughy: 23:08

So I was thinking about this application networking and I was reading about VPC Lattice and trying to understand it. I didn't want to understand it too much because I wanted to still have that perspective of I'm a networker learning what is VPC Lattice for. And I wanted to hold on to that for this podcast before I really dive deep into it so I can think of the right questions to ask. And don't let me forget, because I want to get into the hybrid networking piece of it earlier you mentioned, Justin. I really definitely want to get into that.

Tim McConnaughy: 23:35

But we're all networkers here. We remember Cisco ACI right, that's like the first time I can remember application networking being a term, right. But we all know that nobody runs ACI in application networking mode, right, Everybody runs it network mode and not to pull the direction in that way. But what do you guys think about? Maybe why that happened and maybe how Lattice is going to, I guess, solve that problem that kept application networking from being adopted, I think something that my career and traditional networking side of the house for 20 years now I've been hearing.

Justin Davies: 24:13

we're going to build an SDN and the service providers a lot of the time were just like, okay, yeah, we're going to build an SDN. And all that meant was can we do service training? Can we insert a firewall? Can we do this, can we do that?

Justin Davies: 24:23

We talked about it for a long long time there was some marketing terms around the self-driving network and there was other terms of just different things, and ACI calls into that category too, and they were all great advancements but they wasn't really kind of like getting to what we all kind of thought when we were all listening like yes, I want to see this.

Justin Davies: 24:37

But in the end, when you think about like a true SDN, think about VPC in the cloud, like that is what I would say a really good execution of an SDN, right, software defined network, it's true, and that was the first time where people did this, but why it was so successful is because we built the same primitives to help customers get there, like we made the same thing that they were already used to. You can build a data center it's called the VPC. You can build route tables, you can build submits. Oh, you could have availability zones so that you can have like multiple data centers. You know, like all those kinds of things. Lost my train of thought of what the original question was.

Tim McConnaughy: 25:13

Oh, just how lattice is you know? Because ACI tried application networking and it kind of, really, just kind of failed.

Justin Davies: 25:21

So on that topic, like all the things we just talked about are all those kind of infrastructure components right? So like the bridging the gap to help customers understand like, oh okay, all this stuff is familiar to me, but what wasn't familiar is the things that were actually connected. Like 20 years ago the concept of microservices wasn't quite there, right, and the idea of having dependencies and service dependencies wasn't quite formulated and there was some super advanced customers talking about service-oriented architectures, soa type stuff. But it was kind of like nobody really kind of got it, especially the networking folks. The software folks might have understood it, but the networking folks were just like just tell me what submits you want to connect.

Alex Perkins: 25:56

Tell me what firewall ports you want to open up.

Justin Davies: 25:58

Those kind of things. But over time, moving to the cloud, help customers understand like, oh, there are these things and they have dependencies at each other. How do I do this kind of stuff? And traditionally over the last couple of years they've been very, very disjointed. But what VBCLadis helps with is put some definitions around what a service is in the first place and so that when customers register this thing as a service, now I have something like that I can hold on to they're like okay, cool, this thing needs to talk to this thing. Right, and this thing is an HTTP service living on port 443 and it's hosted on a serverless platform. Like you can define these things. There's something you can grab on to Versus. It wasn't, there was never really that before. Right, there was DNS where you could have like a, an, a record pointing to something, or a C name pointing to a different URL, things like that. But it wasn't quite the same as having like a definition for an actual artifact, like the thing that you want to talk to things.

Justin Davies: 26:54

So that is the first kind of step, and that's one big piece of what VBCLadis does is it helps you define that thing?

Alexandra Huides: 27:00

And I think, in addition to that, it's probably that's where the bringing together the application and the network folks comes in strong, in the fact that whatever network engineer you're asking about connectivity and say, okay, get me, get me onto the network, right, the first question that they're gonna ask you 99% of the times is tell me about your traffic flows, right, what needs to access what, right. So all like 99% of the answers, the times that the application folks are answering that they're like these services need to talk to each other, and they're like in the CKS cluster or they, I have multiple clusters, I have ECS tasks, and all of a sudden the network person is like wait, what? What is an ECS task? Again, like, tell me, tell me that one more time.

Alexandra Huides: 27:58

So there wasn't any common ground where the network person could get what they needed to actually provide network connectivity right, which is, tell me who needs to talk to who. And there wasn't that the other common ground where the application folks could bring what they knew needed to talk to each other right and translate it into words that the network person could understand, which, in VBCLadis, changes radically because you have the construct of service and you have the construct of accessing a service and allowing the service to be accessed. So it's very simple, it's very straightforward and it essentially meets both needs of the two personas. In terms of starting with language, right Like, let's try to understand what we're doing here.

Alex Perkins: 28:42

It does seem like and I think we probably all agree on this call that there's like a gap between Justin you called this out right when you were doing your intro. You were saying how you moved into like the higher level kind of the higher up the stack networking. There's such a gap between traditional network engineers and then application networking. And it's like this is it's almost like you guys are abstracting it so that it's so easy Like you just have to work together because it makes it so easy to do that and to talk between the two. So I don't know, do you guys have any thoughts about why there's a gap there? And I guess really what network engineers need to know about application networking? Right, it is really the question here is why aren't they learning these things?

Justin Davies: 29:23

Couple funny, funny thoughts. It made me think of two different things when you were bringing this up is one like walking up the stack, and I was meeting the OSI stack right, the OSI model, walking up the stack from one to seven. And I just this has nothing to do with their conversation, but just this idea of like, when you look at that OSI model, no matter how deep you are when you question people on like five and six players, they're like what the heck is going on in five six.

Tim McConnaughy: 29:47

Is there anything actually happening there? Like, is this kind of like a stick out?

Justin Davies: 29:52

The other part that I think a lot about is I mean, I first got introduced to this idea of like a full stack developer a little bit before I came over to Amazon, where it was kind of like the hot thing, right, everyone's trying to hire, hey, I want a full stock developer. And at the same time it was when everybody was not even me like hey, network engineer, can you go learn Python? And I was just like, oh manly, like it's one of the two, and I do know some great full stack developers. I also know some great hardcore engineering software developing network engineers, it's just like are you really playing the people's strengths Right?

Justin Davies: 30:26

I don't think we are, and so the idea of making people learn more and be able to execute more and really trust that they're doing it right I don't. I think that's a broken model, but I'm all for people learning more, but I really think we should start abstracting things that we can so that people are freed up to do the thing that they're really good. Right, and so like a developer probably shouldn't be dealing with PPC route tables right, they probably shouldn't even be dealing with, like the compute infrastructure under there.

Chris Miles: 30:51

There's probably some dev off without architect.

Justin Davies: 30:53

It's like doing that. The developers probably dealing with.

Justin Davies: 30:55

GitHub right and like really trying to figure out what is my product manager asking me to build Right. That's the thing I really think that they should be good at. Should they know what an IP address is? Should they know best practices from being able to implement IPv6 and things like that? Totally, Like absolutely. But I don't think that they should be really focusing on making sure that their subnet mask is configured Alternatively. Now, if we flip the switch and go to the programming dev off, see, network engineer. Do I think they should be really the script monkey or the person that's configuring the business logic and all that kind of stuff? Like no, the thing that they're really really good at is understanding architecture, not just even networking, but just like scale.

Justin Davies: 31:35

How do I deal with this? Right, how do I reason about my capacity, projections, things like that? That's what I want my network person dealing with, and so I want to build something that gives an interface to each of these people and helps them communicate with each other Right, and I don't mean communicate, like from a networking perspective. But the developer wants a super user, easy user experience, right? What's the thing that I need to build for that? Okay, well, I need to abstract away. I need to let them define their service, put the code and register it.

Chris Miles: 32:01

Now, this thing shows up as this Okay, I'm a service. What do you want to do with it?

Justin Davies: 32:04

And the developer, the program that serves, probably doesn't need to do it Like I don't know what. Who needs me Right, who needs my, who has a dependence me on me? So now it gives the network operator the security operator, some sort of admin.

Justin Davies: 32:15

Someone writing the admin hat the ability to say cool, I want that, that, that that all to go in together so that I can write common policies, configure it however I need to, and then I can share it around with whoever needs access to it. Okay, so, like giving the tools and kind of controls to an admin without them having to reason about the code and having to figure out what that thing's doing, but then giving a user experience that the developers used to right. Like giving these things but not making them two different layers. Traditionally, these are two different layers. Right, you have the application living on one thing. You got somebody configuring load balancers and then you got somebody configuring the network and it's IP addresses at the network level, it's URLs and domain names. At the application layer, then it's code behind the scenes and these are all three things that you need to look at.

Justin Davies: 32:57

At 2am there's an outage and everybody's pointing it's a network problem and you have no idea of what that IP addresses, because in the container world, that IP address was like five different things within four seconds. I don't know what the heck that is. So, bringing that together and making these things more unified Of course there's layers, still right, of course there's different layers, but being able to provide a user experience. The customers can actually differentiate these and everybody can talk together. I hope that kind of helps a little bit with the constructs.

Alexandra Huides: 33:28

And I think to the initial part of this gap and why this gap is out there. I think it is for, to double down on what Justin mentioned there's folks who are going to be good at a layer and there's folks who are going to be good at a different layer. Right, and taking my own example from when I was in college, I was like dude, I can't see like programming, I can't see the beauty of it, I'm not going to be a brilliant programmer because I don't have that spark right. So what else can I do? I was like, oh, networking. And then I took my first Cisco class actually, and I did a ping between two virtual routers in packet tracer. I remember it today and I was like, my God, this is working and that was my spark right.

Alexandra Huides: 34:17

And I truly feel that there's a lot of folks out there who are like I don't want to deal with the metrics, I don't like it, and I'm very good at what I'm doing, which is this software development piece and the same in the other boat, and I think that, at the end of the day, talking or having the possibility of talking that same language has been a big gap so far because of the lack of probably words and primitives to get there. I remember that probably 99% of my 2am calls and tickets that got escalated were my application is not working. And my question was okay, can you show me what's not working? And I saw like a curl that was timed out and I'm like, okay, can you tell me more? I don't get what's like. Tell me your path, tell me your VPCs and knuckles and security groups and are you?

Alexandra Huides: 35:12

connected to Transigura or are you paired with Transport and essentially into a session of two hours of them describing to be their architecture? So I think that's where the probably the biggest friction point is. Because a network folks ask for something, application, folks deliver something else and the other way around. Tell me your flows, let me. Let me think about that.

Chris Miles: 35:37

Yeah, that's a great call out, because I think that I think, just going based on that, you, the VPC lattice, from what I know at least, is going to change that conversation, right, you're going to say, you're not going to say, you know, hey, my curl isn't working. I'm going to say, hey, this service that I'm subscribing to isn't working, or something like that, right? So I guess, based on that, maybe we should kind of circle back and go through what the basic constructs are of VPC lattice, because I know we've talked about registering a service and a service directory and lights, things like that. So maybe let's, let's go over the basic components. We don't need to spend you know hours on it or anything, but I know we, I know there's a lot to it, but yeah, can we, can we cover, like, maybe, what the basic constructs are for lattice?

Justin Davies: 36:18

So these are all new features and constructs built into VPC. So if you're familiar with VPC, that's a good starting point. You're already most of the way there. We introduced kind of four new things. The first one is this concept of defining a service, and this is, behind the scenes, just a DNS URL. Okay, it's just a DNS URL, behind it something that's configurable, just listeners, rules and target groups. And if you're familiar with kind of the elastic load balancing portfolio or products, it'll be very similar where this is where you can actually define what this service is. This is maybe an HTTP service, maybe it's HTTPS. You got TLS on it and stuff like that. And I'm listening on Pope 443. Maybe I put some rules in there to say, if you get a get request, send it to this target group. Your target group is basically like the back end compute that's actually running the software. You might have a default, maybe you don't have any rules.

Justin Davies: 37:16

Maybe the rule is just like if you come in on Pope 443, send it all to this Lambda function or send it all to this EC2 instance. So it's basically a service, is just kind of a definition that you are basically saying I'm going to register this thing as a unique entity. That somebody might have a dependency on. So that's, first and foremost, a very important permit.

Alex Perkins: 37:35

Are there real quick? Are there what can be a service?

Justin Davies: 37:40

Yeah, perfect. So today we support HTTP and all the different variants. So that is things like GRPC services and HTTP endpoint and HTTPS service Think like APIs. For the most part, there's much more than APIs. We've got some customers that are doing, you know, database connections over HTTP and things like that as well, but right now it's really HTTP endpoints, which is kind of those API transactions. In a microservices type world it doesn't have to be microservices but does that kind of make sense?

Alex Perkins: 38:08

Yeah, it does.

Tim McConnaughy: 38:09

So when we register the service, then the services are just a logical stand in for the actual like it's a logical created rule set, if you will. For the thing is what you're saying.

Justin Davies: 38:22

Yep, is there, like completely made up place marker that says, hey, I'm going to give this thing a name, payments, right, this is my payments app. I'm going to give it a name, and then behind it, payments might be a bunch of different things. Right, payments might be payments slash, user one right, or header equals user agent equals Justin, or you know all these different things. Those would be microservices within the service, right, so you can do all kinds of things. But what? The DPC lattice services? Just this logical kind of front end saying, hey, here's a DNS address.

Justin Davies: 38:57

What do you want to do behind?

Alexandra Huides: 38:58

it, and I think you just mentioned the pieces related to application that are part of the service. But another super important piece of it is that this service can span across multiple compute types, which I think is great from the perspective of I do have a service that's running on EC2, let's say right, and I'm actually wondering how will my service perform if I would put it on a Lambda function or I would put it in EKS and containerize it? So what you can do is abstract behind that service payments, right. Target group one, that is, your EC2 auto scaling group, for example. Target group two, which is your Lambda function or your EKS service, right, and you can say well, I want to actually see how it works.

Alexandra Huides: 39:44

Right, so you reroute part of the traffic using weighted target groups within lattice within the lattice service, vpc service definition and you can say I want to send 10% of my traffic to my Lambda function and see how it works and if it works fine, you can continue with your deployment. So it also gives you the ability to span services across multiple compute options, which goes a bit into the network aspect of things, because usually to get services to sort of get that type of connectivity or front end between multiple compute options requires a lot of networking under the hood right. It requires that connectivity setting across VPCs, accounts and so on.

Alex Perkins: 40:34

It makes you think of, like, if you're refactoring an application right, it's like a more monolithic style, right it's running on some EC2 instance and you're trying to refactor it into a microservices architecture, that's amazing because you can break off pieces of it and just route to, like a chunk, one of the microservices and, as you said, integrating.

Alexandra Huides: 40:55

Yeah, and one thing that we've actually discovered last week was that it is actually the answer to migrating to IPv6. I love this. So it's been the crux of all network engineering folks existence of saying folks, application folks, you got to get to IPv6. And application folks would say, oh, but we don't know how our application is going to break if we put it on IPv6. Well, with VPC lattice you can have a service with two target groups one on IPv4, one on IPv6. And you can slowly migrate traffic to the IPv6 target group and you can see if it breaks, irrespective of whatever your client is doing. It's a complete separation and abstraction of IP addresses.

Alex Perkins: 41:38

Oh, lots of people are going to love that.

Justin Davies: 41:41

Yeah, double click on that one, because I think from networking folks I think a lot of your audience probably hardcore engineers would probably like this. I'll go a little bit deep, but not too deep, and then we can always come back. But essentially we're abstracting away the underlying IP type stuff for customers. Again, like we touched on before, like I think, until we die all this stuff's still going to be there like under the hood. It's just layers of abstraction on top of that, right. That's all like if you came in one of our data centers, you're going to see routers, you're going to see switches, you're going to see lots of IP address communications. But we're abstracting this stuff away, right, and so with lattice. It's the same kind of idea. And what Alex was touching on with the V6 stuff is when you register a service, when customers connect to that service, we want it to be kind of invisible from an IP perspective.

Justin Davies: 42:22

Okay, so when I register my service, it can be on IPv4, it can be on IPv6. It doesn't matter. It's in some VPC and it's something. Once I register it, I give you a DNS address by default. When I give you that DNS address, I configure it with V4 and V6. It's dual stack. To begin with, you might not even be on V6. You're going to get a V6 address anyway, and so what? I don't care what your app's doing, you don't need to refactor anything. It can do whatever it's doing. Now, when the client goes to do a connection and say hey, I want to talk to you.

Justin Davies: 42:50

If that client is on V6, well, it'll just connect to your V6. If it's on V4, it will connect to V4. Right, it gets that.

Justin Davies: 42:56

DNS response that, hey, this is dual stack, which one do you want to use? And you can connect to whatever you want. Lattice will then get that request and figure out what to actually do with it, send it to that service. It does the network address translation for you. You don't need to think about that, but behind the scenes it's all doing that stuff for you. Okay, so this idea is that even though those IP addresses are there, we don't necessarily want the developers and the people that are managing these things to have to think about. We want to abstract that as much as possible to give it a much more user friendly experience. The admin, of course, has knobs that they can dial into and go and look at things and all that kind of stuff, but it's not on by default. So it's very, very simple by default.

Chris Miles: 43:33

I think I already know the answer to this, but so does that? Does that change whenever the product is expanded to support more than just HTTP GRPC type payloads, like if we move further down the stack with regard to IPv6, does that, do you see that changing, or is there going to still be that level of transparency where the user just has no idea?

Justin Davies: 43:56

With HTTP we can do a lot of cool things, especially if we participate in the TLS handshake. If it stays encrypted, there's not much we can do, it's just like okay what it is. But if you participate in TLS, you have that handshake. Where VPC lattice is the gating process.

Chris Miles: 44:11

We can look at HTTP heads and that is super powerful because then you can figure out what does this thing actually want to go to, and that's a much more rich set of things I can look at to do different instructions.

Justin Davies: 44:22

Oh cool. The user agent says blah, send it here. Oh, the host name says foo, send it to there. So I can do a lot of manipulations based on that information. As we go down the stack to other protocols which we're looking at right now but we don't support yet. Some of that stuff will need to go away and it'll be less abstractions, but we'll do as many abstractions as we can. So, if you think about something like layer four or TCP, what is a TCP connection?

Chris Miles: 44:49

Well, it's an.

Justin Davies: 44:49

IP and it's a port, and so you can abstract that by making it very, very simple and not making the customer define what IP address it is, what port it is and stuff like that, but still an IP and a port. And so the real benefit is when you do start to walk up that stack, it's again more and more abstractions that you can create without having to be very easily.

Chris Miles: 45:08

Right, so basically, you want everyone to just build HTTP apps and then all the problems will be solved, right?

Justin Davies: 45:14

No, I think most customers that are more on that kind of microservices journey or just have kind of service dependencies. I don't like the words microservices, to be honest, because I think when I talk to some banks and things like that very, very technically savvy organizations a lot of the time but they on purpose don't move super fast right, because they have compliance and different things that they want to look out for. And the term microservices to a lot of these type of banks and things like that is terrifying, so like hey, I've got this app.

Justin Davies: 45:42

It's never going to change, it's 40 years old, so on and so forth. It's a big model and it works great and it's secure and all this kind of stuff. That's what I understand. That's totally fine. That, to me, is a big service, and that thing might have multiple services in it, right, and it might have a dependency on something different. It's an API or something like that. What?

Justin Davies: 45:59

I find when I talk to most customers is that most of the service to service type transactions are HTTP and then you got about, you know, 5%, 10% of it that's something different your database connections and things like that. So that's kind of where we started with with HTTP and I think it covers most use cases. But for those other ones, vpc lattice isn't changing VPC as you know it today. It adds a whole bunch of new features and functionality to it automatically when you turn it on, but the VPC is still the VPC. If you do a DNS request and you're looking up some service that's behind a private link or behind a load balancer and transit gateway and all these other primitives, it's still going to get there right, it's just going to take the other path.

Justin Davies: 46:37

If it sees and knows about it in lattice, it'll go take lattice. If it finds it and it's something else, it'll go take the other path. So I want to be conscious. We've only talked about service right now.

Tim McConnaughy: 46:47

Yeah, I know we've taken the time there, sorry.

Justin Davies: 46:49

No, no worries. I think it's a very important thing and it's new to a lot of people that are in the networking realm, right, and so it's really important. I say take time to understand that primitive because it is a very important one. Everything is built off of that right. If we didn't have services, what are we doing?

Justin Davies: 47:03

There's nothing you know like if I, if, if you know, I'm trying to think of what I, if I go to Instagram or something like that, like what is it Okay? So, now that that's there, we need a place to actually see all the services.

Chris Miles: 47:17

I create and all the services that were shared with me. So we created a service directory.

Justin Davies: 47:20

This lives in the VPC console and it's nothing more than just a visual representation of all the services that I created or that were shared with me. We can get into that in more detail in a minute, here it's just a service directory, okay.

Justin Davies: 47:32

The developer likes it because it's one place that they go to. They copy the URL of the service they want. They put that in their code. That's why the developer likes it. Good user experience the admin likes it because it's one place to say what the heck does that account have access to, what are all the services it created and what are all the services that were shared with it, Right, so?

Justin Davies: 47:51

it's again you'll see this as a theme of like the personas, right? What's the tool for the admin? What is the user experience of the developer? Of course, we care about the user experience for admins too, but you know, that's all of us, so we're fine. So okay, any questions on the service directory.

Alex Perkins: 48:06

Yeah, Can you see it Like how do you? How do you see it? How do you consume it?

Justin Davies: 48:10

Well, there's an API call. You can do the CLI or you just go to the VPC console. Just log into AWS, go to the VPC console and you click on your services and you will see the whole service directory there, all the services that were shared. It's an account level view. If you're super savvy with AWS, this is also an important reference. So it's all the things that are within your account. So if a different account shared something with you, you can share a service. You'll see that as well.

Justin Davies: 48:34

Now, all these things were created. They live in the service directory. They're just sitting there. What the heck can we do? We want to do something with it. We created something called a service network. You can think of this as a grouping mechanism for these services.

Justin Davies: 48:45

Okay, so everyone on here has probably been around the days when you were going through basic networking classes but you learned things about like non networking type stuff, like active directory or this concept of users and groups configure a bunch of users and you can put a bunch of permissions on them. But if you've got thousands of users and you want something applied to all of them, it's kind of tedious to do it to a thousand users. So you create a group. You create all the common stuff on the group and then you put the most specific stuff on the user. Same concept here. We created a grouping mechanism called a service network that allows you to put services in, and this helps you do two or three things. First thing is you can apply common permissions. You can go into what that actually means off policies as to who has access to talk to one at the service network level.

Justin Davies: 49:29

You can also do it at the service level, Same way you would with users and groups. So it's just a collection. I want to point out that this is different than a service mesh Some customers like to think of hey, is this a service mesh? Is this not a service mesh? Totally different. Okay, so don't go down the path of thinking this is a service mesh. It'll break your mental model and just don't go down. Okay, we very purposely said we didn't want to build a service mesh.

Justin Davies: 49:50

So this is a service network. It's a grouping mechanism. Just because you put your services in it doesn't mean they can all talk to each other. It's just the grouping mechanism. At this point, to get connectivity to the things in this service network, you associated with a VPC and that is the network connectivity piece. Once that is enabled, once you take that service network with all the services in it and you associate it to a VPC, now everything in this VPC can discover it and connect to it. The grouping mechanism for policy. It's also the thing that's used to implement the connectivity. The admin in an organization typically owns this thing, runs this thing. The developer or some sort of DevOps person typically owns the service. You can also turn on centralized observability on this thing. So it's like those are the three things you can do with it. You can put policy, you can enable connectivity and you can enable observability, like logs and metrics, to a centralized place.

Tim McConnaughy: 50:40

In my head. I just like and again my purposefully did not read too deep on this so that I could explain it and I could add the right questions. It sounds like what we're talking about is like almost like an orchestrated set of private links to a logical grouping of these services. Is that fairly accurate?

Justin Davies: 51:03

I love it, yeah, no, so it depends who I'm talking to. We always end up like I love listening to Alex actually describe this stuff when she's talking to customers, because she does it a different way than I do, I do a different way than her. It all depends on who the audience is, because if it's like a service mesh type customer, I start out and I say, hey, so it's kind of like a service mesh, right when it's doing connectivity. It has a lot of the same features and functionality, it's just implemented a little bit to a more network savvy audience. I typically go down the route of saying like what if you combine an application load balancer and a transit gateway? Right, what if you combine those two things?

Justin Davies: 51:34

But some customers are like oh, it's kind of like privately too, it's like handling that and all that kind of stuff. Absolutely Right, like these are all things. It's higher level than privately. It's all seven versus all four, but this is exactly the same kind of construct but instead of having to deal with the NIs and kind of all that kind of stuff, subnets and all that, it's a much more abstracted version of over the last seven years, we've seen customers using things like API gateway, things like transit gateway, things like app mesh, things like private link, things like blah, blah, blah, blah, blah, blah, blah. This is taking that fresh look and saying, okay, now we understand how customers are using these things. What if we built a more simple version that bundled these things together? Okay, behind the scenes it's not really these things bundled together, it's a new platform. But that's the kind of mental model. We understand how modern applications talk to each other. Now let's build a system for that.

Alex Perkins: 52:21

Yeah, if you saw me laughing a lot while you were when you kept saying service mesh portion, and it's because even though I'm very much traditional network engineer I have always been. As soon as I saw this I was like this is like a service mesh. Immediately and it's interesting because I had originally thought that it kind of came from that model. But the more you talk about it it just seems like it is so different in so many ways that I just I wouldn't have got the nuance unless you started explaining some of this stuff.

Justin Davies: 52:53

You even see, in a lot of our marketing material and different things that we talk about, we do frame it as in that same kind of category as a service mesh. The thing I like to tell people, though, is just don't think of it like that, because a service mesh is very specific to a containerized platform.

Justin Davies: 53:09

And I think that's great Architecture yeah container architecture, mostly Kubernetes specifically, and I love that and we wanted to make sure that we built a very native experience for that.

Justin Davies: 53:18

But we didn't want to limit ourselves for that, because there's a lot of customers that just aren't just Kubernetes, there are a wide range of things and they still need those features and functionality.

Justin Davies: 53:27

And so if you look at the traditional service meshes that are out there, some of them have actually started to say, okay, you can do it on EC2, you can do it on this, you can do it on that and mix platform, but it's like really painful to get there because it wasn't built for that. And when we looked at this we said, okay, what would it look like if we built a platform that was universal to the underlying computer? And that's where we started right and saying, okay, these are the features and functionality that their customers are asking for. Let's build in the way for all of these so that the admin doesn't have to qualify, saying, hey, you know what developer you're only allowed to configure on EC2, because I haven't quite qualified ECS or EKS or Lambda, right, because I need to figure out how I'm going to handle authentication, authorization, all these things by abstracting that.

Justin Davies: 54:07

Now customers can say, okay, I'm standardizing on lattice and then, if you want to use Lambda or EC2 or EKS, do whatever you want, because I have a common set of tools here and I've abstracted away whatever you're doing behind the scenes and I know that I can still meet my compliance.

Alex Perkins: 54:20

You know, again coming from expanding out the gosh, the service mesh concept. Like you said, people are expanding it out to more than just microservices slowly, but it's always like a sidecar, proxy model, right, and it's like you guys have already skipped that step and expanded it out. And that's where it's like it's so different than how the sidecar, how that industry is approaching it, how the service mesh companies are trying to approach it.

Justin Davies: 54:48

Yeah, I think, like I'll point out, like we kind of cheated, we have this magical thing called the VPC and we have things like Nitro. We have these very powerful constructs under the hood that we could build something like this right, like if you tried to build it on top. You can't right, because it's like we're using a lot of this underlying connectivity to do this. With that being said, like I will say that there's a ton of cool things that you can do with a sidecar. The problem with the sidecar model and the traditional service mesh is that we've looked at this cool little shiny thing that you can put next to every workload and we said awesome, let's just do everything in it. And it's like what is that ever a good idea? It's never an all or nothing right. It's that whole centralized, distribute, centralized, distribute. There's certain things, certain features that you make a lot of sense to put next to the workload. Keep doing it. If you want to do a sidecar for just those cool, don't put your kitchen sink there, right? There's no reason that a full blown proxy and all of your services discovery needs to happen at every single node Because you scale up like disaster. Right, pick and choose what you want what VPC lives does. It says we're going to put it all in the VPC natively outside of user space and then if you want to put things inside, cool, go for it, but you don't have to, all right.

Justin Davies: 55:55

So we talked about service network. The last one I just want to point out is off policy and that is just basically an I am resource policy and that might be unfamiliar to a lot of folks that are not necessarily dealing with AWS all the time, but this is basically the thing that powers any of your authorization. You know, billion requests per second type thing, billion authorizations per second kind of thing. Instead of it just being for AWS APIs, which was what it was before, before, now you can do this for your own service to service communications.

Justin Davies: 56:23

So hands free, hands off, secrets, management, authentication, authorization, so these this is what VPC allows, uses, it's I am and you can apply these off policies to define who can talk to what at the service network level or at a service level, and this gives you control for treating it like users and groups. But some core screen stuff that the service network, these are your guardrails that the admins just like. As long as this comes from my organization. I probably won't show up on hacker news right. And then the service side be more specific, like only principles that are PCI compliant and blah, blah, blah, blah, blah, things like that.

Chris Miles: 56:58

Yeah. So I mean thinking in terms of the, the, the networkers out there, the admins out there that are currently building. You know, they're using transit gateway, they're using VPC peering, they're using everything direct connect, everything under the hood to build the communication highway for the services as they are now, let's say, without lattice. How, how do these things kind of commingle with the other network offerings that they're using day to day? Because I'm I think people have seen this and be like, oh, they're taking things away from me, like you know, the, you know I'm going to lose admin control and things like that. So how does how do these things kind of play, play together?

Alexandra Huides: 57:36

I'll take that. I'll take that. The reason for it is because that was my first question as well. Hence, we've created a reinforced session, which was just last week, about AWS Cloud Round plus VPC lattice plus verified access working all together, and I'll share the link.

Alexandra Huides: 57:59

Yeah, we need to get that, yeah, and I think that's that's probably the first question that comes up whenever I talk to the network. Persona is okay, cool. So how do I integrate this with my environment? That's one. How do I continue to manage, how do I continue to have that overarching control over the things that I need to have control over, so that I don't have my developers doing all kinds of crazy things but at the same time, how do I enable my developers? Right, and probably some of the most common questions is how do I connect multiple case clusters across multiple accounts, cross multiple VPCs, how do I overcome the overlapping IP space problem? How do I get to IPv6 and so on?

Alexandra Huides: 58:46

So the fact that, as Justin was mentioning at the beginning, service discovery is DNS based helps admins control what gets solved for by VPC lattice.

Alexandra Huides: 59:01

And actually one of the use cases that we've presented in the reinforced session was access to shared services from VPCs with overlapping IP space. That's probably 99% of use cases that everyone wants to get to, Also from multiple routing domains or environments, right? So let's say you have one instance of your artifact repository, for example, and you want that to be accessed from both prod and dev and stage and whatever. So you can choose as an admin which use cases you address using VPC lattice. You can choose or you can continue using your transit gateway network or your cloud one network, your direct connect, your internet connectivity, your inspection architectures for internet in Resigras or for VPC to VPC communication, based on your needs, and you have full control of that. So I think that's the added very powerful feature of VPC lattice the fact that because it operates at like under the hood in the VPC right, it's able to attract that traffic that needs to go to it without impacting your normal routing VGB policies, everything you're doing nicely in your global network.

Justin Davies: 1:00:17

Yeah, we wanted to pick something that was completely non-intrusive, because I think we did a lot of kind of soul searching with customers on. You know, what do they want to do? What does next generation look like? Some of the customers that had already adopted service mesh things like Istio. Most of the other customers were like things like application load balancers, and the thing that was very clear is like it's very tough to go all in on something like service mesh. It really is that I, like I need to go all in. How do I do that? Overnight?

Justin Davies: 1:00:42

When we were drawn up the board, we're saying this is just impossible. We need to make it so that it just works. If I want to put one service in and that's all I want to do, how do I do that? Right? I don't want to put all my things in, and so the way to do that is to use normal constructs that we all are familiar with DNS, right? We don't need to get super crazy with service discovery. Dns is great. It's been working for years and years. There's some tricks we've done to make it more optimized, right, so that you're not constantly worrying about having to get your TTLs issues figured out and all that kind of stuff. But like those kind of things, you put services in as you want to enable them. If the customer looks up that DNS and it happens to be behind lattice, it just goes there.

Chris Miles: 1:01:18

If you're looking at anything else, it just goes there the other way right.

Justin Davies: 1:01:22

So it's just normal, normal protocols. I think the network engineers will really like that, because it's not anything weird, it's just the normal stuff.

Chris Miles: 1:01:29

It's nice to know that, no matter what, the problem will always be DNS.

Justin Davies: 1:01:32

Always be DNS that's what I'm hearing as long as they're not working at the network let's go, point at the systems engineer. You know the DNS person.

Tim McConnaughy: 1:01:44

So this actually is a good segue, because I was going to ask and I know we're running it up time here but I think this is really important, especially to the networkers that are going to be watching or listening to the episode and thinking about lattice. A lot of them their first questions are going to be like all right, well, how do I monitor and troubleshoot it? Like, how do I know when lattice is having a problem? Because the more we sweep under the rug, the you know you lift up that rug and it could get pretty ugly under there. So what's your feeling there?

Justin Davies: 1:02:09

When we talk about more, we sweep under the rug. I actually have a different kind of feeling about it, because, while that is the case when you think about managed services, when you have a lot of them teamed up together, it can be really challenging, right?

Chris Miles: 1:02:21

Because you're like, not only doing, not a visibility, but I have a lot of different places I need to look.

Justin Davies: 1:02:25

But DPCLive has actually taken kind of a different approach, right? Is it saying I'm going to make you deal with less? Right, you're dealing with a lot less, and so, as long as I provide you the observability so that you can see when things are coming in, you're not looking at a whole bunch of different hops, there's one. You log into one thing and you look at that and it gives you a very, very simple way of kind of seeing is my service broken? Is my net service not broken? I'm not needing to look at all the underlying pits and pieces to figure this part out, right, and I think that's actually very appealing to a lot of customers.

Justin Davies: 1:02:54

Again, it's like the cloud journey, where some customers are like I'm terrified of the cloud. Then they get in there and they're like okay, this is actually really helpful. Same kind of thing here. The other part of putting it on the observability front is that another theme that we saw was that the developers had some sort of tool that they were using Prometheus, grafana, whatever it is right. The admins are like no way, man, I'm using like Nagios or Nagios, however you pronounce that and I'm using SolarWinds and Splunk and all these kind of things. Right, it's like very different platforms that they want to use.

Chris Miles: 1:03:21

On top of that, the admins like developer 2am.

Justin Davies: 1:03:24

Why didn't you turn on your logs and metrics Like?

Justin Davies: 1:03:25

we can't even figure this out right, and it was very, very hard. So what we wanted to build was a place that the admin and the developer had the same logs and metrics but could use it however they wanted to, and so, at the service level, you can enable logs and metrics and send it to wherever you want to send it to. You can send it to S3, cloudwatch we integrate with Kinsis Data Firehose. You can send it to whatever platform you like. The admin though this is the power at the service network level can turn it on for all services in the network, regardless of if the service owner turned it on or not, and they can send it to their platform. And so now you have this kind of very, very audible kind of situation that gives you those rich metrics and logs. Here's the big part. Again, we talked about like IP addresses not making sense in container world.

Tim McConnaughy: 1:04:02

I'm not dealing with IPs anymore.

Justin Davies: 1:04:03

Of course you'll have them in your logs and metrics. But you're going to see, service A was authenticated with an allowed access to talk to blah and they didn't get requests at blah, blah, blah time stamp, so on and so forth. You get those rich, rich, rich metrics and logs. What's going on?

Chris Miles: 1:04:21

That's interesting, that's cool.

Alexandra Huides: 1:04:22

And the added piece to that is that again, those access logs show the totality of information that's meaningful for the service owner and for the service network owner, for the admin, and you stop looking at two different things from two different perspectives. You stop looking at a curl that timed out versus at a ping that doesn't work. So that's kind of the again, a place where these two personas come together and look at the same thing at the end of the day and troubleshooting is much easier.

Justin Davies: 1:04:55

Bridge that gap. It needs to be one thing. Because it is one thing Right now, we're developing things on different players and we're saying no. The only reason why we're doing that is because we don't want to have to build and hire really good full stack engineers. They're hard to find, if they even exist, and we don't want the super Debbie bring it down, provide the right user experience to both and make it the same thing instead of having two different things.

Chris Miles: 1:05:17

I think you guys need to VPC lattice. You need to work your way down the stack to where I can do ICMP. So if I can't ping the service, it doesn't work.

Tim McConnaughy: 1:05:26

I don't know what it is, but I can't ping it.

Justin Davies: 1:05:28

Well, I just feel like there's a GitHub for ICMP wrapped in HTTP somewhere.

Alexandra Huides: 1:05:36

We should add that to the road map, just in case.

Chris Miles: 1:05:40

There it is, there it is.

Tim McConnaughy: 1:05:43

I need to send gets as ICMP.

Alex Perkins: 1:05:44

I got a super quick one and this might have been covered. And this is weird to even say because I'm going to call an overlay and underlay. But is there a way to have, like, do you have to have a network already established in AWS to have the overlay of VPC lattice service network running over it? Does that make sense? Just a VPC or yeah, like, does the VPCs already have to be peered? Is there any kind of requirement underneath or does lattice just come on?

Justin Davies: 1:06:13

This says all that for you. So most of the time customers think of lattice as, like the network and load balancer thing put together, they handle all the cross VPC stuff Behind the scenes. We're not actually doing VPC peering and all that kind of stuff. You don't need to do that. You can completely isolate your VPCs, not have a network at all. The major magic is that once these services are all registered, now VPC lattice has this thing. Oh cool, I know about all these services, so now all you need to do is just to share them like you would a private one, and that is that setup.

Justin Davies: 1:06:40

I do want to point out that, like it doesn't have to just be for network connectivity. Vpc lattice is a full blown proxy, instead of having to like, configure a subnet and put an application load balancer in there and one VPC lattice does that too. Right, it is a proxy, and so I don't care if you are in a different VPC or you're in the same VPC. None of that stuff matters to me. All I care about is that you registered your service and you're a part of that service network. If that's checkmark, checkmark, I can connect to you, as long as the off-policy is allowed, obviously.

Alex Perkins: 1:07:06

Okay, well then, so that's perfect. So this goes into the last question. The last question is what's the most interesting deployments that you guys have seen with this product?

Justin Davies: 1:07:15

Interesting. I mean I would recommend reading Alex's blog that covers probably my favorite of the architectures, but I'd say that we originally were focusing on the developer user experience.

Justin Davies: 1:07:27

We were really kind of focused on like how do we make this just super simple? So this idea that, like I didn't even need a network admin, my developer could have its own service network. I could be running in Kubernetes, configure all my services and then just have everything talk to each other that was kind of like the angle we were going Like how do we make it so simple? But when we started shopping this around and kind of talking to different customers, it was very evident that, like it made a full-on switch where the admins were like oh no, this is the way that I can still give the developer that experience. But now I've got that centralized place to control it.

Justin Davies: 1:07:56

And I think the most popular architecture pattern we've seen is really along this lines of an admin of some sort creating a couple of different service networks, one for, like, maybe, pci compliance, another one for shared services. Right, them being the gatekeeper of what goes into this Only PCI compliance I might do diligence and I'd verify that these are all compliant type workloads and then sharing that service network out. You can share service networks or services. I don't think we covered that. If you're able to do that own that network and share this thing around is the really really kind of powerful one that I think most of the bigger customers are interested in.

Alexandra Huides: 1:08:31

Justin mentioned the shared services access. But I think the access to that central artifact repository, central code repository everyone in Prada and Dev needs access to this service. How do I do it? Well, so far you either had to do like East West inspection on transit gateway, you had to do private link in every single VPC, you had to do something right. Well, when you see, lattice becomes much, much more simple and it also enables that zero downtime type of migration. So essentially, it's just the DNS change. It's not interrupting your production workloads or that flow. So yeah, I think that shared services pieces super important, especially when so many, so many large scale environments that come from acquisitions and all of that have overlapping IP space.

Justin Davies: 1:09:23

I want to say one more architecture is because you just maybe think of one the other one is really just this idea of isolation, Just the same way that we when we first launched VPC.

Chris Miles: 1:09:31

we never thought the customers would have more than one Most customers don't even have a data center.

Justin Davies: 1:09:34

They rent space in a data center that quickly changed. We've got customers with hundreds of thousands of VPCs, same with accounts and customers.

Justin Davies: 1:09:42

Really, like this idea because it's two boundaries that they can wrap their head around right, network boundary, vpc account permissions. Those are two boundaries but in this model it allows you to kind of really isolate and say, okay, I'm going to put an application in this VPC, all the major dependencies might live in it, it's got a database there and all that kind of stuff. But when I have like that front end that I share with everybody else, that all my dependencies need to call, today we open this VPC up, whether it's the internet gateway, vpc, peers, transit gateways we open it up.

Justin Davies: 1:10:07

And in all reality. Do I want to open it up at the network level or do I want to open?

Justin Davies: 1:10:10

it up at the service level, and that's what VPC lattice is really really kind of good at handling right Is allowing these customers to get that kind of really isolated reduction of last radius kind of situation where I cut off all connectivity from my VPCs, I give all my application owners their own VPC to do whatever the heck they want. They don't get internet gateways, they don't get transit gateways, they don't get anything. Pick and choose what they want to share and then that's it, and so now it's completely centralized control of all of that kind of stuff. So that is kind of the big, big magic bullet there.

Alexandra Huides: 1:10:38

What you just mentioned, justin, reminded me of a customer who not actually just one customer, multiple customers who've created VPCs purposefully with overlapping AP space so that they would never peer with each other and they would always have control over what connects to what. Is the thing that enables you to do that? Maintain that control, not care about the overlapping AP space?

Alex Perkins: 1:11:06

Okay, well, this was amazing. We got to cut it at some point. I was going to ask we'll have to get some links. We didn't talk about security, so maybe it'd be good to get some links that talk about some of that stuff. But I'm going to just go around the table real quick, chris or Tim, anything you want to chime in Any last words.

Chris Miles: 1:11:24

Yeah, I'll say this was super helpful. Thanks, alex and Justin for coming on. This was I actually did opposite Tim. I did quite a bit of reading before coming on this call and I will say I walked away with quite a bit, so this has been very well, thank you.

Tim McConnaughy: 1:11:42

Yeah, it's really good. I'm glad to hear about it Again. I did the opposite of Chris, which is what we normally do, but mostly because I wanted to have that perspective to ask those questions right and, having heard all of it, I'm really excited to actually go now and do the really deep end research and start playing with it. So thanks for making the time, it's been excellent.

Justin Davies: 1:12:06

Happy to do this. It's a new primitive for a lot of folks, I think. You know, even though we built the user experience for developers, people that built it were all admins. So you know, alex, myself, you've got that kind of same background. So there's a little bit of something for all of your audience there.

Alexandra Huides: 1:12:26

And I think, based on, based on everyone's reaction and I think we're going to get questions or feedback We'd love to come back, talk some more, go more in depth.

Alex Perkins: 1:12:38

So absolutely yeah, I'm sure there's definitely a lot, a lot of a lot of questions. Okay, anything you guys want to plug, when do we find you guys online?

Alexandra Huides: 1:12:47

Oh, for me it's LinkedIn. Just search Alexandra Huyvish, and you'll find me there.

Justin Davies: 1:12:52

I think LinkedIn is probably best for me. I think I'm Mr Justin D, I think. Every time I'm on Twitter I just paste my LinkedIn posts, so I haven't really figured out that platform yet, but yeah, it's probably the best place.

Alex Perkins: 1:13:08

All right, awesome, all right. Well, thank you all very much for tuning into the Cables to Clouds podcast. If you like this episode, please share it around to anyone you think might be interested. Give us a five star rating on your favorite podcatcher and hit those like and subscribe buttons on our YouTube channel Until next time. Hi everyone, it's Alex 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 of 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.