Transitioning to Cloud Networking

Dmitry Figol 0:00

Like I would drop a video like once per year and then I will go silent for three years and then in three years they're like oh, I'm back.

Chris Miles 0:08

Today is one of those days that you're a content creator because you're on the show.

Tim McConnaughy 0:11

That's right, we're filling the quota.

Alex Perkins 0:15

Yeah, Three years of silence now after this right.

Tim McConnaughy 0:18

Welcome to the Cables to Clouds podcast, your one-stop shop for all things hybrid and multi-cloud networking. Now here are your hosts Tim.

Chris Miles 0:27

Chris and Alex.

Tim McConnaughy 0:30

Hello and welcome back to another episode of the Cables to Clouds podcast. As always, my name is Tim McConaughey at JuanGolbez on Twitter. With me, as always, are my co-hosts Alex Perkins at Bumps in the Wire on Twitter and Chris Miles at BGP Main on Twitter. We have with us a special guest this week to kind of talk about some of the transitioning from network engineering on-prem to the cloud and some challenges and things that he does to help customers that are moving to the cloud today. So go ahead and introduce yourself, dimitri Fiegel. We've got him from AWS, hey everyone.

Dmitry Figol 1:11

I'm Dimitri, senior Cloud Infrastructure Architect at AWS Professional Services. I help customers design and implement scalable infrastructure on AWS. My main area of expertise is networking cloud networking. Specifically, I'm one of the authors of Cisco DevNet Expert Exam, occasional conference speaker and occasional content creator. Occasionally, once in a while, I would drop a video once per year, and then I would go silent for three years, and then in three years I'm like oh, I'm back.

Alex Perkins 1:47

We've all been there.

Chris Miles 1:48

Today is one of those days that you're a content creator because you're on the show.

Tim McConnaughy 1:51

That's right, we're filling the quota.

Alex Perkins 1:54

Yeah, three years of silence now after this right.

Tim McConnaughy 1:57

That's right. We'll open the cave three years from now and you can come back out. Open the cave three years from now and you can come back out. Thanks for joining us, dimitri. So tell us a little bit, if you would, about you know, because obviously a lot of people already you know, might know you, especially in the network engineering community, but maybe not the cloud community yet. So tell us a little bit about your background in network engineering and kind of what led you to end up where you are now with AWS doing cloud networking.

Dmitry Figol 2:27

Yeah, so I've been working at Cisco for around seven years where I was doing a lot of different things. I started in tech and then I was in sales for some time and then transitioned to network automation stuff and then eventually to some parts of software development as well, and probably during the last five years at Cisco I was focusing specifically on network automation. It was my thing, I really wanted to know everything there is to know about that and I was exploring a lot of different things. Yeah, and then I think what has happened is I realized that like I personally stopped believing in it. I guess that's my issue is that you know, like there have been talks about.

Dmitry Figol 3:18

So, first of all, like some people were doing parts of like CLI automation for years, like technically it was nothing new. There was stuff around things like Yank, some new tooling Even Yank 10 years later I don't think it really went to a level where everyone is familiar with it or the tooling around it that makes sense. So what I think has happened is there was some hype around it and some of it is useful, but it also requires a lot of investment into that. Like you're essentially asking a person to do two jobs at once, like network engineering and software development, and, frankly, not many companies are really willing to pay for that, for two skills at once. Right, it's like you know a network engineer who knows some I don't know YAML and a little bit of Python, but like I haven't really seen except of some cases, right, where proper software development life cycles and practices really came into network automation world.

Dmitry Figol 4:30

So at some point and like over the years, I didn't really see that being evolving. It was more of the same. It's like, okay, it will be nice that you folks not only do all this OSPF, bgp style but also write Python for it. Right, yeah, true, yeah. And at some point I realized it's just, you know, I want something different, I want to do something else. Like I stopped believing in it and that's where I made decision that I'm going to leave it and I'm going to leave it behind myself. Like I'm going to close this chapter of my life. I would stop going to Cisco lives, I would stop tweeting about how I dislike Ansible and things like this and that's it. And then I found another role at AWS, where it was something completely different and I never looked back. But then eventually networking came back for me and I was like okay, I know on-premises networking.

Dmitry Figol 5:31

So it was kind of easier for me to build some of this cloud networking knowledge on top of it and become really good at it. So I kind of used it to my advantage.

Alex Perkins 5:43

Yeah, I think it's like IPv6 adoption right, like everybody's been talking about it forever. It's like when is it actually going to get adopted? And I mean network automation has not been around as long as people have been saying IPv6 is going to take over, but it's still like a similar kind of trajectory, it feels like. So I agree with you there for sure.

Tim McConnaughy 6:03

Yeah, I mean I remember you used to do like, uh, twitch streams that were like ridiculous amount of time. It was like six hours long twitch streams that you would do and I was. I just remember being thinking like respect for being able to to focus on something for that period of time. I mean the stuff that you were doing was really awesome. But I totally get where you know. You were like kind of wanting to lead the way and advance the industry if you would, but it just wasn't ready to follow behind. I guess it just wasn't ready to come with you. So I can, I can understand that. So OK, so, so so can I. Just before we lead into it, then, what? What was it about, say, aws or cloud in general, that you were looking at Like, ok, this is where I should be instead?

Dmitry Figol 6:47

if you don't mind me asking, To be honest, I didn't know that that's what I'm going to do next. That wasn't necessarily my plan. I had an opportunity. My friend joined AWS just some time ago. I joined AWS just some time ago and so I'm based here in Poland and, as I'm starting, evolving and growing the center here in Poland specifically for AWS professional services, so and at some point he said, hey, like this is what we do, do you want to join? And I said, yeah, why not? Right? So then, like a little bit later, I realized that, well, probably even before beforehand, I knew that I wanted to be closer to business in terms of developing applications, um, and building applications, having, like, proper architectures in place. Um, that's something I liked. I liked drawing diagrams and understanding how different components of IT systems work and how to design them properly, and it seems like it was a good fit when they joined.

Tim McConnaughy 7:59

Isn't it so interesting? It's funny because, of course, when we were on-prem networking people, it's not like the applications were really that far away, but but organizationally it felt much further away. And I don't know if you guys agree, but like when I, when I was a network engineer, like the apps could have been on another planet, like I mean I knew they existed and I knew that they were important, that they had requirements and the network had to meet them. But like knew they existed and I knew that they were important, that they had requirements and the network had to meet them, but like I couldn't have told you what those were. That might be on right, but when you go to the cloud, the apps are like right there, like everything you build with the cloud from a networking perspective is in support of that. It just feels different.

Alex Perkins 8:36

I don't know what you guys think about that yeah, to me it's like there's two approaches that I think everybody has in this. It's when you first get networking, you're so far away from the apps, but it's like as you get more experienced, you kind of just grow closer to them. But then also, right on top of it, a cloud just really puts them front and center, and it's more so. It's like networking People seem to approach it from both angles at the same time.

Chris Miles 9:02

I think, yeah, I think it's partially due to that transition from the monolithic type of infrastructure. Even if you do a lift and shift, it's still true the app is immensely closer to you for some reason in the cloud, and I think it has to do with that modernization piece as well. Right, and the the, the fact that you know there's no, you're not, you're not focusing on the networking layer and then the virtualization layer. It's like all that is kind of I hate saying dumbed down, but it's kind of dumbed down in a lot of these situations. Right, there's not, there's not overly complex networking and virtualization options where you can really get yourself into trouble. Right, so they've oversimplified a lot of these things.

Navigating Networking Challenges in AWS

Tim McConnaughy 9:48

Okay, so actually that's a good segue. Dimitri, you mentioned as part of your job at AWS, you help customers with design and architecture. Are the kind of customers that you're working with? What kind of challenges from a networking perspective are you usually seeing and helping them solve? What do you see as the same place where people are stubbing their toes a lot of time, or what ends up being a lot of the problems to solve from a networking perspective?

Dmitry Figol 10:16

Well, first is the mindset and understanding that networking on AWS and networking on-prem are different things and the constructs that you are exposed to they might seem familiar, but they're also not exactly the same that you shouldn't really take what you know on-premise and apply that knowledge on AWS directly. You really need to understand some of these components in order to build good architectures. So, yeah, there are a couple of things that I see where I see there is a lot of confusion about, especially when some folks haven't had a lot of AWS experience before. So things like availability zones, for example, or security groups and some other areas, Do we want to deep dive into that moment?

Tim McConnaughy 11:16

I mean, yeah, some examples of what you're helping these people with, that'd be great. Yeah, absolutely.

Dmitry Figol 11:23

Yeah. So, for example, let's say you have a number of data centers on-premises and maybe they are in, maybe, let's say, one data center, or maybe two data centers in France, let's say, and a couple I know in Germany and et cetera. And then let's say you want to do lift and shift migration to AWS or, in general, you want to build something similar. And then you have to understand well what AWS region you're going to use, what availability zone you're going to use, or how many of those. And that's like one where, like this, one of the confusion is that availability zones are different data centers, right, that are not very far from each other but also not very close to each other, so they are not affected by, like, power outages and floods et cetera. And so let's say it's a distance up to 100 kilometers away from each other. It's they're designed in a way where you have redundancy, where you have resiliency, where you can actually do synchronous replication of your data, simply because the latency there is not that high. But then if let's say you were to take your on-premise data centers and then put them in another AWS regions maybe let's say, I don't know, frankfurt, and then something else, now you are in different AWS regions. Like some different rules are applied, like you cannot stretch some things across different regions. Like many AWS services are actually regional, so like your VPC and EC2 is regional constructs, so like you kind of just stretch it right.

Dmitry Figol 13:18

So, and one other thing is there are many ways to build highly resilient applications in single region that, customer, I would encourage to explore first, before even going multi-region Then, just because doing multi-region creates a lot of additional challenges, and not only in terms of like latency, which leads to potentially asynchronous replication of your data. But then you have to think about, well, how do you monitor it properly? Where are you going to put your monitoring? In what region? What happens if there is a problem with monitoring in that one region? Do you have another observability point? You probably will have some dependencies, things like this, that are not obvious. So, yeah, focusing on building your application resilient across different AZs within a single region is probably one of the things that I would suggest looking into more to make sure that you did everything you could Do.

Tim McConnaughy 14:31

You have a lot of customers that come to you and are like. The very first thing they say to you is Dimitri, we need multi-region, because multi-region means more resilient. Is that what you mean? Are people not aware of the different resiliency options that they could be leveraging in AWS?

Dmitry Figol 14:47

It's different for different customers. Very often, a lot of these decisions are made before I even join the call right, of course, and then it's really hard to have that kind of conversation much later, I guess.

Tim McConnaughy 15:02

Yeah, those of us who've worked in delivery understand that very well.

Chris Miles 15:08

Yes, for sure. I'm curious because I've worked in professional services as well, for for a lot of my career and I do understand. A lot of times you are handed something that isn't the most opportunistic or best designed, uh, in the forefront thing. Or do you find yourself having conversations like that, about things like uh, about latency, that, about things like about latency, about MTU, things like that that people were not considering with multi-region architectures, because I know it's crazy how complicated things get the second you want to do multi-region right.

Dmitry Figol 15:48

Yeah, so not really about MTUs, but latency does come into play and sometimes it comes into discussion so much, so late that, like you already built your physical direct connect circus to your on-premise architecture. Now we are discussing latency and they're like, okay, this is not the numbers that we expected. Well, you know, probably some tests should have been done much earlier. Yeah, so some anecdotes I remembered.

Dmitry Figol 16:22

It's interesting that when you have an application on-premises and you are on LAN where you have sub-millisecond latency, and then you move part of your components somewhere else, like AWS, right, and then maybe one part of application is in AWS and one part is on-premises and then suddenly between your components is not sub-millisecond latency, maybe it's 15 or 25, right. And then later it's like you know, someone complains that okay, my API request response take one and a half second. And then you start doing some investigation with like packet captains and stuff, and then you realize that there are like 15 or 30 round trips going on and then like, of course, like those, you have never seen that, because if it's sub-millisecond latencies you don't even notice that you did 15 times back and forth. But then if you move components apart, then it's like okay, now it's much more noticeable.

Tim McConnaughy 17:28

Poor application design has been covered by the network for so many years. You know what I mean, Like these database calls where every time you try to make a call to the database, you're you're, you're grabbing these giant tables or you're asking for 40, 400 different pieces of information with your database calls. Just really shitty. Application writing has been covered by overbuilding the network for so many years and unfortunately, like you said, if you go to the cloud and you start loose coupling this stuff and putting latency in between them, the cracks start showing pretty fast.

Chris Miles 18:03

Yeah, I think that's the thing is. Once it happens, that's when people really start thinking about it and looking at it right, because that brings something to mind. I was actually just talking with a customer not too long ago. The network team noticed that they set up these Direct Connects, they moved things into a VPC and there's one process on this application that they moved that runs very often, probably 10s and 20 times a day and it has over a million transactions for one single process. That and it's just like and they're hairpinning that up and down every transaction and it's just insane. Yeah, so that definitely does happen.

Alex Perkins 18:47

Yeah, just to back up just a sec. You know you mentioned, like knowing just the basics, like availability zones, just something I'm observing people that are traditional on-prem network engineers stuff like redundancy between data centers isn't a forefront thought, right, it's usually something that comes afterwards. I know I've been at plenty of places where you have two data centers but they're not actually redundant. One is just for separate applications and then there's giant exercises to make it so that you can have redundancy between them.

Tim McConnaughy 19:24

Yeah, whole projects to deploy the apps there and stuff.

Alex Perkins 19:27

Giant drills to be like. Can we even fail over here? Yeah, so I just thought that's a good example and I bet that's some of the things that you see customers having challenges with. Right Is just getting around that mentality in the first place.

Dmitry Figol 19:43

So maybe I could talk about another misconception or something that's maybe not misconception but not very familiar to folks. So I think security groups take people by surprise. So for those who don't know, security group would be a stateful firewall on pretty much almost every network interface on AWS. And then you have a rule inbound rule, for example. You open some port so you can accept an inbound connection, but then outbound connection will go through as well, since it's stateful firewall. And again, this comes up a lot in lift and shift migrations, where people are not really familiar with firewall rules on that level.

Dmitry Figol 20:34

Instance-level or VM-level firewalls are pretty rare, right, you would often have firewall rules somewhere at the boundary of your subnet or something like that. That often creates some challenges as well. So you don't have the same rule on premise. Like you suppose that everything on the same subnet can just communicate with each other on any port, right. But then you move to AWS and you are required to put those security groups and design them in the first place. So like there is some confusion there. So like this firewall is moved much more closer to your instance. So you have to take that into account when you are doing these kind of migrations.

Tim McConnaughy 21:25

Yeah, do you find that customers aren't aware that the SGs exist, or just that they assume they would be kind of open unless I explicitly deny stuff?

Dmitry Figol 21:38

See, it comes. Well, it again depends on who are you talking to in the organization, right, because there is, more often than not, there are some group of people who are championing being on the cloud and their level of familiarity with some of these concepts are much higher. But then there would be also potentially network folks or application folks for whom all of this is completely new. They have never done anything on AWS, right. So it depends, right. So with those folks, they could be surprised that, okay, my server has moved, but I didn't really specify in some kind of template that I needed this. My server is listening on that port and this no longer works. Why is that?

Tim McConnaughy 22:25

That was a huge problem on-prem too. A lot of times when you have the testing environment for the devs and this happened to me all the time when I was an enterprise engineer we'd have the testing environment for the devs, and this happened to me all the time when I was an enterprise engineer. We'd have the testing environment for the devs that was set up with the same VLANs and everything as the prod, but of course they didn't want to pay for the security infrastructure, so there weren't firewalls in the middle of it. So dev would run their stuff, they would change whatever they wanted to change in terms of source destination, programs talking to each other, they do it and it all work and they push to prod and of course it broke immediately because of all the firewall infrastructure that was part of the actual network. We hadn't gotten any firewall requests to update any of the stuff because the devs didn't know anything about that, right? So it sounds very similar.

Alex Perkins 23:09

This is my exact day-to-day like that. You just described exactly what I deal with all the time. So yes, thank you for that memory.

Dmitry Figol 23:20

Yeah, I mean, it's really important for application folks to understand how their components actually work right. Have diagrams in place? Have that documented right?

Tim McConnaughy 23:31

But when they lift and shift man so often, they have no idea right, when you're pulling it off of my data center, I don't even know where the stuff is in my data center. I just know I write this name and X talks to Y and there's thousands of lines of code with it and we're going to lift and shift that into the cloud. And they have no idea what's talking to what right? You just have to.

Chris Miles 23:50

Yeah, the. I mean oftentimes when things are reported like oh, we think there's a network problem with this and like okay, I mean, what TCP UDP ports are you using?

Alex Perkins 23:59

It's always like I don't know Like yeah, you tell us.

Chris Miles 24:03

Yeah, you tell us I'm like, but that, but that also kind of exponentially becomes a problem when you move things into the cloud, like you said, dimitri, where now there's pretty much a firewall on every single network interface card. That is out there.

Tim McConnaughy 24:17

It's micro-segmentation pretty much.

Chris Miles 24:19

Yeah, l4 micro-seg yeah.

Tim McConnaughy 24:21

L4.

Chris Miles 24:24

But I'm curious are you seeing issues with the customers that you talk to? Because now that becomes kind of part of what they need to make sure they're orchestrating when they're building in the cloud. Right, if you're building purpose-built security groups for for specific use cases or for applications, they need to know that and then they need to know how it gets applied, how it gets, you know, put on uh ec2 instances whenever they're spun up. Um, do you, do you see customers having issues with sprawl of that? That's like a net new element that they need to deal with now. Are they struggling with?

Dmitry Figol 24:59

that I would say it's mix. Again, that happens as well.

Alex Perkins 25:04

Sprawl, or do they just make a custom one and then apply it everywhere? That just allows traffic right? Same problems everywhere.

Dmitry Figol 25:14

Yeah. So I actually more often see that as like that's being fixed, unless some specific use cases like maybe still like if it's component of the same application, maybe if it will allow communication on like every port. But more often than not I actually see that's getting fixed, simply because, let's say, you migrated a server and then something doesn't work, and then there is some kind of troubleshooting process, right, and it's like, okay, you didn't inform us that there was this flow, so that flow gets added rather than just some blanket statements. So I see security is usually being taken quite seriously and also simply because it enforces you to interact with this kind of elements, you have to. It's much easier to do it right from the beginning in that case, rather than just allow and then you will never fix it.

Understanding Cloud Networking Concepts

Tim McConnaughy 26:18

Okay, yeah, I think we. Is there another anecdotal piece that you wanted to cover? Or we can move on to the next thing, if you want.

Dmitry Figol 26:29

I think we can move on to another thing, and that is load balancing, I think, is something that comes up. So this is more to networking folks. Um, I think there is um, um, something, uh, that very often networking folks are used to is some kind of, uh, vip concept on load balancers, right, and the way load balancers work on aws is that every load balancer node will get its own IP. There isn't really VIP concept there, right? And some of these changes in how you think about resiliency of that load balancer nodes come into play. You can't use one IP for everything, for every single AZ, etc. Etc.

Dmitry Figol 27:20

And that you have to rely on DNS, because there is an on AWS load balancing specifically, there is integration between Route 53 DNS and the load balancer, where it would help check the load balancer nodes, and if there is a problem besides the load balancer or targets behind load balancer, we would take out the DNS entry from the sorry IP address, from the DNS entry, right? So that's how you achieve that resiliency. And on-premises sometimes it's different, right? You would use some kind of VIP concept and you just have single static IP as an entry point for your application. So sometimes that comes as well of like okay, I want to have this single IP for my application, but that's not directly translatable and would not be a best practice to even do that on AWS. You would want to rely on DNS for that.

Chris Miles 28:22

Yeah, I think I'm just curious because, obviously, moving to the cloud, just as you've pointed out now, I feel like that it has caused people to have to kind of refactor their DNS implementations to be a little bit more robust and using, like you said, multiple IPs per entry as opposed to a virtual IP or something like that. But one thing is DNS. I feel like on on-prem, especially in some of these situations with mission-critical applications, we're used to building like, hey, this failover needs to be sub-second, things need to be very fast. However, dns typically time to live on a DNS record is relatively slow. I think default is typically what like 300 seconds or something. How do you talk about situations like this with failover and things like that? Are you seeing people need to adjust expectations or things like that?

Dmitry Figol 29:27

So it didn't come up in the conversation that I had that much. To be honest, though, there are some services that, if you are looking for non-DNS based failover, that can do that, like Global Accelerator, for example. So it's just like I didn't have those kind of conversations, probably yet.

Chris Miles 29:51

Yeah, I mean, that's kind of where I was leading, though it's like you need to pick the right tool for the job, right? So if that's something that you need, it's important to know what services are there.

Dmitry Figol 30:00

I think, in general, I would say I would want to add that it's important to know what services are there. I think, in general, I would say I would want to add that it's important to understand fundamentals of pretty much anything like when you can get to like a packet level exchange or maybe at least like an actual request response and understanding what's going on there, like what would be the header why you have you're doing so many round trips, or like why this source ip is being changed to something else then, like why it's being put in x for the, for the four, um, you know, like all all kind of these things. Like, if you start focusing on fundamentals, it really helps to operate, to design and troubleshoot, regardless if you are on cloud or on-premises.

Chris Miles 30:52

The packet walk is always king.

Tim McConnaughy 30:54

Yeah, especially at the network level, and it doesn't matter if you're on-premises or in the cloud. We were just talking about picking the right tool for the job. To pick the right tool for the job, to pick the right tool for the job, you have to understand what the application is doing, what the expectation is Like for the X forwarder. Do I need the X forwarder? Like, is that something? Like do I need information in the X forwarder to be persistent? Like that's an option? Right, I can pick yes or no. Like I need it to have it. Does the app expect it? That's the level of detail you've got to get to to be able to pick the right load balancer as an example.

Tim McConnaughy 31:26

Okay, yeah, I think that's a really good discussion on this and I think it leads us kind of into the last little thing we wanted to touch on before we wrap up, which is transitioning from on-prem to the cloud is obviously a huge undertaking and there's a lot of skill changes that carry over, and we've talked about this from the beginning, I think even from our first or second episode. There's also skills that you have to like. Just start from zero with like, which is understanding what options exist in the cloud. So you know, how do you think people should, just how do you think people should get started? I mean, obviously you had to do it, so what was your kind of way to pick up the cloud stuff?

Dmitry Figol 32:07

So I would say the way I would start today is trying to build some kind of application on cloud and use different compute and storage options. It can be very simple. You don't have to do something from scratch. You can even take some Docker images, container images someone else has built. You don't have to write code yourself.

Dmitry Figol 32:31

But I would take an application, I would understand its components and then I would build it in the cloud and then I would try to make it better, make it more resilient, to understand security groups, to understand availability zones, how load balancing would behave, and I would probably start with just EC2 instances and things like this.

Dmitry Figol 32:59

But then, once you become more familiar, you can transition to something else, like how do you deploy containers natively? Or maybe even you don't really want to think about all of these logical networks and APC stuff and you would just use serverless services like Lambda and things like this, so that you never have to define an IP address in the cloud. That would be probably the first area and then second area, as you go along, like once maybe you build it, I would automate what I've built in the console, just so I can replicate it at scale, because most likely that's the way you would want to build it in your company. It doesn't really make sense to do click-offs for everything, especially if you have tens or hundreds or thousands of your applications. It would be so much easier to just I don't know write some infrastructure as code and be done with it.

Tim McConnaughy 33:58

I feel like we have to ask, though, just given history what is your preferred method of automating in the cloud?

Dmitry Figol 34:08

That's a good question, and I think all of the tools have room for improvement. Let's put it this way it's the best answer.

Tim McConnaughy 34:17

All right, that's a fair point. I was just curious if you were like a AWS CLI guy or Terraform or CloudFormation or all of the above or whatever.

Dmitry Figol 34:29

Yeah, so as part of my role I use all of that. It really depends on what the customer wants. Gotcha, for one customer I could do one tool and then for another customer another tool. It doesn't really matter in the end.

Tim McConnaughy 34:46

Okay, yeah, that makes perfect sense. Okay, so I think we are just about ready to wrap up. Any final thoughts or something that you wanted to share, Dimitri, before we wrap up?

Dmitry Figol 34:58

Yeah. So I wanted to briefly share my favorite database networking service and I wanted to make sure that people go ahead and check it out if they haven't which is AWS PrivateLink. So, very briefly, it allows you to connect to another application, regardless in which VPC account it is Like. It doesn't require you to connect to networks to each other. So I think it's very impressive and it can solve a lot of interesting use cases. So that's kind of one thing, and second thing is I would encourage folks especially interested in high availability across AZs and load balancing to check out the reInvent talk from last year about zonal shift, arc zonal shift. That's something that again, like I went through it and like my mind was completely blown. I was like, okay, now I want to share this knowledge to anyone who is willing to listen, and even if they don't, I will talk to them anyway until they don't want to talk to me?

Tim McConnaughy 36:12

Nice, okay, we'll make sure we get the link and get that in the show notes for that talk.

Chris Miles 36:18

Yeah, we will. I'll say we didn't discuss this before hitting record and as soon as you said I wanted to discuss my favorite AWS service. I'll be honest, privatelink was not at the top of my list.

Tim McConnaughy 36:28

I'm surprised.

Chris Miles 36:29

that's where you went. But at the same time, PrivateLink's really powerful People have built entire businesses.

Tim McConnaughy 36:37

Businesses out of it. Yeah, like SaaS business basically out of it. Yeah, absolutely Honestly. Basically out of it. Yeah, absolutely Honestly. I was waiting for you to say Lattice, but I wasn't sure.

Alex Perkins 36:46

No, I was just going to ask one last question real quick, and it was going to be what do you think of things like VPC Lattice, and do you see those as more tools for the application team or networking team?

Dmitry Figol 36:57

So I think it's a very interesting service. It's a relatively recent addition to networking services on AWS and it does have a lot of cool use cases there, and I think it appeals a lot to application folks who don't want to. Maybe, for whatever reasons, you already have your VPCs using the same IP addresses everywhere and you just want to focus on connecting your microservices together. So I think it's worth exploring and it has its uses. One thing I will add, since you asked so it can actually do like on one site, one application, one service uses IPv4, and then another site uses IPv6. So that part is also really, really cool. So, like you can bridge gap between like v4, v6, regardless.

Dmitry Figol 38:04

So that speaks to me as a networking guy.

Alex Perkins 38:07

Yeah, we had Alexandra Wiedisch come on and I think that was one of her main use cases, for it was migrating from V4 to V6.

Tim McConnaughy 38:17

Yeah, we got a really cool demo from them, showing that migration Not migration, but interoperability rather as well. It's a really cool use case, especially as a network guy. I totally agree. That's just a nerd knob that's fun to turn, I think. Okay, All right guys. Well, any final thoughts from you guys, Chris Alex.

Alex Perkins 38:36

No, I'm good. Thanks for coming on, dimitri, definitely appreciate it.

Dmitry Figol 38:40

Thank you so much for having me folks, no worries.

Tim McConnaughy 38:44

Okay, so this has been the Cables to Clouds podcast. If you like what you heard and or saw, please subscribe to us on social media. Buy our breakfast cereal, order our stuff from Ebbetsy Book some time with Alex on your dating app of choice, and we'll see you all next time. Hi everyone, it's Tim 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 podcast catcher, 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 Cables2Clouds. You can also visit our website for all the show notes at Cables2Cloudscom. Thanks again for listening and see you next time.