1 00:00:07,822 --> 00:00:09,522 Welcome back to Adventures in DevOps. 2 00:00:09,522 --> 00:00:12,722 Every episode is a deep dive into a specific topic with an expert guest. 3 00:00:12,722 --> 00:00:16,922 And I'm hoping that this is finally the year of IPv6 for the desktop. 4 00:00:16,922 --> 00:00:18,762 I mean, for our cloud providers. 5 00:00:18,762 --> 00:00:27,762 The expert we brought in a veteran in the cloud infrastructure space, previous senior staff engineer at EF and now CTO at MoVEXA, Don Bolaghe. 6 00:00:27,762 --> 00:00:28,966 Welcome to the show. 7 00:00:29,112 --> 00:00:29,626 Thank you. 8 00:00:29,626 --> 00:00:30,988 Thank you for having me on. 9 00:00:30,988 --> 00:00:35,622 You know, I think it's been almost two years that I've been trying to convince you to finally show up now. 10 00:00:35,622 --> 00:00:45,610 And I think maybe that it's uh a little bit of a serendipitous that at this moment, the cloud providers have chosen that IPv6 may finally be a thing that we can start using. 11 00:00:46,178 --> 00:00:51,081 don't know about Google Cloud and Azure, but definitely on AWS. 12 00:00:51,081 --> 00:00:58,226 It's finally happening after I made the life of our account manager slightly more difficult than it should have been. 13 00:00:58,348 --> 00:01:06,586 I feel like if you're signing up as the account manager uh coming on board for a cloud provider, you've got to be open to the possibility that your customers are going to ask 14 00:01:06,586 --> 00:01:10,220 for things that you're just not prepared to have available. 15 00:01:10,220 --> 00:01:20,056 Yeah, the answer on AWS that I've always gotten was, well, if you want to have better routing and a less complex network, just take VPC lattice. 16 00:01:20,056 --> 00:01:23,389 So why is IPv6 even important in the cloud? 17 00:01:23,389 --> 00:01:29,235 Isn't everything abstracted away in such a fashion that it doesn't really matter what the underlying infrastructure is? 18 00:01:29,235 --> 00:01:36,972 Why go through so much pain and suffering trying to convince technical account managers, the cloud providers to really start offering support for it? 19 00:01:36,972 --> 00:01:51,244 Well, if you've ever seen the traditional diagram that AWS recommends and everybody also uses for their networking setup with public private subnets, taking on IP spaces, pairing 20 00:01:51,244 --> 00:02:00,801 them sometimes with on-prem and having to deal with IP collisions, you just don't have any of that with IPv6. 21 00:02:00,801 --> 00:02:03,023 You get a clean network. 22 00:02:03,023 --> 00:02:05,405 You don't need to do public private subnets. 23 00:02:05,405 --> 00:02:07,010 You can, but... 24 00:02:07,010 --> 00:02:07,860 You don't really need to. 25 00:02:07,860 --> 00:02:14,392 You don't need to pay for the biggest scam on AWS, which is NAT gateways, because there's no NAT. 26 00:02:14,392 --> 00:02:17,133 And you want to peer different accounts, sure. 27 00:02:17,133 --> 00:02:23,975 You just share the IPv6, SIDR, prefix, put it in your VPC group and congratulations, you are peered. 28 00:02:23,975 --> 00:02:28,107 No need to care about collisions of IPs or anything. 29 00:02:28,107 --> 00:02:32,078 And it's just the amount of... 30 00:02:32,078 --> 00:02:35,478 difficulty that IPv4 brings along with it. 31 00:02:35,478 --> 00:02:37,018 It's just ridiculous. 32 00:02:37,098 --> 00:02:45,118 At AWS re.invent 2023, I went to this talk and quick side note, this was a level 500 talk. 33 00:02:45,118 --> 00:02:54,358 These are the best talks at re.invent and they're typically empty for whatever reason, because this is the ones where you are not gonna sit into a marketing presentation for an 34 00:02:54,358 --> 00:02:55,118 hour. 35 00:02:55,458 --> 00:02:57,298 This is where the actual technical bits are. 36 00:02:57,298 --> 00:03:00,086 Anyways, this talk was from Netflix. 37 00:03:00,086 --> 00:03:04,029 who internally has gotten fully IPv6 on their Kubernetes cluster. 38 00:03:04,029 --> 00:03:12,899 And it took them a couple of years, but they showed the diagram of their networking setup before and after. 39 00:03:12,899 --> 00:03:19,840 And it looks like some piece of satire of how much simpler it was. 40 00:03:19,840 --> 00:03:25,012 So in the current world, ah it sounds like just move to it, but I feel like... 41 00:03:25,012 --> 00:03:30,205 even all of the services in AWS didn't support IPv6 for such a long time. 42 00:03:30,205 --> 00:03:33,496 And I don't know what the current status is of the service. 43 00:03:33,496 --> 00:03:37,948 feel like there are some limitations that just were always getting in the way of actually migrating. 44 00:03:37,948 --> 00:03:47,172 If you have all of your stuff running purely on say virtual machines, you may be afforded some additional flexibility in choosing your network topology. 45 00:03:47,172 --> 00:03:54,906 But if you're using some of the more complex or first-class services that support serverless or Fargate, et cetera, I feel like there was always some particular issue 46 00:03:54,906 --> 00:04:05,839 you'd run into where it, should just tell you that it's not supported to utilize those services with IPv6, even though there are some fundamental limitations with the IPv4 47 00:04:05,839 --> 00:04:06,594 infrastructure. 48 00:04:06,594 --> 00:04:13,621 Well, it took them long enough to support single stack IPv6 on just VPC and EC2 to begin with. 49 00:04:13,621 --> 00:04:18,385 If I remember correctly, this is a thing from the last two years where they made this happen. 50 00:04:18,386 --> 00:04:24,852 Before that, it was dual stack and you could attach IPv6 to it and you could do that for... 51 00:04:24,852 --> 00:04:30,636 And every year, I used to run a platform team and every year I would go out and just... 52 00:04:30,636 --> 00:04:37,269 try to set up a core piece of our infrastructure with an IPv6 native infrastructure. 53 00:04:37,269 --> 00:04:46,314 And every time we would run into like these fun quirks where like, yes, this should work, but only once in a blue moon. 54 00:04:46,314 --> 00:04:54,918 And if you sacrifice your firstborn and then you go complain to AWS support and 55 00:04:55,170 --> 00:04:57,141 They say, we don't know what's going on. 56 00:04:57,141 --> 00:05:04,696 And then you end up talking to a PO and the PO is also like, yeah, let me, let's get back to you and see what's going on there. 57 00:05:04,696 --> 00:05:11,019 Because they are also all puzzled and all I'm doing is trying to follow the guide I was given. 58 00:05:11,219 --> 00:05:15,082 Now this has become significantly better over the past few years. 59 00:05:15,082 --> 00:05:22,530 For example, my company, Mevexa, we are running fully IPv6 native everything on Fargate, on ECS. 60 00:05:22,530 --> 00:05:24,251 with RDS. 61 00:05:24,251 --> 00:05:28,214 However, RDS specifically requires a dual stack setup. 62 00:05:28,214 --> 00:05:34,639 So I've got one VLAN specifically for the database, but everything else is running in a VLAN. 63 00:05:34,639 --> 00:05:35,940 Sorry, subnet. 64 00:05:37,261 --> 00:05:38,298 For what specifically? 65 00:05:38,298 --> 00:05:44,858 For RDS needing dual stack setup and not just being able to rely on pure IPv6 as the network configuration. 66 00:05:46,298 --> 00:05:55,118 And this is the thing is that AWS had a release, I think it was in the last year, saying that RDS fully supports IPv6 only as an option, but then you go and you look at the 67 00:05:55,118 --> 00:06:00,724 configuration that can be there and when you actually try to select a single stack mode, it... 68 00:06:00,724 --> 00:06:08,258 If it works, end up with an issue either pulling images or whatnot, or more likely is it just doesn't even work out of the box. 69 00:06:08,258 --> 00:06:11,045 Well, last I checked that option didn't even exist. 70 00:06:12,592 --> 00:06:14,914 IPv4 single stack or dual stack? 71 00:06:14,914 --> 00:06:25,198 And that's something I sort of want to get back to on IPv6, is it seems like it helps from a technical standpoint, but I'm curious if you have any opinions on how or if there's a 72 00:06:25,198 --> 00:06:26,518 customer perspective. 73 00:06:26,518 --> 00:06:32,961 Like, didn't Mavexa go with the direction of having IPv6-only infrastructure? 74 00:06:32,961 --> 00:06:35,838 Was it purely technical or are there other considerations? 75 00:06:35,838 --> 00:06:41,053 Well, there are several technical considerations. 76 00:06:41,053 --> 00:06:51,473 One of them is, of course, being much easier to set up and also much cheaper because I don't have to pay for an app gateways and IPv4 addresses, which, by the way, I want to 77 00:06:51,473 --> 00:06:52,464 thank AWS for. 78 00:06:52,464 --> 00:07:00,060 This is like the best charge they ever introduced because now people are are starting to care um because they have to pay for it. 79 00:07:00,064 --> 00:07:01,034 I see. 80 00:07:01,775 --> 00:07:13,130 Maybe that gateway has been like a very long play, right, from decades ago to convince the world to move to IBV6 because without that, maybe the NAT gateway charge, you know, if it 81 00:07:13,130 --> 00:07:19,082 didn't exist, they would be, they would have lost a critical tool in actually convincing people. 82 00:07:19,470 --> 00:07:26,430 Well, I've spoken to many people on this subject and the feeling I get is that no one really cares. 83 00:07:26,550 --> 00:07:30,970 They are just paying this because, that's what it costs, right? 84 00:07:31,570 --> 00:07:44,010 But then people suddenly did start caring when in 2024, AWS started charging for IPv4 addresses, even if they were in use, because previously it didn't matter. 85 00:07:44,430 --> 00:07:47,398 You would only be paying for the ones that were sitting around. 86 00:07:47,398 --> 00:07:59,473 And at the time at the company I was working for, um I did see a jump in our bill the moment they started charging and that was quite noticeable despite our spending, which was 87 00:07:59,494 --> 00:08:00,875 quite significant. 88 00:08:02,392 --> 00:08:08,418 So the IPv4 switch to charged IP addresses, like that was actually a motivating factor. 89 00:08:08,418 --> 00:08:14,483 Well, my previous company, wasn't because there were more important things to do and we're just going to absorb the pain. 90 00:08:14,904 --> 00:08:27,896 But if you're starting green, just fresh, I would totally see this as a motivating factor to at least explore IPv6 and finally adopt the technology from 9095. 91 00:08:28,312 --> 00:08:29,202 I see. 92 00:08:29,764 --> 00:08:40,995 I noticed that one of the concerns that we had initially with uh especially VPC architecture with IPv4 was uh being able to spin up quickly ENIs, which used to be a huge 93 00:08:40,995 --> 00:08:43,117 pain for serverless architecture. 94 00:08:43,177 --> 00:08:50,424 I don't know enough about the network to stack here, but I have to imagine that AWS must have made some improvements over... 95 00:08:50,424 --> 00:08:52,172 uh 96 00:08:52,172 --> 00:09:01,526 what was in place historically for the network architecture for IPv4 only to circumvent the limitations that were in place. 97 00:09:01,582 --> 00:09:02,083 Probably. 98 00:09:02,083 --> 00:09:12,036 um I did have to deal once with uh our VPC being exhausted with IPs because we were spending up too many serverless functions in one go. 99 00:09:13,159 --> 00:09:18,766 You get traffic and you can only assign 200 IPs in your subnet. 100 00:09:18,766 --> 00:09:22,746 There must wait, is some not really limited to only 200 IP addresses? 101 00:09:22,860 --> 00:09:28,782 Well, it's 255, uh 253 really, cost of your gateway and your net mask. 102 00:09:28,782 --> 00:09:36,222 Okay, so if you're running a serverless function inside the VPC, of course it's going to be in one or two subnets. 103 00:09:36,222 --> 00:09:42,540 You're going to be limited by 250, less than a thousand concurrent invocations. 104 00:09:42,540 --> 00:09:44,374 Well, of course, it depends on how you set up your network. 105 00:09:44,374 --> 00:09:48,162 In our particular case, we had a slash 24 block for this specific network. 106 00:09:48,162 --> 00:09:54,350 Of course, you should probably be taking something like a slash 22 block, which gives you quite a few more IP addresses. 107 00:09:54,350 --> 00:10:03,490 I can imagine with an architecture that's not serverless, if you're using Kubernetes or even some sort of swarm setup, poorly defining, like not per, I would say not even poorly, 108 00:10:03,490 --> 00:10:10,050 not perfectly defining your usage of the IP address space would lead to exhaustion. 109 00:10:11,090 --> 00:10:14,284 Like that problem just completely goes away by switching to IPv6. 110 00:10:14,284 --> 00:10:25,048 Yes, because you get more IP address than we have known stars in the universe or sent sent corns on this planet multiple times. 111 00:10:25,048 --> 00:10:28,159 How does this work realistically in practice? 112 00:10:28,159 --> 00:10:40,772 Are individual nodes each getting assigned an IPv6 network address from AWS like global proper, is there some sort of, I don't know, magical network appliance that's, I mean, 113 00:10:40,772 --> 00:10:42,813 there's no network address translation that's happening. 114 00:10:42,813 --> 00:10:48,004 Like there is no like LAN that's in existence for the IPv6 infrastructure. 115 00:10:48,004 --> 00:10:54,424 So I'm not actually familiar with what must be happening here in order to provide the level of sort of 116 00:10:54,424 --> 00:10:57,619 performance or growth from getting requests in. 117 00:10:57,710 --> 00:11:00,950 So let me quickly break down IPv6. 118 00:11:00,950 --> 00:11:04,290 A IPv6 address is 128 bits. 119 00:11:04,410 --> 00:11:09,850 The first 46 bits of that is a writable address, also known as the prefix. 120 00:11:09,850 --> 00:11:14,050 And the last bit is the identifier, the last 46 bits. 121 00:11:14,050 --> 00:11:23,390 In the original RFC, which was RFC 1886, I believe, 1883, it was quite simple. 122 00:11:23,390 --> 00:11:27,340 You had your first 46 bits as your 123 00:11:27,340 --> 00:11:35,556 gateway address and all the devices below that would use the order 64 bits to basically translate their MAC address. 124 00:11:35,556 --> 00:11:47,064 So the first 64 bits would be what in IPv4 we would refer to as your external WAN address and the last 64 bits would be known as the internal IP. 125 00:11:47,364 --> 00:11:48,845 Of course, this is IPv6. 126 00:11:48,845 --> 00:11:50,747 Everything is globally routable. 127 00:11:50,747 --> 00:11:54,469 And there were some nightmares about privacy there. 128 00:11:54,810 --> 00:11:55,794 So... 129 00:11:55,794 --> 00:11:59,675 in 2017 if I'm not mistaken. 130 00:11:59,876 --> 00:12:06,819 They introduced the privacy extension where the last 64 bits are no longer based on your MAC address. 131 00:12:06,819 --> 00:12:14,542 Before you could already do that uh using static routing or DHCPv6 which is also not needed. 132 00:12:14,542 --> 00:12:16,991 Couldn't you spoof your MAC address too? 133 00:12:17,438 --> 00:12:18,719 You can, of course. 134 00:12:18,719 --> 00:12:21,200 Most mobile phones already do that out of the box. 135 00:12:21,200 --> 00:12:26,142 And Mac OS as well, I don't know about Windows or Linux out of the box. 136 00:12:26,142 --> 00:12:29,143 Doesn't if you use networking manager. 137 00:12:29,143 --> 00:12:36,086 But that wouldn't necessarily uh relieve your problem because you'd still have a static address effectively. 138 00:12:36,086 --> 00:12:44,810 How it works nowadays is you just get a random identifier when you request an IP and... 139 00:12:44,966 --> 00:12:55,680 your gateway will know how to write this and at any given time depending on your hardware for example this computer i'm recording this on currently has about 12 ipv6 addresses 140 00:12:55,680 --> 00:12:57,462 assigned to it is that a lot? 141 00:12:57,462 --> 00:13:04,142 that's quite a lot but also i didn't do anything to change this this is out of the box configuration 142 00:13:04,142 --> 00:13:05,396 How is the assignment happening? 143 00:13:05,396 --> 00:13:10,901 is it per, I don't know, network process or by process that's actually requesting these? 144 00:13:10,904 --> 00:13:11,955 Per process? 145 00:13:11,955 --> 00:13:17,498 Well, I've got a little order bit to go into after this, but no, it's your networking interface. 146 00:13:17,498 --> 00:13:19,198 Funny that you should say per process. 147 00:13:19,198 --> 00:13:31,955 um I was at uh FOSDEM and there was this interesting talk from this older gentleman who had the idea of the internet of threats, where you would assign each threat on your 148 00:13:31,955 --> 00:13:34,387 operating system an IPv6 address. 149 00:13:34,387 --> 00:13:40,598 And because of how mind-bogglingly large the IPv6 space is, you can... 150 00:13:40,598 --> 00:13:42,740 totally do this without any concerns. 151 00:13:42,740 --> 00:13:55,190 It did raise a couple of questions because what I hear from people that don't know about IPv6 or typically have excuses to not look into it and these misconceptions is that, no, 152 00:13:55,350 --> 00:13:58,012 IPv6 is a privacy nightmare. 153 00:13:58,012 --> 00:14:07,920 But realistically, the only, these first 64 bits are the important bit, uh which is the same as your IPv4 public LAN address essentially. 154 00:14:08,261 --> 00:14:09,806 And if everything 155 00:14:09,806 --> 00:14:12,546 Every thread gets its own IP address. 156 00:14:12,926 --> 00:14:15,286 That problem is just completely gone. 157 00:14:15,566 --> 00:14:19,766 Also, generally, the problem is completely gone with the privacy extension. 158 00:14:19,766 --> 00:14:27,986 But with the Internet of Threads, every single browser tab could have its own IP address, which is quite exciting to think about. 159 00:14:28,246 --> 00:14:30,126 I don't think this is going to happen. 160 00:14:30,754 --> 00:14:33,877 I was going say, I think you and I have different definitions of exciting. 161 00:14:33,877 --> 00:14:40,292 But I get the benefit of not having to reuse connection pool in some way or uniquely identify. 162 00:14:40,292 --> 00:14:50,210 I mean, I can also imagine some of the challenges that come along with providing that, from a, I'll say, if you are trying to monitor or validate traffic that's coming, the fact 163 00:14:50,210 --> 00:14:54,054 that each one of these things has its own unique IP address could potentially be problematic. 164 00:14:54,054 --> 00:14:55,055 It could be. 165 00:14:55,055 --> 00:14:57,896 I spoke to somebody from Fastmail. 166 00:14:57,896 --> 00:15:02,526 They launched um this back in the day, in 2012. 167 00:15:02,526 --> 00:15:05,820 And there's an article from their CEO on their blog. 168 00:15:05,941 --> 00:15:10,623 And he talks about how they had enabled it and everything was amazing. 169 00:15:10,623 --> 00:15:17,627 And then there is a blog post slightly later, like, disabled it again, with no specific reasoning behind that. 170 00:15:17,687 --> 00:15:23,122 But after talking to a bunch of email people at Fostem, it really seems like 171 00:15:23,122 --> 00:15:30,866 One of the big problems here is spam filtering because most companies still rely on IP reputation lists. 172 00:15:31,147 --> 00:15:43,693 And because IPv6 is such a mind-bogglingly large address space, these lists are easy to circumvent because I can just change the last bits of my prefix, sorry, the last bits of 173 00:15:43,693 --> 00:15:46,315 my writable address and keep the prefix the same. 174 00:15:46,695 --> 00:15:52,438 So I essentially have a 64-bit number space to play around with. 175 00:15:52,716 --> 00:16:01,489 Realistically, you should just be set those prefixes on to, sorry, the IP reputation lists on the prefix, really. 176 00:16:01,770 --> 00:16:13,314 But anyway, those lists don't really exist and email providers, unfortunately, rely on this, which is why hosting your own email server is quite the challenge. 177 00:16:14,004 --> 00:16:21,839 Email providers are behind on technology that doesn't surprise me in one bit. 178 00:16:21,839 --> 00:16:32,205 do like that ingress and egress blocking, has historically been based at the IP address level, uh basically feels dead with the migration to IPv6. 179 00:16:32,265 --> 00:16:40,340 The wonder why I like that is because all of these companies with security parameters claiming to do security and I have that in quotes. 180 00:16:40,340 --> 00:16:46,688 like actually now have to join us in the 21st century and shift to what everyone else has been doing, which is some form of zero trust. 181 00:16:46,774 --> 00:16:51,918 Yes, and actually do some security rather than security to obscurity. 182 00:16:51,918 --> 00:17:02,905 So one of the common myths about IPv6 is that it doesn't use NAT and NAT is a security feature. 183 00:17:04,166 --> 00:17:04,887 yes. 184 00:17:04,887 --> 00:17:16,172 And this is very easy to break down quite quickly because NAT itself, yes, it translates your IP address and you can't go to uh a computer directly. 185 00:17:16,172 --> 00:17:17,602 behind the NAT. 186 00:17:17,842 --> 00:17:19,203 And this is true. 187 00:17:19,243 --> 00:17:24,803 But most NATs come with a built-in stateful firewall. 188 00:17:24,844 --> 00:17:26,635 And that's the magic bit. 189 00:17:26,635 --> 00:17:31,706 They're stateful firewalls, the same stateful firewall that you should be using with IPv6. 190 00:17:31,706 --> 00:17:36,818 If you go disable the stateful firewall in your NAT, your NAT is not going to be as secure anymore. 191 00:17:36,818 --> 00:17:43,169 Because the moment you go visit a host or run any program, they essentially can just directly talk to the end machine. 192 00:17:43,169 --> 00:17:45,422 And you want that firewall to be there. 193 00:17:45,422 --> 00:17:50,882 Now, and this gets even worse because IPv4 is such a limited address space. 194 00:17:50,882 --> 00:18:03,002 You can, and there's plenty of people who do and plenty of companies who do, scan the entire range and port scan everything and just do like knocking on the doors of NAT and do 195 00:18:03,002 --> 00:18:04,362 some NAT hole punching. 196 00:18:04,462 --> 00:18:09,362 Now with IPv6, it's actually more secure because you can't feasibly do that. 197 00:18:09,362 --> 00:18:13,336 It's just not realistic to scan a 128 bit number. 198 00:18:13,336 --> 00:18:14,562 today, right? 199 00:18:14,562 --> 00:18:16,735 Well, I don't think ever. 200 00:18:17,366 --> 00:18:25,419 This is a question of whether there's some sort of quantum computing process which would help in this way, but I think given that you have to explicitly enumerate them, I don't 201 00:18:25,419 --> 00:18:29,892 think any sort of quantum annealing would even help expose relevant information. 202 00:18:29,892 --> 00:18:43,818 I think I won't spoil my pick here, but part of it I think was the ability to potentially use the IP address space and the ICMP packet to make a hard drive. 203 00:18:44,629 --> 00:18:46,504 I want to know more about that one 204 00:18:46,906 --> 00:18:50,229 So I'll say more about that at the end of the episode. 205 00:18:50,229 --> 00:18:54,793 ah so the thing here is, and maybe it's worth spelling out exactly what Nat is doing. 206 00:18:54,793 --> 00:19:00,538 So in a home consumer network, like I have a router that's attached to the ISP where it gets an IP address. 207 00:19:00,538 --> 00:19:10,607 And then I have all my devices connected to the network, which can see out through the internet, but requests that come back from the internet don't understand about my specific 208 00:19:10,607 --> 00:19:10,988 machine. 209 00:19:10,988 --> 00:19:13,772 And the router is routing those packets. 210 00:19:13,772 --> 00:19:15,043 to the individual machine. 211 00:19:15,043 --> 00:19:16,354 is a little bit different, right? 212 00:19:16,354 --> 00:19:19,877 Where it's sort of rewriting the packet and faking what's in the network. 213 00:19:19,877 --> 00:19:30,977 And I think it is a security feature where if everyone was using a cloud provider, cloud providers prevent sort of hijacking and making fake NATs and lying about the IP address. 214 00:19:30,977 --> 00:19:37,923 But you can attach any, your own version of a NAT to the internet and lie about your IP address all day long. 215 00:19:37,923 --> 00:19:41,346 And it will just go, now ISPs are supposed to be blocking that. 216 00:19:41,346 --> 00:19:48,809 But there's no guarantee that they're doing it, especially if those packets are coming from some uh renegade Wild West place uh in the world. 217 00:19:48,809 --> 00:19:58,572 And so I think it's always been a lie that IP addresses uh provide any sort of security, that Mac tracking provides any sort of security feature, and that, as you pointed out, 218 00:19:58,572 --> 00:20:03,734 that NAT is using NAT as a replacement for security with the built-in firewall. 219 00:20:03,734 --> 00:20:06,075 Yes, notably that built-in firewall. 220 00:20:06,075 --> 00:20:12,958 um All NAT really is doing, as you said, is rewriting packets, and that's it. 221 00:20:12,958 --> 00:20:19,481 And em I would like to mention mostly TCP packets, because a UDP cannot do NAT. 222 00:20:19,481 --> 00:20:24,883 If you want to do UDP, you need to do NAT hole punching and just establish an end-to-end connection. 223 00:20:25,683 --> 00:20:29,295 This brings me to another fun feature of IPv6. 224 00:20:29,295 --> 00:20:32,096 Well, not necessarily a feature, but a big benefit. 225 00:20:32,322 --> 00:20:35,663 Because UDP was designed with an end-to-end connection in mind. 226 00:20:35,663 --> 00:20:41,316 If you want to have a UDP connection be reliable, you're gonna need to do NAT hole punching. 227 00:20:41,316 --> 00:20:45,427 And for NAT hole punching, you're gonna have to run a state machine. 228 00:20:45,427 --> 00:20:58,413 And these state machines can get quite complex, especially if there is this other thing, terrible hack that is known as a carrier-grade NAT, where you have your own NAT at home, 229 00:20:58,413 --> 00:21:01,870 but then your ISP has its own NAT as well. 230 00:21:01,870 --> 00:21:07,350 So you're sharing the same external IP address with 500 order customers of your ISP. 231 00:21:07,550 --> 00:21:17,350 This is quite commonly seen in mobile networks, but also thanks to the exhaustion of IPv4, a lot more in residential connections these days. 232 00:21:17,358 --> 00:21:23,501 There's a common aspect called multiplexing when you have to send data along an internet pipe. 233 00:21:23,501 --> 00:21:27,783 There's different ways of breaking up giving the bandwidth to individual subscribers. 234 00:21:27,783 --> 00:21:37,167 You can break it up by time delays where the first millisecond of the bandwidth is for the first customer and the second millisecond of the bandwidth is for the second customer. 235 00:21:37,167 --> 00:21:46,282 Then there's frequency multiplexing where you send multiple different digital packets along, they're analog, along the network cable at different frequencies and different 236 00:21:46,282 --> 00:21:47,612 customers are different frequency. 237 00:21:47,612 --> 00:21:52,807 You know, this is an interesting standpoint of like how do you expose this data to the outside world when it's analog? 238 00:21:52,807 --> 00:22:02,107 You sort of have to make these determinations yourself It sounds like what you're saying actually is we've been trusting ISPs to provide us a level of security with IPv4s And I 239 00:22:02,107 --> 00:22:04,209 don't remember the last time I'm like, you know my ISP. 240 00:22:04,209 --> 00:22:05,678 I absolutely love it 241 00:22:05,678 --> 00:22:13,658 Well, I'm fortunate enough that I can say that my ISP in it 7 here in Switzerland is probably the best ISP in the world. 242 00:22:13,658 --> 00:22:15,038 I love you guys. 243 00:22:16,958 --> 00:22:20,518 But yeah, on the average ISP, I definitely wouldn't. 244 00:22:20,518 --> 00:22:23,058 I want to quickly go back to UDP. 245 00:22:23,058 --> 00:22:27,258 For UDP to work again and to add connection and IPv4 does not provide that. 246 00:22:27,258 --> 00:22:28,418 You need to have this. 247 00:22:28,418 --> 00:22:34,798 You need to have something in between like NAT and NAT rewrite your packages, but UDP packages can't really be rewritten. 248 00:22:34,798 --> 00:22:35,470 So. 249 00:22:35,470 --> 00:22:39,630 At the end, you need to have the state machine ready. 250 00:22:40,030 --> 00:22:42,590 this is problematic because this is all complexity. 251 00:22:42,590 --> 00:22:44,190 It's not very reliable. 252 00:22:44,310 --> 00:22:54,370 And if you want to, for example, have a conversation like this, recording this podcast, we're in two different spaces and these tools often under the hood use UDP for streaming. 253 00:22:54,650 --> 00:23:03,490 And right now, if this were to go over IPv4, there would be a complex state machine in between doing that hole punching and keeping track of what's going on. 254 00:23:03,490 --> 00:23:05,951 In IPv6, you just have a direct connection. 255 00:23:05,951 --> 00:23:07,691 You don't need any of that. 256 00:23:07,691 --> 00:23:11,892 You just have a straight line from A to B. 257 00:23:12,293 --> 00:23:15,033 I used to play World of Warcraft for a very long time. 258 00:23:16,114 --> 00:23:25,236 World of Warcraft, since it's very early days, had this beautiful toggle in its settings menu that would enable the preference for IPv6 over 4. 259 00:23:25,236 --> 00:23:31,970 And if you would enable this, you would actually get a more reliable connection because you would get an end-to-end connection. 260 00:23:31,970 --> 00:23:40,437 There's another one that I would like to highlight, which HTTP 3, the new standard of HTTP that the internet is slowly moving towards. 261 00:23:40,437 --> 00:23:43,899 HTTP 3 is not going over TCP. 262 00:23:43,899 --> 00:23:49,244 It runs on this new not quiet layer 4 thing. 263 00:23:49,244 --> 00:23:50,585 It's more like layer 4.5. 264 00:23:50,585 --> 00:23:52,065 It's called QUIC. 265 00:23:52,250 --> 00:23:57,250 Yeah, it's QUIC, which is built on top of IPV, sorry, on top of UDP. 266 00:23:57,250 --> 00:24:06,753 I guess the problem is UDP doesn't benefit from the net packet rewriting, so it's less reliable over IPv4, right? 267 00:24:06,753 --> 00:24:08,204 Is that where this is going? 268 00:24:09,467 --> 00:24:11,754 So how does that actually work then? 269 00:24:11,754 --> 00:24:17,806 you just get an end-to-end connection for A to B because all your devices have a globally routable address. 270 00:24:17,806 --> 00:24:20,177 Okay, so TCP is the one that has the handshake. 271 00:24:20,177 --> 00:24:28,212 You need to verify every packet that comes back or the server connection has to basically resend it to verify. 272 00:24:28,212 --> 00:24:33,195 UDP is fire and forget, but in a way, that's why it's used for streaming stuff. 273 00:24:33,195 --> 00:24:41,820 However, I will share that because of the world of streaming gets more complex every day, the way that recording actually works for the podcast, maybe this is interesting to 274 00:24:41,820 --> 00:24:46,294 someone, is uh my stream gets recorded locally and so does yours. 275 00:24:46,294 --> 00:24:48,977 and that's what we actually stitched together to make the episode. 276 00:24:48,977 --> 00:24:55,102 But while we're recording the episode, we care about lossy real-time packets rather than the lossless recording. 277 00:24:55,102 --> 00:25:02,789 So you can be talking, and I may not even know what you're saying because the stream is being dropped, but when we stitch the episode together at the end, we have the full 278 00:25:02,789 --> 00:25:04,591 context of what everyone was saying. 279 00:25:04,591 --> 00:25:12,910 And what's happening in the browser is we don't have a direct connection because I'm on a private behind-the-net connection and you're on a private network behind, you know... 280 00:25:12,910 --> 00:25:21,330 that or you're using IPv6 and I'm not connected with that, but it's using WebRTC or WebSockets and it would be using WebSockets, which would be better, but the problem is 281 00:25:21,330 --> 00:25:28,530 that WebSockets have historically been very slow and the problem with WebRTC is that most of the time you're blocked from the direct connection. 282 00:25:28,530 --> 00:25:36,810 So I'm wondering, first of all, where is QUIC going and does this help solve the real time streaming from, you know, person to person? 283 00:25:36,870 --> 00:25:40,432 Well, I love that you bring up WebRTC and WebSockets. 284 00:25:40,432 --> 00:25:45,115 In HTTP 3, there's this new feature that is slowly being rolled out. 285 00:25:45,115 --> 00:25:47,956 Right now, only Chromium-based browsers support this. 286 00:25:47,956 --> 00:25:59,833 But thanks to Interop 2026, this is also happening in Firefox and Safari now, it's a feature called WebTransport, which is like basically the same idea as WebSockets, in that 287 00:25:59,833 --> 00:26:03,945 you can have a bi-directional connection between the server and the client. 288 00:26:03,945 --> 00:26:06,466 Except WebSockets come with some uh 289 00:26:06,466 --> 00:26:07,708 limitations. 290 00:26:14,228 --> 00:26:15,032 But it's per job. 291 00:26:15,032 --> 00:26:17,420 It's like a per domain or something, right? 292 00:26:17,420 --> 00:26:20,195 It's 8 per domain, yeah, something like that. 293 00:26:20,195 --> 00:26:22,868 Or 8 per browser tab, I'm not sure. 294 00:26:23,082 --> 00:26:32,612 I think I remember it was domain because if you have the same tab open nine times, then if you have a WebSocket implementation, it starts to fail because you have too many tabs 295 00:26:32,612 --> 00:26:34,934 open, which is just amazing. 296 00:26:35,182 --> 00:26:36,123 beautiful. 297 00:26:36,123 --> 00:26:40,646 Okay, so it's nine per domain then, eight per domain, which is even worse. 298 00:26:40,907 --> 00:26:53,617 But WebTransport solves this problem because the way that QUIC has been designed is basically UDP streams, uh multiplexed UDP streams, where you just open one connection and 299 00:26:53,617 --> 00:26:56,320 WebTransport utilizes that very same connection. 300 00:26:56,320 --> 00:27:04,654 So effectively what you can do is you can open a thousand WebTransport uh sockets and you can just 301 00:27:04,654 --> 00:27:07,734 chats with whatever with the server. 302 00:27:07,894 --> 00:27:15,474 And it's faster and also quite a bit more reliable because of HTTP3's design. 303 00:27:15,474 --> 00:27:20,294 And I'm super excited for this to finally launch and so I can use it. 304 00:27:20,294 --> 00:27:22,354 I really don't like web sockets. 305 00:27:23,960 --> 00:27:25,139 It sounds like... 306 00:27:25,334 --> 00:27:33,776 You know, we've had ideas on how to make the connections of really the internet more efficient and more performant for a long time, legacy companies have been getting in the 307 00:27:33,776 --> 00:27:33,996 way. 308 00:27:33,996 --> 00:27:40,058 And I feel like we're a bit beholden to the cloud providers now, which are quote unquote said to be running most of the internet. 309 00:27:40,058 --> 00:27:47,480 uh At least it seems that way when one of them is having an incident, it's very clear that there's a problem are now responsible for doing this. 310 00:27:47,480 --> 00:27:54,582 It's like another one is the uh the new verb for query that I've been waiting for for decades, basically. 311 00:27:54,582 --> 00:27:55,234 uh 312 00:27:55,234 --> 00:27:58,385 just to throw this out there, there's the rest verbs, right? 313 00:27:58,385 --> 00:28:03,896 The ones that the browsers can use, get, post, patch, delete, you know, whatever. 314 00:28:03,896 --> 00:28:10,378 And what I was really missing was the ability to send a payload and have it be cacheable. 315 00:28:10,378 --> 00:28:13,329 And the only ones that accept payloads aren't cacheable. 316 00:28:13,329 --> 00:28:15,780 You can't catch a post request, right? 317 00:28:15,780 --> 00:28:19,561 It's meant to be represented of a new request every single time. 318 00:28:19,561 --> 00:28:24,076 But if you have a search query, right, you're looking for some items from an e-commerce store and whatnot. 319 00:28:24,076 --> 00:28:30,402 It can be incredibly complex to stick the whole query in the query parameters of a URL because you don't get a body sent with a get. 320 00:28:30,402 --> 00:28:37,538 Now, technically you can send a body with a get request, but all the cloud providers, they vomit when you try to do this. 321 00:28:37,739 --> 00:28:39,470 And the solution is to add a query. 322 00:28:39,470 --> 00:28:47,637 And I feel like we're beholden to them to actually support this new verb that comes out, just like we're beholden to having them actually support IPv6 in order to start utilizing 323 00:28:47,637 --> 00:28:50,518 it and therefore the improvements with the other technologies. 324 00:28:50,518 --> 00:28:52,660 Yes, I totally agree with that. 325 00:28:52,660 --> 00:28:53,260 I don't know. 326 00:28:53,260 --> 00:28:57,153 I'm going to paraphrase this because I can't remember the exact quote, but Mr. 327 00:28:57,153 --> 00:29:10,973 Fint-Serv, one of the creators of TCP-IP, said at some point that IPv4 was just like a proof of concept, a thing that should not have been widely adopted and that TCP-IPv6 was 328 00:29:10,973 --> 00:29:13,035 going to be the real thing that should have been adopted. 329 00:29:13,035 --> 00:29:17,870 Now, back then they also had an IPv5 which essentially became 330 00:29:17,870 --> 00:29:25,844 uh voice over IP and they had experience with IPv7, 8 and 9 but IPv6 is the one that got stuck. 331 00:29:25,844 --> 00:29:28,940 IPv4 should never have been the thing that got deployed. 332 00:29:29,122 --> 00:29:32,386 This is true of a bunch of different technologies as well. 333 00:29:32,386 --> 00:29:36,111 I think the same thing is said for JavaScript in the browser. 334 00:29:36,111 --> 00:29:45,132 Like, yeah, I just needed to enable it so that I could do one specific thing and now only, well, then there was a lot of years of the... 335 00:29:45,132 --> 00:29:52,620 cross-site requests being executed before we actually got to uh fetch implementation for real API access. 336 00:29:52,620 --> 00:29:57,084 But it was also set as a thing that, yeah, probably won't stick. 337 00:29:57,084 --> 00:29:58,526 It's not even really that critical. 338 00:29:58,526 --> 00:30:01,288 And the implementation was quite naive at the time. 339 00:30:01,358 --> 00:30:04,378 Yeah, I just want to come back to AWS for a second. 340 00:30:04,378 --> 00:30:05,298 Yeah. 341 00:30:05,298 --> 00:30:14,338 Specifically at AWS reInvent 2023, I had a brief chat with the person who designed VPC lattice. 342 00:30:14,358 --> 00:30:28,178 Now, for those that don't know what VPC lattice is, it's basically an overlay network on AWS where you can do fancy stuff like IAM policies for routing and skip a whole lot of the 343 00:30:28,178 --> 00:30:29,996 networking complexity that 344 00:30:29,996 --> 00:30:40,889 Really, IPv4 brings and with IPv6, the only benefit of VPC Lattice would be routing policies, because you can have IAM rules for the routing policies rather than IP 345 00:30:40,889 --> 00:30:41,902 addresses. 346 00:30:41,902 --> 00:30:51,668 It sounds like someone over engineered their network stack and a large enterprise said, you know what, we have very specific requirements where we want permission controlled 347 00:30:51,668 --> 00:30:57,262 access based off of the actual network packets that are being sent over the network and want to control it with IAM. 348 00:30:57,262 --> 00:31:00,414 And I feel like all of those things is something no one should ever want. 349 00:31:00,556 --> 00:31:05,389 Well, for certain environments, can see this being a thing. 350 00:31:07,631 --> 00:31:11,894 that's a very small, small subset of that. 351 00:31:11,894 --> 00:31:20,360 I think if you just have a well-defined IPv6 base, that's just going to be so much easier because you don't need any of that complexity. 352 00:31:20,360 --> 00:31:29,634 basically, this guy that designed this said that one of the primary use cases was just to stop having to deal with IPv4 complexity. 353 00:31:29,634 --> 00:31:42,101 because as I mentioned at the start of this episode, the traditional way people have been architecting at AWS has been suggesting your architect, your VPC setup is you have a 354 00:31:42,101 --> 00:31:46,384 public subnet, one for each availability zone. 355 00:31:46,384 --> 00:31:49,065 So in most regions you will have three of those. 356 00:31:49,086 --> 00:31:56,640 You uh put an app gateway on that and then you create more, uh one more subnet for each. 357 00:31:56,710 --> 00:32:05,358 availability zone that you call a private subnet that has routing rules to go through the public subnet to the internet, but that's the only way they can reach the internet. 358 00:32:05,358 --> 00:32:13,164 And if you want to attach multiple accounts to that and you want to have routing policies between accounts, for example, you want to have one big database cluster because you have 359 00:32:13,164 --> 00:32:14,805 a distributed monolith. 360 00:32:15,066 --> 00:32:18,489 But you pretend that you don't have one of those. 361 00:32:18,529 --> 00:32:24,472 So you've got your central database account that all of your microservices talk to. 362 00:32:24,472 --> 00:32:26,289 that are deployed by individual teams. 363 00:32:26,289 --> 00:32:28,134 um 364 00:32:28,302 --> 00:32:29,962 I feel like I'm going to have a stroke. 365 00:32:29,962 --> 00:32:34,062 No one has what AWS account that they call their production database account. 366 00:32:34,062 --> 00:32:35,894 Please tell me that doesn't exist. 367 00:32:35,894 --> 00:32:39,036 It totally does and I happen to deal with one of those. 368 00:32:39,637 --> 00:32:42,439 Anyway, so that's a thing. 369 00:32:42,439 --> 00:32:47,423 Well, this historically grew because there used to be an actual monolith. 370 00:32:47,484 --> 00:32:49,605 Sure, it was a 15 year old monolith. 371 00:32:49,605 --> 00:32:58,052 It was terribly designed because it was built during the area where it was popular to go and outsource to India to the cheapest bidder. 372 00:32:58,052 --> 00:33:05,822 And in this particular instance, those cheapest bidders, the cheapest bidder would go even cheaper internally because they were also doing that internally. 373 00:33:05,822 --> 00:33:14,880 And at some point this went five layers deep and the code that was written was just absolutely atrocious because I got what you're paying for. 374 00:33:14,880 --> 00:33:18,093 This entire project was quite a mess. 375 00:33:18,093 --> 00:33:27,211 However, um over the year it was tried to be salvaged and at what was finally being deprecated or being shut down was actually... 376 00:33:27,211 --> 00:33:30,704 Yeah, it was a terrible code base, but you could work in it. 377 00:33:30,704 --> 00:33:33,526 um You could make your changes. 378 00:33:33,862 --> 00:33:35,715 This is your typical legacy code base. 379 00:33:35,715 --> 00:33:38,549 There were decisions that were questionable. 380 00:33:38,550 --> 00:33:42,055 anyway, the idea was to move out of this. 381 00:33:42,196 --> 00:33:44,739 And that was supposed to be a two year migration. 382 00:33:44,841 --> 00:33:46,252 That took nine years. 383 00:33:46,360 --> 00:33:48,147 So right on schedule. 384 00:33:48,278 --> 00:33:49,838 Exactly, right on schedule. 385 00:33:49,899 --> 00:33:51,280 Very much written budget. 386 00:33:51,280 --> 00:34:03,098 And this migration went to somewhat microservices, but there were so many dependencies on this particular database still that there was quite a few apps still talking to it. 387 00:34:03,098 --> 00:34:09,853 But they were all uh running in separate AWS accounts because, well, you want to do microservices now, so each team is going to get one of those. 388 00:34:09,853 --> 00:34:17,752 Well, first of all, there was an Excel sheet with IPv4 ranges that were being used because this was also being paired to the 389 00:34:17,752 --> 00:34:21,110 to the no longer active uh on-prem beta center. 390 00:34:21,110 --> 00:34:23,433 The IP address had never been released. 391 00:34:23,463 --> 00:34:32,104 So the missing part here that's also important, I think, is that if you want to peer between multiple AWS accounts, they need to have non-overlapping IPv4 ranges, which I 392 00:34:32,104 --> 00:34:43,946 don't actually understand why, because when you're connecting them either direct peer or over uh transit gateway, which is like a multi-account peering strategy for IPv4, it could 393 00:34:43,946 --> 00:34:46,377 do the translation itself, but it doesn't. 394 00:34:46,377 --> 00:34:53,035 uh It requires all of the VPC subnet uh cedar blocks to be mutually exclusive. 395 00:34:53,035 --> 00:35:02,568 Yes, however, this has been fixed by VPC endpoints uh where it will do some fancy translation and this is very useful, however... 396 00:35:03,908 --> 00:35:08,189 costs a lot more money, Which again, IPv6 saves your money. 397 00:35:08,270 --> 00:35:09,050 Where was I at? 398 00:35:09,050 --> 00:35:09,959 uh 399 00:35:09,959 --> 00:35:13,197 I cannot tell you now. 400 00:35:13,826 --> 00:35:15,540 That doesn't gonna be cut out, just rants. 401 00:35:15,540 --> 00:35:16,982 oh 402 00:35:16,982 --> 00:35:18,766 man, um... 403 00:35:18,766 --> 00:35:28,533 um Right, um this shared database, everybody has been moving to their native-based account, been writing their microservices, but there was still this dependency on the 404 00:35:28,533 --> 00:35:29,814 central database. 405 00:35:29,814 --> 00:35:32,615 Now, there were multiple ways that this was being solved. 406 00:35:32,615 --> 00:35:36,818 One of them was being a massive Kafka cluster that everybody would subscribe to. 407 00:35:36,818 --> 00:35:46,645 However, this was using AWS managed Kafka, uh MSK, which was IPv4 only, so you would have largely half the same problem again. 408 00:35:46,645 --> 00:35:48,238 Now, that was being... 409 00:35:48,238 --> 00:35:51,658 problem was being solved by throwing a graphql on top. 410 00:35:51,758 --> 00:36:00,358 Actually no, so what they did was they had all of the topics right into a postgres database and that postgres database had graphql on top. 411 00:36:00,358 --> 00:36:08,578 And this was a bespoke layer that was written on top of it because it also had access controls that were built in house to just deal with this problem. 412 00:36:08,578 --> 00:36:12,578 While looking at this from the outside you'd go what the fuck. 413 00:36:12,578 --> 00:36:17,438 And this was actually a quite reasonable solution to the constraints. 414 00:36:17,755 --> 00:36:21,319 Just don't think of that GraphQL like an API. 415 00:36:21,500 --> 00:36:21,880 wasn't. 416 00:36:21,880 --> 00:36:24,304 It was just stored procedures as a service. 417 00:36:24,304 --> 00:36:26,246 oh 418 00:36:26,967 --> 00:36:30,930 There is something that comes up a lot of times here, because I've seen this too. 419 00:36:30,930 --> 00:36:37,065 I was working at an aerospace company and there was one team that owned the data. 420 00:36:37,065 --> 00:36:49,685 They weren't even the DBAs, it was just one team that were tasked with the ownership of the critical manufacturing data for actually putting together the vehicles. 421 00:36:49,685 --> 00:36:53,758 There were other applications owned by other teams that would need access to that fundamental data. 422 00:36:53,758 --> 00:36:56,086 The solution was, of course, 423 00:36:56,086 --> 00:37:00,928 that the team that owns the data would create a REST interface and expose the data to, who are we kidding? 424 00:37:00,928 --> 00:37:01,989 No, that wasn't the solution. 425 00:37:01,989 --> 00:37:12,874 The solution was one engineer got access to the database that was outside of the team that owned it and they created a REST API and that REST API had one endpoint called post which 426 00:37:12,874 --> 00:37:22,238 literally took in a SQL and just ran it against this database to return the result for whatever anyone wanted. 427 00:37:22,456 --> 00:37:27,758 Did it at least use basic ouf for the uh database user login? 428 00:37:27,758 --> 00:37:38,157 Um, you know, I don't think I don't think I'm legally allowed to share and if I do the penalty is like like up to 10 million dollars in 10 years in prison or something if I if I 429 00:37:38,157 --> 00:37:38,856 do 430 00:37:38,856 --> 00:37:40,657 yeah, I won't pressure any further on that story. 431 00:37:40,657 --> 00:37:41,400 oh 432 00:37:41,400 --> 00:37:45,088 it was called though it was called the warp transfer function 433 00:37:45,088 --> 00:37:47,883 I know what company you're talking about, so that makes sense. 434 00:37:48,539 --> 00:37:57,742 The other really clever thing you could do instead of exposing the data, and I've seen this done multiple times actually, is that you try to implement a real-time database 435 00:37:57,742 --> 00:38:05,906 replication, like read and write across every AWS account at the same time so that everyone can just integrate with a database that's stored in their account. 436 00:38:05,906 --> 00:38:12,688 And then the magic part is somehow all these databases are kept in sync, which is actually just not a solvable problem. 437 00:38:14,229 --> 00:38:15,370 But I've seen it tried. 438 00:38:15,370 --> 00:38:16,250 Yeah. 439 00:38:16,303 --> 00:38:16,965 Beautiful. 440 00:38:16,965 --> 00:38:18,026 oh 441 00:38:18,026 --> 00:38:20,266 the migration over at this point? 442 00:38:20,266 --> 00:38:21,466 Did they ever finish? 443 00:38:21,466 --> 00:38:23,046 Is it going in the right direction? 444 00:38:23,046 --> 00:38:30,046 Is the database going to be removed or is that database going to be turned into its own first class service? 445 00:38:30,104 --> 00:38:37,244 Within my last year, I am very happy to say this database has been shut down and the migration was considered finished. 446 00:38:38,447 --> 00:38:40,083 Now the database is called Salesforce. 447 00:38:40,083 --> 00:38:42,516 we completed our migration to Salesforce. 448 00:38:42,516 --> 00:38:44,328 I don't know which one is worse, honestly. 449 00:38:44,328 --> 00:38:54,796 Well, because at least your own database, no matter how terrible your routing setup may be, um at least allows you to query it and get data from it. 450 00:38:54,796 --> 00:39:05,225 Salesforce, the moment you start developing outside of it, it becomes very difficult to do that because you get hit by limits, platform limits is what they're called, that can be 451 00:39:05,225 --> 00:39:10,249 quite annoying to deal with and um just stupid things. 452 00:39:10,249 --> 00:39:12,174 Like for example, in Salesforce, 453 00:39:12,174 --> 00:39:15,215 And I might be wrong, but this is what I remember. 454 00:39:15,215 --> 00:39:17,396 Whoever's listening might want to fact check me on this. 455 00:39:17,396 --> 00:39:25,740 em If you create a table on Salesforce, you can never add more columns or change the column definition. 456 00:39:25,740 --> 00:39:34,753 So what you would get is you'd have a well-defined table, but there would always be like 50 more columns. 457 00:39:34,753 --> 00:39:41,262 was an additional column underscore one, additional column underscore two, et cetera, be sitting there for 458 00:39:41,262 --> 00:39:45,262 additional fields that might arise from future business cases. 459 00:39:45,321 --> 00:40:02,322 And if you look at queries where you would be querying like select ID, comma, additional field 43, comma, additional field 2 from table 1 and then join on where additional field 460 00:40:02,322 --> 00:40:08,582 43 from this database equals table 2, additional field 50. 461 00:40:09,504 --> 00:40:11,165 It'd be very nice to read. 462 00:40:11,165 --> 00:40:13,478 m 463 00:40:14,134 --> 00:40:15,355 ridiculous. 464 00:40:15,366 --> 00:40:15,816 yes. 465 00:40:15,816 --> 00:40:18,980 It doesn't really matter whether or not it can be different. 466 00:40:18,980 --> 00:40:24,265 The fact is that they thought that this is what had to be done and this was the right way to go about it. 467 00:40:25,326 --> 00:40:27,127 yeah, this is absolutely awful. 468 00:40:27,308 --> 00:40:41,471 One way to get around this is just to migrate your entire data to a new table and solve this problem so you'd have like, uh customers underscore 54 point old dot back, um which 469 00:40:41,471 --> 00:40:46,094 would be several terabytes large because you're a big boy company and you many customers. 470 00:40:46,094 --> 00:40:48,474 It's one thing to say migrate and I'm totally with you. 471 00:40:48,474 --> 00:40:55,794 my, thing is that realistically in my entire engineering career, was always migrations are expensive because it's difficult to write. 472 00:40:55,794 --> 00:41:00,534 But like at this point in my career, I believe the app, the opposite is actually true. 473 00:41:00,534 --> 00:41:02,394 Migrations are incredibly cheap to write. 474 00:41:02,394 --> 00:41:05,234 Like writing a migration and switching to a new table, that part's cheap. 475 00:41:05,234 --> 00:41:08,774 Actually getting the data transferred from one physical location to another one. 476 00:41:08,774 --> 00:41:15,008 That's the thing is like, Oh, you know, we're trying to copy the data over and it says it's going to take us 31 days and that's. 477 00:41:15,008 --> 00:41:20,226 a normal amount of time for this to happen with the fastest hard drives that ever existed. 478 00:41:20,226 --> 00:41:22,730 Like, it's just absolutely ridiculous. 479 00:41:22,730 --> 00:41:25,814 And yet, you know, that's actually where the problem is. 480 00:41:26,198 --> 00:41:34,710 Yes, 31 days with the fastest hard drives available means that you have a very good problem probably because you have a lot of customers. 481 00:41:35,146 --> 00:41:46,671 Or, or, or, uh I one-up you one there, and that's we have so much critical data that uh is very important for the business that we can't afford to delete. 482 00:41:46,671 --> 00:41:57,456 I assure you, was in these databases was essentially like uh a bunch of IoT sensors that were collecting information for multiple years. 483 00:41:57,456 --> 00:42:02,458 And one of them may have something really valuable that we just can't let go of. 484 00:42:02,832 --> 00:42:03,915 Of course, of course. 485 00:42:03,915 --> 00:42:05,530 That's how it works. 486 00:42:05,530 --> 00:42:07,384 It's business critical information. 487 00:42:08,259 --> 00:42:10,452 Okay, this may be a good opportunity to switch over to. 488 00:42:10,452 --> 00:42:14,506 Okay, yeah, so what did you bring for us, Don? 489 00:42:14,998 --> 00:42:19,822 So I'm going to bring something that's completely unrelated to uh IPv6. 490 00:42:19,822 --> 00:42:30,231 um But also comes from the bit of there are simpler ways to do things and for some reason they're not being adopted. 491 00:42:30,231 --> 00:42:37,397 um And my pick for today is going to be SolidJS. 492 00:42:37,397 --> 00:42:42,894 So I bet my company on SolidJS rather than React, mostly because... 493 00:42:42,894 --> 00:42:47,494 I've been writing React for six, seven years. 494 00:42:47,494 --> 00:42:48,954 I can balance it. 495 00:42:49,094 --> 00:42:55,614 Especially when React hooks were introduced, I believe this was 2018, they came with the rules of hooks. 496 00:42:55,954 --> 00:43:03,594 And they add quite a lot of mental overhead or cognitive overhead I found in my development cycle. 497 00:43:03,594 --> 00:43:07,274 Now, if you write React all day, you might get numb to this. 498 00:43:07,274 --> 00:43:09,686 And you might only, every now and then, 499 00:43:09,686 --> 00:43:17,482 shoot yourself in the foot, which is why React Direct Team introduced Direct Compiler in React 19 to alleviate this problem. 500 00:43:17,482 --> 00:43:23,378 But to me, this is just like there must be something fundamentally wrong with this approach. 501 00:43:23,378 --> 00:43:24,058 I agree. 502 00:43:24,058 --> 00:43:31,444 And I'm a big fan of JSX and there's other frameworks out there like Vue, like Svelte, like Angular. 503 00:43:31,444 --> 00:43:35,768 They're also all great frameworks, but they don't do JSX and I really like JSX. 504 00:43:35,768 --> 00:43:38,860 But there's this one other framework out there called SolidJS. 505 00:43:38,862 --> 00:43:41,544 And it's been around for many years at this point. 506 00:43:41,544 --> 00:43:45,386 And they do two things very different from React. 507 00:43:45,386 --> 00:43:52,390 uh One is, while they're in the hooks, they do two things very different from React. 508 00:43:52,390 --> 00:44:03,876 One of them is the reactivity model, where in React, uh when you have a component, every time something changes, it will just re-execute your function over and over again. 509 00:44:03,876 --> 00:44:05,637 In Solid, that's not the case. 510 00:44:05,637 --> 00:44:06,956 It will render. 511 00:44:06,956 --> 00:44:15,752 It will execute your component once and your state is managed by signals rather than these magical hooks. 512 00:44:15,752 --> 00:44:28,841 Now, the syntax for signals is the exact same as in React, except the thing the output is an array with a function that returns a value and a function to change the value rather 513 00:44:28,841 --> 00:44:30,742 than just the value. 514 00:44:30,742 --> 00:44:36,716 So if you want to use this, what you do is you go into your return statement 515 00:44:36,766 --> 00:44:43,411 And when you want to use the value, you just execute the function rather than just putting it straight in there. 516 00:44:43,612 --> 00:44:49,777 And this approach gives you very, very fine grained control over reactivity. 517 00:44:49,777 --> 00:45:01,046 And because of that difference, I found SolidJS to be so much more intuitive to write despite it looking exactly and feeling exactly like React. 518 00:45:01,134 --> 00:45:06,298 I always found that the concept of having to explain what a functional component was, was always messed up to me. 519 00:45:06,298 --> 00:45:09,290 And Hooks just added this extra complexity on top. 520 00:45:09,290 --> 00:45:17,916 It's one of the reasons why I personally was always a fan of Vue and the transition of Vue 3 also added this sort of, it doesn't matter where you are, it doesn't matter if you're 521 00:45:17,916 --> 00:45:22,029 generating uh components that are used in your UI or doing something functional. 522 00:45:22,029 --> 00:45:24,911 You can rely on the state management. 523 00:45:24,911 --> 00:45:27,603 Just the same, there's no difference there. 524 00:45:27,603 --> 00:45:28,958 Everything's, you know. 525 00:45:28,958 --> 00:45:32,100 is very similar, irrelevant of the context. 526 00:45:32,320 --> 00:45:41,846 And I think that's one of the biggest problems that you mentioned that realistically, if you're using a framework that adds workarounds and wrappers to solve a problem that it 527 00:45:41,846 --> 00:45:44,868 created itself, it should tell you like, don't use this thing. 528 00:45:44,868 --> 00:45:52,151 And actually, I think this may go into, I think if anyone has their bingo card ready, I'm gonna mention AI for the first time in this episode. 529 00:45:52,972 --> 00:45:56,086 If there are examples of doing something out there, 530 00:45:56,086 --> 00:46:00,228 then LLMs are more likely to provide you with those examples when you need to solve a problem. 531 00:46:00,228 --> 00:46:08,262 But statistically, if those examples are more likely to be wrong than right, then likelihood is you're going to end up with more likely to have wrong code in your 532 00:46:08,262 --> 00:46:09,213 production environment. 533 00:46:09,213 --> 00:46:10,283 So you actually want it. 534 00:46:10,283 --> 00:46:17,887 There's a trade off of switching to frameworks and languages that are more likely to be objectively correct in what they're doing. 535 00:46:17,887 --> 00:46:18,277 OK. 536 00:46:18,277 --> 00:46:19,057 Yeah. 537 00:46:19,217 --> 00:46:20,398 I like your pick. 538 00:46:20,654 --> 00:46:25,440 um I would like to highlight as well that Solid.js is so easy to adopt. 539 00:46:25,440 --> 00:46:28,184 recently had a developer start on my team. 540 00:46:28,184 --> 00:46:30,217 They had never looked at Solid.js before. 541 00:46:30,217 --> 00:46:38,157 They have had many years of React experience, but they were creating actual functional pull requests within a day. 542 00:46:38,190 --> 00:46:39,050 Cool. 543 00:46:39,171 --> 00:46:40,631 I like your pick. 544 00:46:40,751 --> 00:46:42,092 So I guess I'll share mine. 545 00:46:42,092 --> 00:46:43,630 So I mentioned this earlier. 546 00:46:43,630 --> 00:46:46,495 I actually switched because of something you said. 547 00:46:46,495 --> 00:46:57,901 So there's this YouTube video out there uh where the content creator goes and creates hard drives, basically the idea of a hard drive from different technologies that exist. 548 00:46:57,901 --> 00:46:59,441 And it's called Harder Drive. 549 00:46:59,441 --> 00:47:02,463 And there'll be a link in the description uh below the episode. 550 00:47:02,463 --> 00:47:08,202 And he goes through basically what actually a hard drive is, like conceptually, which is basically storing data. 551 00:47:08,202 --> 00:47:10,853 and how can you store data via other mechanisms? 552 00:47:10,853 --> 00:47:13,515 And if we think about hard drives, they're not permanent, right? 553 00:47:13,515 --> 00:47:15,066 They can degrade over time. 554 00:47:15,066 --> 00:47:16,046 The metal can wear. 555 00:47:16,046 --> 00:47:22,310 If you're using a old style HDD, then the platter can degrade or can get scraped. 556 00:47:22,310 --> 00:47:23,930 So it's not perfect. 557 00:47:23,971 --> 00:47:31,175 And in the video, one of the harder drives that he makes is actually using uh ping with ICMP packets. 558 00:47:31,175 --> 00:47:37,418 So basically you can actually add some additional data after the header in a ping packet that will come back to you. 559 00:47:37,818 --> 00:47:40,259 So you can verify the packet is authenticity. 560 00:47:40,259 --> 00:47:44,422 And so you can actually store arbitrary data in there and then send a ping to an IP address. 561 00:47:44,422 --> 00:47:46,403 And part of that is sending the packet back. 562 00:47:46,403 --> 00:47:51,015 So that time, that dwell time that the packets in the internet basically is stored. 563 00:47:51,015 --> 00:47:53,287 Your data is stored in the internet. 564 00:47:53,287 --> 00:48:03,392 And obviously there's a failure mode here where the data may not come back if the IP address isn't being used or is down or doesn't respond to ICMP because they're being 565 00:48:03,392 --> 00:48:03,722 blocked. 566 00:48:03,722 --> 00:48:07,064 in a lot of cloud providers, their IP addresses, don't. 567 00:48:07,064 --> 00:48:16,507 your production servers, right, applications, you don't return pings, you may only be open on port 80 for the IP address, basically narrows down, scans the whole range, figures out 568 00:48:16,507 --> 00:48:21,958 which IP addresses are actually responding to pings, and then goes to store some data there, and then does some additional calculations. 569 00:48:21,958 --> 00:48:32,481 And there's a couple other mechanisms too, for storing data that I find as a good thought experiment, including like how many chainsaws can you juggle in the air? 570 00:48:32,481 --> 00:48:36,082 Very clever, I think, as an episode, and very entertaining. 571 00:48:36,110 --> 00:48:47,670 Okay, so thank you Don for coming on and chatting with us about IPv6 and other futuristic improvements to the network topology and internet to come in the near future. 572 00:48:49,030 --> 00:48:50,090 And thank you. 573 00:48:50,090 --> 00:48:55,206 And thanks to all the viewers for checking out this episode and hopefully everyone will be back again next week.