WEBVTT 1 00:00:04.919 --> 00:00:09.640 Okay, Hey, what's going on? Everybody got another episode of Adventures in 2 00:00:10.000 --> 00:00:12.800 DevOps. I'm back this week. Hey, Warren, how's it going. 3 00:00:14.199 --> 00:00:16.600 It's great. You know, I didn't know if you were going to show 4 00:00:16.640 --> 00:00:19.879 up, so I was thinking about we'd be having to do a second episode 5 00:00:20.079 --> 00:00:24.199 just by myself. I mean, I think last week went right. You 6 00:00:24.239 --> 00:00:27.120 know, I was on an island in the South Pacific, so it went 7 00:00:27.160 --> 00:00:32.759 great for me as well. I have zero complaints. I'm jealous. I'm 8 00:00:32.759 --> 00:00:37.719 gonna have to head over there myself, so I've got my Factor of the 9 00:00:37.719 --> 00:00:44.520 week. I was over in Warsaw doing a cybersecurity short conference meetup, and 10 00:00:45.240 --> 00:00:50.679 I got questions whether or not using SaaS is secure. And I feel like 11 00:00:50.719 --> 00:00:55.600 it's an interesting proposition people bring up as a challenge whether or not what you're 12 00:00:55.600 --> 00:01:00.280 building internally versus externally is more or less secure than that. And I find 13 00:01:00.320 --> 00:01:04.760 it really interesting that still lots of companies believe that somehow the engineers that you've 14 00:01:04.840 --> 00:01:08.239 hired are better than the ones that another company is hired. Now, for 15 00:01:08.239 --> 00:01:11.879 sure, it can be true sometimes, but I still feel like there's an 16 00:01:11.879 --> 00:01:15.200 overwhelming majority that keeps questioning this, which is really a surprise for me. 17 00:01:17.840 --> 00:01:25.680 Yeah, So what you're saying there is that people are reinventing the wheel still 18 00:01:25.760 --> 00:01:29.280 because they don't trust sas. Is that the Yeah, for sure. I 19 00:01:29.319 --> 00:01:32.319 mean it's a whole nother level on top of not invented here, right, 20 00:01:32.400 --> 00:01:34.319 it's a oh yeah, that's not secure. And I feel like it's just 21 00:01:34.400 --> 00:01:40.000 this abyss that you can fall into of believing that because we're doing it ourselves, 22 00:01:40.079 --> 00:01:44.000 we're going to somehow do it better, it's going to be more secure 23 00:01:44.159 --> 00:01:47.959 than another solution. I'm just like, you know, show me where your 24 00:01:47.959 --> 00:01:52.480 interview process is that proves that the engineering team is definitely better, because there's 25 00:01:52.519 --> 00:01:57.079 lots of good companies out there that are have great interviewing processes, have great 26 00:01:57.120 --> 00:02:00.640 cultures that are for sure building secure solutions. Yeah for sure. Yeah, 27 00:02:00.680 --> 00:02:07.400 I'm leveraging that right. Well, may I may I interrupt? May I 28 00:02:07.599 --> 00:02:13.400 absolutely an opinion? Yeah, bring it on, go for it. I 29 00:02:13.479 --> 00:02:15.360 think I understand where people might be coming from it. I don't think it's 30 00:02:15.400 --> 00:02:20.439 because they think that they're better engineers. I'm sure some of them do, 31 00:02:22.520 --> 00:02:34.000 but I think that there's some legitimate engineering consideration around isolation, right, Like 32 00:02:34.080 --> 00:02:36.360 I think like as an engineer, you would say, Okay, well, 33 00:02:36.400 --> 00:02:42.240 if it's like inside my ABS account and I control the boundaries of this account, 34 00:02:42.280 --> 00:02:46.680 the VPC, the im rolls as account as an example, is like 35 00:02:46.719 --> 00:02:52.560 an isolation boundary, and I think like there is something to say about going 36 00:02:52.599 --> 00:02:58.520 outside of that boundary into another you know, and then into another system. 37 00:02:58.599 --> 00:03:02.400 And so I think that maybe some of that sentiment comes from from that isolation 38 00:03:02.520 --> 00:03:07.479 boundary, not necessarily from like I didn't build it, so I don't trust 39 00:03:07.479 --> 00:03:14.199 it. I don't know. Yeah, I feel like we should introduce our 40 00:03:14.280 --> 00:03:21.599 guest for today, right. That new voice that you just heard is our 41 00:03:21.680 --> 00:03:29.360 guest, Eli Ben Israel, former ABS, former Microsoft, the CEO and 42 00:03:29.439 --> 00:03:34.680 co founder of Wing. And this is a cool fact you created the AWS 43 00:03:34.800 --> 00:03:39.080 CDK, Is that right? Yeah? Yeah, you just hold that. 44 00:03:39.400 --> 00:03:45.759 Yeah, Yeah, of course I did. Mean and an amazing team that 45 00:03:46.240 --> 00:03:53.039 Amazon and WUS and but yeah, it's it's really really really proud of this 46 00:03:53.120 --> 00:04:01.159 project. That definitely been really sure the journey. Yeah, just looking at 47 00:04:01.199 --> 00:04:05.080 your background here, it seems like it's been a fun journey, which I've 48 00:04:05.080 --> 00:04:08.479 always you know, I feel the same about my career, and I just 49 00:04:08.520 --> 00:04:14.560 think how amazing that is that I could spend three decades doing something and go 50 00:04:15.120 --> 00:04:18.720 that was pretty cool, man, and continuing to be passionate about it and 51 00:04:18.759 --> 00:04:24.560 like excited about it. I feel like, actually, I think Microsoft was 52 00:04:24.560 --> 00:04:32.399 the first time in my career where I stumbled into old geezers who are still 53 00:04:32.720 --> 00:04:38.879 doing software for a living and still writing code and still have this like childish 54 00:04:39.120 --> 00:04:46.720 enthusiasm after you know, forty years of programming and got really inspired by that. 55 00:04:46.800 --> 00:04:49.240 I feel like that was like, as a young engineer, it was 56 00:04:49.279 --> 00:04:55.680 like, yeah, I can I can see myself doing this for a few 57 00:04:55.720 --> 00:05:00.439 more decades. Oh for sure, I agree, And I think that's super 58 00:05:00.439 --> 00:05:04.279 cool because a lot of people can't say that, And I know for sure 59 00:05:04.279 --> 00:05:09.879 if I were in a different career, I may not be as excited about 60 00:05:09.879 --> 00:05:12.480 it. So I think it's really really cool that we can do that. 61 00:05:13.199 --> 00:05:15.439 Well, now, I'm worried that the first job you get out of university 62 00:05:15.519 --> 00:05:19.079 or you know, get into the professional environment, whoever is around you is 63 00:05:19.120 --> 00:05:24.480 going to dictate how were you inspiration and how you think about work goes on 64 00:05:24.560 --> 00:05:28.079 for the rest of your professional life, and that that scares me a bit 65 00:05:28.160 --> 00:05:31.959 because I feel like there were way too many jaded engineers at the early on 66 00:05:32.040 --> 00:05:38.439 places where I worked. I don't think it would it would dictate it. 67 00:05:38.480 --> 00:05:42.959 I think, like like anything in life, you you find your role models 68 00:05:44.399 --> 00:05:48.600 during your journey, and you identify them when they they're the right road models, 69 00:05:48.680 --> 00:05:51.720 right like, not necessarily with the first one, the first ones that 70 00:05:51.759 --> 00:05:58.240 you encounter. Yeah. I can say from my perspective that a lot of 71 00:05:58.279 --> 00:06:01.959 the the mentors in role models that I had over my career, it wasn't 72 00:06:02.040 --> 00:06:08.279 until years and sometime decades later that I realized that they were mentors and role 73 00:06:08.319 --> 00:06:11.879 models. Yeah. I mean, I don't think it's well defined, and 74 00:06:11.920 --> 00:06:15.360 I also think that there the corollary problem here is you're not really talked to 75 00:06:15.560 --> 00:06:18.920 or taught about how to find a role model or why you might want to 76 00:06:18.959 --> 00:06:21.279 find one, or what that even looks like and how it can help you. 77 00:06:21.360 --> 00:06:25.720 I feel like at one point in your career people start popping on and 78 00:06:25.759 --> 00:06:28.360 be like, oh, I it would probably be good if I had one 79 00:06:28.399 --> 00:06:32.519 of these. Maybe how do I get one? Where's the app? Where's 80 00:06:32.600 --> 00:06:38.480 the app? Right? You joke? But I'm sure there was one out 81 00:06:38.480 --> 00:06:42.199 there now, like find your tech mentor, right and go on there? 82 00:06:43.560 --> 00:06:46.680 Actually both I think both Microsoft and Amazon has like had like internal systems for 83 00:06:47.600 --> 00:06:53.800 matching you with the mentor. So it's not so makes sense right, the 84 00:06:53.800 --> 00:07:00.839 AI has automatically selected your mentor. Please click continue Why it has Scarlette Johansson's 85 00:07:01.319 --> 00:07:14.920 It has Scarlett Johanson's voice. Cool. So aside from mentoring and sas and 86 00:07:15.560 --> 00:07:19.600 careers, what is wing? I'm curious about that because I kind of have 87 00:07:19.600 --> 00:07:21.399 a little bit of an idea, but I want to hear it straight out 88 00:07:21.439 --> 00:07:26.839 of your mouth. Tell us what wing is. Yeah, we're also like 89 00:07:27.279 --> 00:07:30.959 learning how to talk about it, like as the project evolved, so it's 90 00:07:31.000 --> 00:07:35.600 probably you probably have a different It would be interesting to hear what you you 91 00:07:35.639 --> 00:07:43.800 know, I think that the way the way I'm thinking about it is so 92 00:07:43.920 --> 00:07:47.720 Yeah, spend some time at AWS, built the CDK, built some internal 93 00:07:47.759 --> 00:07:59.560 distributed systems at Amazon, and been constantly obsessed about developer experience and developer productivity 94 00:07:59.720 --> 00:08:03.839 and iteration speed because to me as a developer, that's like the most most 95 00:08:03.839 --> 00:08:11.959 important piece of like my my experience is my ability to iterate. And after 96 00:08:11.040 --> 00:08:15.959 leaving Amazon, I was like, okay, so it still feels crappy to 97 00:08:15.959 --> 00:08:18.879 build stuff on the cloud. For some reason, I mean, I love 98 00:08:18.920 --> 00:08:22.920 the CDK and I think like it's it took us many steps forward, but 99 00:08:22.000 --> 00:08:26.199 something didn't feel like we've really solved the problem. It's kind of I was 100 00:08:26.240 --> 00:08:30.959 thinking, well, the cloud is going to be here for fore you know, 101 00:08:31.040 --> 00:08:33.639 for the foreseeable future. We're going to continue to build stuff on this 102 00:08:33.679 --> 00:08:39.960 new kind of platform. But something is still a bit broken, and it 103 00:08:39.000 --> 00:08:46.200 took me some time to untangle, like what are the what are the big 104 00:08:46.279 --> 00:08:52.159 pains or where the kind of the root causes of the of those of those 105 00:08:52.360 --> 00:08:56.919 of this friction that we feel. I think like everybody I talked to kind 106 00:08:56.919 --> 00:09:01.639 of resonates with that friction. But no, I think like people perceive that 107 00:09:01.679 --> 00:09:07.320 it's coming from different uh, you know, from different reasons and and the 108 00:09:07.360 --> 00:09:11.600 way I am thinking about it, my perception of this is that there are 109 00:09:11.600 --> 00:09:18.679 two main problems. One is the fact that the developers, you know, 110 00:09:18.720 --> 00:09:24.799 when you're when you're looking at a system like the cloud, there are two 111 00:09:24.399 --> 00:09:30.399 engineering disciplines that are required in order to deliver something to the cloud. One 112 00:09:30.639 --> 00:09:35.120 is the infrastructure discipline or the DevOps discipline or the it ops or the system 113 00:09:35.200 --> 00:09:41.200 administration, and the other is the application developers. And as much as we 114 00:09:41.279 --> 00:09:46.639 would love a world where all applications developers would also be passionate about I P 115 00:09:48.360 --> 00:09:52.480 routing tables. And I think some of us are. I think some of 116 00:09:52.559 --> 00:09:56.519 us are, which is tantalizing somethings, because you know, I'm I'm one 117 00:09:56.559 --> 00:10:00.519 of those. And so for me, like having like a full understand of 118 00:10:00.600 --> 00:10:05.960 the stack is it's fun and I enjoy it. And I learned enjoyed learning 119 00:10:05.000 --> 00:10:11.639 how to configure vpcs and how to set up EC two instances. And but 120 00:10:11.919 --> 00:10:16.519 most application developers are focused and passionate about the problem domain that they're you know, 121 00:10:16.600 --> 00:10:22.080 solving for, which is usually the business problem domain or the customers of 122 00:10:22.120 --> 00:10:28.360 their business. And these are two different engineering domains in terms of like the 123 00:10:28.440 --> 00:10:33.639 problem space. And I think what I've seen with the CDK, and I 124 00:10:33.639 --> 00:10:37.759 think a little bit of the blind spot we had with the CDK, especially 125 00:10:37.759 --> 00:10:45.039 given Amazon's and Aws's engineering culture, which is very much on the kind of 126 00:10:45.120 --> 00:10:52.159 like full stack devop see you know, everybody, the side of the spectrum 127 00:10:52.639 --> 00:11:00.399 is that developers don't really want and are really struggling to understand all the mechanics 128 00:11:00.559 --> 00:11:05.720 of the of the cloud and and in reality, when you look at organizations 129 00:11:05.879 --> 00:11:09.399 they don't really want their developers to fully understand all the mechanics and the cloud. 130 00:11:11.000 --> 00:11:15.159 And so one of the problems that I've seen is that developers are not 131 00:11:15.320 --> 00:11:20.919 they don't have access to this new type of computer they they access in terms 132 00:11:20.960 --> 00:11:28.000 of like cognitive you know, cognitive barrier, learning barrier, and in some 133 00:11:28.120 --> 00:11:31.840 cases also like they're not allowed to touch the cloud, right, Like it's 134 00:11:31.879 --> 00:11:35.639 like, this is the develop scene, this is the platform stuff. You 135 00:11:35.879 --> 00:11:39.200 just do your container you know. I kind of I kind of sometimes think 136 00:11:39.200 --> 00:11:45.279 about it, like we've containerized the developers just put them in side, and 137 00:11:45.600 --> 00:11:48.799 this is the cloud. You don't worry about it. Just just write your 138 00:11:48.799 --> 00:11:52.639 code and the cloud is you don't have to care about it. And I 139 00:11:52.639 --> 00:12:00.320 think it's a shame because you know, the beauty of the cloud is infrastructure 140 00:12:00.519 --> 00:12:05.039 is the ability to leverage managed services to achieve your goals. And the more 141 00:12:05.799 --> 00:12:09.120 but the more you're leaning on that, on that, on that system, 142 00:12:09.159 --> 00:12:15.200 the more you're leaning on these services, uh, the less you give developers 143 00:12:15.200 --> 00:12:18.799 independence, and the less you give developers the ability to actually like iterate quickly 144 00:12:18.840 --> 00:12:24.240 and choose the right tools and understand how they're you know, leveraging this new 145 00:12:24.240 --> 00:12:31.120 type of technology. And so to me that was like the fundamental realization is 146 00:12:31.159 --> 00:12:37.320 that the gout that the cloud is not is not ready for developers in a 147 00:12:37.399 --> 00:12:41.639 sense. And and I think what we've seen is that, or what we're 148 00:12:41.679 --> 00:12:48.080 seeing is that organizations are trying to kind of again they containerize the developers. 149 00:12:48.120 --> 00:12:54.279 They create these like big platforms and complex workflows. And you know this HELM 150 00:12:54.440 --> 00:12:56.519 chart, So go and change this one line if you want to add an 151 00:12:56.559 --> 00:13:03.759 API endpoint, but you can't really test it because we need to deploy it 152 00:13:03.759 --> 00:13:05.279 on the cluster in order for you to actually see that it's working. But 153 00:13:05.320 --> 00:13:09.320 don't worry, it's going to be fine. And it's not fine sometimes And 154 00:13:09.399 --> 00:13:13.240 I think you guys know what I'm about, right, And so basically trying 155 00:13:13.279 --> 00:13:16.679 to solve this problem, right, Like it's like, how do we give 156 00:13:16.720 --> 00:13:22.759 developers access to this new type of computer? And it's a huge challenge, 157 00:13:22.799 --> 00:13:28.919 I feel, because I think what happened is that the cloud is you know, 158 00:13:28.960 --> 00:13:33.799 we've we've raced to the cloud in a sense and as an industry, 159 00:13:33.919 --> 00:13:39.799 and we've basically carried with us a lot of the tools and approaches that worked 160 00:13:39.799 --> 00:13:43.720 for us in the data center and in traditional computing that like the programming languages 161 00:13:43.759 --> 00:13:50.279 and the abstractions and the deployment systems, and and we ended up with like 162 00:13:50.960 --> 00:13:56.320 something that's not optimized for this type of platform, and so what have you 163 00:13:56.360 --> 00:14:01.320 know. What we've been doing with WING in the past few years is trying 164 00:14:01.360 --> 00:14:07.960 to distill how to how to address this pain uh. And I think like 165 00:14:07.039 --> 00:14:13.200 one of the kind of like maybe a bit of a recent coin drops I 166 00:14:13.279 --> 00:14:20.360 had or the recent kind of uh observations I had, was that the thing 167 00:14:20.399 --> 00:14:28.120 that we're missing is is an abstraction layer. Is this decoupling between application and 168 00:14:28.200 --> 00:14:35.679 platform that we have in traditional software and we've developed in traditional software, Like 169 00:14:35.039 --> 00:14:37.960 I used to write code in the nineties, and we didn't have that decoupling. 170 00:14:39.039 --> 00:14:41.200 I had to you know, I know which file system I'm using in 171 00:14:41.279 --> 00:14:45.840 order to write files, and I had to know how to you know, 172 00:14:46.000 --> 00:14:50.399 store create like TSR programs in order to do some memory you know background uh, 173 00:14:50.759 --> 00:14:56.519 you know stuff that truns in the background and like do sometime. And 174 00:14:56.559 --> 00:15:00.360 so again this is I loved I love this. I've always been a acted 175 00:15:00.399 --> 00:15:03.360 to this, but now today when you want to do these things, you 176 00:15:03.399 --> 00:15:05.879 really don't have to understand how your your platform works, right Like, you 177 00:15:05.919 --> 00:15:09.720 really don't have to know which filesystem you're using in most cases, and which 178 00:15:11.039 --> 00:15:15.759 even which operating system you're using, right Like, we have established a bunch 179 00:15:15.840 --> 00:15:22.679 of layers that allow developers to be effective on this platform called a computer, 180 00:15:22.960 --> 00:15:28.799 right computer that runs inside a machine. And and and my realization was that 181 00:15:28.960 --> 00:15:33.879 we need this layering for the cloud because without this layering, we keep bumping 182 00:15:33.919 --> 00:15:39.080 into each other, right Like, these disciplines keep keep the friction keeps happening. 183 00:15:39.039 --> 00:15:46.279 And what we've been doing with WING is basically we've established this abstract cloud 184 00:15:46.320 --> 00:15:52.000 API as a foundation for solving this problem. And I think there's a timing 185 00:15:52.039 --> 00:15:56.919 aspect to this, because the cloud as a as a you know, as 186 00:15:56.960 --> 00:16:03.120 a as a platform is is maturing over time. And we've and I believe 187 00:16:03.159 --> 00:16:10.440 we're at the state where we can identify the primitives and and even identifying them 188 00:16:10.559 --> 00:16:12.120 from the bottom. In a sense, it's not necessarily saying, you know, 189 00:16:12.320 --> 00:16:15.120 I'm going to be able to like give you all the primitives you ever 190 00:16:15.159 --> 00:16:21.360 need. It's basically saying, let's give you more primitives. I'll give you. 191 00:16:21.399 --> 00:16:26.000 I'll give you an example, what I mean about this, you know 192 00:16:26.039 --> 00:16:30.720 what let me So the basically what I'm trying to say is that it's it's 193 00:16:30.759 --> 00:16:34.919 pretty safe. There are some primitives that we know that are very valuable. 194 00:16:36.240 --> 00:16:40.240 But for example, a container, right, being able to execute a container, 195 00:16:40.320 --> 00:16:42.399 run a container, you know, in a scalable way. And I 196 00:16:42.440 --> 00:16:48.320 think Kubernetes said basically said, yeah, here's here's your primitive. And it's 197 00:16:48.360 --> 00:16:52.480 been very very successful in exactly that, right, Like it's basically saying, 198 00:16:52.480 --> 00:16:56.759 if you need to run containers, Kubernetes gives you exactly this abstraction that you 199 00:16:56.840 --> 00:17:03.319 need. And it's because super successful because it was able to identify this one 200 00:17:03.400 --> 00:17:11.720 primitive, uh that that can hold an application on the cloud. But in 201 00:17:11.720 --> 00:17:15.920 my mind, it's it's very low level, and it's it still means that 202 00:17:15.960 --> 00:17:18.680 you're not leverage you're not really able to leverage the cloud, right, Like 203 00:17:18.720 --> 00:17:25.160 you're leveraging VMS maybe, right, which is super powerful, super valuable. 204 00:17:25.160 --> 00:17:27.880 But again, if you need if you need storage, for example, then 205 00:17:30.039 --> 00:17:34.000 okay, go manage hard drives and memory manage and and you know, scale 206 00:17:34.039 --> 00:17:40.839 your volumes and back up and replication and like, but hey, guys, 207 00:17:40.880 --> 00:17:45.960 there's like a thousand people team at Amazon that's managing object storage and S three, 208 00:17:45.519 --> 00:17:48.519 maybe we can use this service and then instead of doing this ourselves, 209 00:17:48.599 --> 00:17:53.960 right, And so even just saying let's take object storage as another primitive, 210 00:17:55.359 --> 00:17:59.319 it's pretty ubiquitous. It exists in every cloud, every cloud provider. It 211 00:17:59.440 --> 00:18:03.359 even as a self hosted Kubernetes you know, solution if you need it. 212 00:18:04.200 --> 00:18:08.920 And let's define the abstraction layer of this, of this idea called a bucket 213 00:18:10.000 --> 00:18:12.279 or object store. And I think we know how to do this. I 214 00:18:12.279 --> 00:18:17.079 think, like you know, anybody can pretty much define, Okay, we 215 00:18:17.119 --> 00:18:21.160 need to be able to put files and get files and download and download multi 216 00:18:21.160 --> 00:18:26.880 part downloads and uploads and mind types and this there's a surface area that's pretty 217 00:18:26.920 --> 00:18:33.039 easy to identify and say, even just adding this one primitive to your toolbox 218 00:18:33.240 --> 00:18:40.960 of abstract cloud primitives can really help. Right. I've talked to many people 219 00:18:41.000 --> 00:18:45.400 and because that especially people who use Kubernetes that are kind of like, we're 220 00:18:45.440 --> 00:18:51.119 worried about taking too much dependency on their cloud provider, but they still have 221 00:18:51.160 --> 00:18:56.240 a bucket, right, Like they still need a bucket, which is anecdotally 222 00:18:56.279 --> 00:19:00.279 it's actually as is first service, right like atabus is first service. That's 223 00:19:00.279 --> 00:19:04.440 three. So taking step by step basically saying, okay, let's let's talk 224 00:19:04.440 --> 00:19:10.720 about object store and define this abstract API and start building our applications on top 225 00:19:10.759 --> 00:19:15.279 of this abstract API, which is decoupled from the you know, concrete implementation. 226 00:19:15.240 --> 00:19:22.480 Again, super simple exercise, not super hard to do. And the 227 00:19:22.519 --> 00:19:26.279 other thing that we're doing with Wing is we're actually doing we're actually audi also 228 00:19:26.680 --> 00:19:33.279 providing a simulator implementation for those for those resources, because again, if I 229 00:19:33.359 --> 00:19:37.160 define the contract for a bucket, pull, get lists, whatever, it's 230 00:19:37.160 --> 00:19:41.000 pretty easy to implement it locally. It's obviously not highly available and replicate it 231 00:19:41.039 --> 00:19:45.799 and all that stuff, but like from a functional perspective, I can actually 232 00:19:45.839 --> 00:19:49.559 test my application now and I can iterate. And so this is basically the 233 00:19:49.599 --> 00:19:53.559 exercise that we've started doing. It's like, okay, let's take buckets and 234 00:19:53.640 --> 00:20:04.200 queues and topics and static websites and and secrets and basically slowly kind of like 235 00:20:04.480 --> 00:20:10.440 adding more tools to the arsenal of tools that you that are the foundation. 236 00:20:10.599 --> 00:20:17.240 They are the standard library in a sense of the cloud. And let me 237 00:20:17.319 --> 00:20:22.559 let me pause you right there. So so if I'm following you correctly, 238 00:20:22.680 --> 00:20:30.559 you're thinking about application development in terms of just the primitives as far as like 239 00:20:30.599 --> 00:20:34.240 Okay, I need compute, I need file storage, I need database, 240 00:20:34.480 --> 00:20:41.079 and so instead of forcing the application developers to think about the individual characteristics of 241 00:20:41.119 --> 00:20:48.319 those because of the chosen provider, just abstracting that away to say, look, 242 00:20:49.000 --> 00:20:53.640 you need file storage, Okay, here's here's the interface for putting files. 243 00:20:53.680 --> 00:20:59.559 Here's the interface for getting files. How that happens because you're using ABS 244 00:20:59.720 --> 00:21:06.240 or g CP or NetApp or whatever doesn't matter, right, am I following? 245 00:21:06.240 --> 00:21:10.559 You're right? Yeah, yeah, exactly right. And I think like 246 00:21:10.759 --> 00:21:14.200 the heavy lifting that we're doing on our side is testing, right. It's 247 00:21:14.240 --> 00:21:17.599 basically saying, oh, here's an implantation for a WS, here's an inflation 248 00:21:17.960 --> 00:21:22.279 implantation, or azure, here's an implementation for the simulator. It's heavy lifting 249 00:21:22.319 --> 00:21:27.279 because I can't expect every platform team across the industry to actually do all this 250 00:21:27.400 --> 00:21:32.319 heavy lifting across you know, multiple resources, across all the different types of 251 00:21:32.359 --> 00:21:36.359 cloud providers. And obviously we're doing this with the community. It's like an 252 00:21:36.400 --> 00:21:41.759 open source project, and so we start to see people fill up, you 253 00:21:41.759 --> 00:21:48.039 know, fill up little little boxes in this matrix of compatibility and the thing 254 00:21:48.079 --> 00:21:52.799 that this does in terms of solving the original problem. There are two things. 255 00:21:52.839 --> 00:22:00.920 Basically, one is a higher level API which is in it, which 256 00:22:00.960 --> 00:22:06.119 is based on the mental model of the application and not on the mental model 257 00:22:06.119 --> 00:22:10.839 of the infrastructure. And because when the developer uses a bucket, they they 258 00:22:10.960 --> 00:22:17.519 understand the the semantics of this the function, the functional semantics of this of 259 00:22:17.559 --> 00:22:21.119 this resource even today right like when they're using S three, they understand, 260 00:22:21.119 --> 00:22:26.759 okay, so I'm putting objects on this service. And there's some constraints related 261 00:22:26.759 --> 00:22:30.319 to the fact that it's a distributed system. Like all those things are easy 262 00:22:30.359 --> 00:22:33.680 for developers to understand, they're not that that's not the hard part. The 263 00:22:33.799 --> 00:22:40.400 non functional aspects of the of the of the of the bucket. Uh wing 264 00:22:40.519 --> 00:22:45.319 actually has this like pluggable customizable back end model, and so we provide some 265 00:22:45.400 --> 00:22:51.799 default implementation, but then platform teams can actually like customize that default implementation and 266 00:22:51.839 --> 00:22:56.960 provide their own implementation or you know, a customized implementation of our of our 267 00:22:57.039 --> 00:23:03.079 bucket. And so for example, we have this customer who it's actually a 268 00:23:03.079 --> 00:23:07.839 really cool example, like we have this uh resource called API, which is 269 00:23:08.079 --> 00:23:15.519 sorry, which is basically so we have this resource called API which is basically 270 00:23:15.559 --> 00:23:18.400 an API gateway, so you can specify routes and then you can specify the 271 00:23:18.440 --> 00:23:22.920 handlers, you know, how how how the each route, how you respond 272 00:23:22.960 --> 00:23:26.440 to each route. And our default implementation at the time for the time being 273 00:23:26.559 --> 00:23:33.480 is using infre w S, is using API gateway and lambda functions because it's 274 00:23:33.519 --> 00:23:37.960 the it's the simplest implementation to get started with. And we have a customer 275 00:23:38.240 --> 00:23:41.640 who basically said, well, we were not allowed to use API gateway because 276 00:23:42.039 --> 00:23:47.960 you know, some compliance security, you know, some financial institute, and 277 00:23:47.960 --> 00:23:53.480 and they created an implementation of this API resource that uses load balancer and a 278 00:23:53.559 --> 00:24:00.440 monolithic container right behind the scenes, and you didn't have to change to anything 279 00:24:00.480 --> 00:24:03.400 about the programming model. Like from the developers perspective, they just specify the 280 00:24:03.480 --> 00:24:07.839 bunch of routes and a bunch of handlers, and and the way that these 281 00:24:07.839 --> 00:24:14.119 guys are going to be deployed in that with this particular cloud environment is using 282 00:24:14.599 --> 00:24:18.279 you know, a load balancer and a long runnings container. Great, and 283 00:24:18.319 --> 00:24:22.680 so I think this de coupling offers both the application the developers the ability to 284 00:24:22.720 --> 00:24:27.759 actually understand what they're doing, right, Like it's not just like change this 285 00:24:27.880 --> 00:24:33.599 one line here this terre form and yeah, it's it's HCl, it's this 286 00:24:33.759 --> 00:24:37.880 thing. Don't worry about it, it's it's now. Like talking in their 287 00:24:37.000 --> 00:24:42.319 language also gives the platform teams and develops teams the ability to focus on their 288 00:24:42.880 --> 00:24:48.720 responsibility, because it's not like we're saying there's no need for develops or there's 289 00:24:48.759 --> 00:24:52.160 no need for you know, people who are experts in on the on the 290 00:24:52.160 --> 00:24:56.839 problem domain of the infrastructure and the problem domain of the the of the system. 291 00:24:57.000 --> 00:25:03.559 It's always been needed, right for software. So that's why sure. 292 00:25:03.119 --> 00:25:07.480 And then the second side is like the simulation, which I think is really 293 00:25:07.279 --> 00:25:12.400 shifting the developer experience to to the left in the sense it's like the cloud 294 00:25:12.480 --> 00:25:15.480 is not that you don't need the cloud in the loop when you're iterating, 295 00:25:15.519 --> 00:25:21.480 which is and probably don't want it there even if it is in the loop. 296 00:25:22.039 --> 00:25:26.079 Yeah, I mean, I think developers are really spoiled and legitimately so 297 00:25:26.319 --> 00:25:29.519 right, Like they want to work on their ID, they want their debugger. 298 00:25:30.519 --> 00:25:33.920 This is their you know, this is their craft, right Like their 299 00:25:33.960 --> 00:25:37.599 craft is like to change some code and check that it's working, and change 300 00:25:37.640 --> 00:25:38.920 it again, and check again and change again, and then then write a 301 00:25:38.920 --> 00:25:42.240 little unit test, and like you want to be able to do these iterations 302 00:25:42.279 --> 00:25:45.839 really really quickly, and even if it takes like thirty seconds or a minute, 303 00:25:47.400 --> 00:25:52.720 it's too long, at least in my my standards. You said, 304 00:25:52.759 --> 00:25:55.519 you said a bunch of really interesting things there, and I feel like there's 305 00:25:55.599 --> 00:25:59.079 a there's three that really come to mind, and the first one is there's 306 00:25:59.119 --> 00:26:02.920 an aspect of the container world, which I think you know started with Docker 307 00:26:03.119 --> 00:26:06.960 than Kubernetes, that has really failed us. It just the interface that you 308 00:26:07.000 --> 00:26:11.000 have to understand in order to deploy your technology in one of these environments requires 309 00:26:11.240 --> 00:26:12.839 I mean, it's better than it was. It took the interface that we 310 00:26:12.920 --> 00:26:15.920 had, which was the operating system, and sort of adjusted it by like 311 00:26:15.960 --> 00:26:19.160 say, ninety degree angle. It's still the same, it's still the same 312 00:26:19.160 --> 00:26:22.799 thing in a lot of ways, but maybe there is more consistency in what 313 00:26:22.880 --> 00:26:26.839 we're getting. And I feel like that's that's in a way something that we 314 00:26:27.000 --> 00:26:32.079 lost. We had the DevOps movement. Everything's supposed to be under one roof, 315 00:26:32.079 --> 00:26:34.880 everything's supposed to be understood together, and if anything, we didn't achieve 316 00:26:34.920 --> 00:26:38.079 that. We didn't get in that direction with the tools. We just you 317 00:26:38.079 --> 00:26:41.119 know said, oh yeah, you know, we have the mindset, and 318 00:26:41.160 --> 00:26:44.079 I feel like this is an opportunity. You start talking about primitives here that 319 00:26:44.160 --> 00:26:47.839 we actually need, and I feel like that's where AWS was really successful compared 320 00:26:47.839 --> 00:26:51.200 to the other cloud providers. You start out with S three. A huge 321 00:26:51.200 --> 00:26:53.880 release was Lambda successfully in an API gateway. I mean, these to me 322 00:26:53.960 --> 00:26:57.319 are the primitives that you're even talking about, and they that's where the success 323 00:26:57.319 --> 00:27:00.960 came from. Everything else is like, you know, what is that even? 324 00:27:00.680 --> 00:27:04.240 And if we take it another step further, we can see companies like 325 00:27:04.279 --> 00:27:10.599 render or Netlify versl that are trying to create an abstraction layer on top of 326 00:27:10.640 --> 00:27:11.880 the cloud to make it simpler. But I feel like it's you know, 327 00:27:11.920 --> 00:27:15.319 almost what we're saying is it's two opinion based, right. You're losing the 328 00:27:15.400 --> 00:27:21.400 aspect of how to deliver value from the underlying resources that are there, blockstore, 329 00:27:21.400 --> 00:27:25.440 et cetera. By offering a two opinion needed answer, like if you 330 00:27:25.480 --> 00:27:27.680 need to dive down, you can't get that. So both early on we 331 00:27:27.960 --> 00:27:33.200 didn't succeed because we didn't figure out what the primitives were, and we also 332 00:27:33.240 --> 00:27:37.400 have two over opinionated platforms. It'd be great if we could redefine what that 333 00:27:37.599 --> 00:27:41.160 real interfaces at the platform level, at the cloud provider level, so that 334 00:27:41.599 --> 00:27:44.519 what you need at the application makes sense. I mean, even Lambda, 335 00:27:44.839 --> 00:27:48.480 you have to know that you're using Lambda in aws in order to deploy your 336 00:27:48.559 --> 00:27:52.039 software. Right, you can't just be like I don't want to think about 337 00:27:52.039 --> 00:27:56.079 this in go to town. Early alternative as containers today. Yeah, absolutely 338 00:27:56.160 --> 00:28:02.279 agree. I think I think the vertical the vertical platforms like Heroku, you 339 00:28:02.319 --> 00:28:07.240 know, ver Cell render uh, you know, they're able to create a 340 00:28:07.279 --> 00:28:11.799 really great developer experience by completely narrowing down the surface area and saying, Okay, 341 00:28:11.799 --> 00:28:15.559 we're just going to give you the ability to you know, deploy websites 342 00:28:15.640 --> 00:28:18.839 or to deploy containerized the applications. And in that sense, it's it's great, 343 00:28:18.960 --> 00:28:23.000 it's solving it's solving the problem right in that sense because for those use 344 00:28:23.039 --> 00:28:27.400 case you really get an amazing experience. Well, what we're trying to do 345 00:28:27.480 --> 00:28:30.599 with Wing is we're trying to actually create like a general purpose solution, not 346 00:28:30.680 --> 00:28:37.279 necessarily a vertically integrated solution, but more of like like any any you know, 347 00:28:37.319 --> 00:28:41.559 programming environment where you're able to actually pick and choose which tools you want 348 00:28:41.559 --> 00:28:48.160 to use for your solution, and we are actually working on a delivery experience 349 00:28:48.599 --> 00:28:55.240 there will be very similar to what Render offers and verseell offers, but works 350 00:28:55.279 --> 00:28:59.839 on top of this foundation, so it's not limited to you know, just 351 00:29:00.119 --> 00:29:08.720 delivering websites or containers. It almost makes me think of like an infrastructure approach 352 00:29:08.880 --> 00:29:14.079 implemented with Go interfaces, you know, because if you have a Go interface, 353 00:29:14.519 --> 00:29:21.440 you can swap out anything that matches those same interface, the same interface 354 00:29:21.440 --> 00:29:26.319 specification, so underneath, you know, if you're if you're logging provider matches 355 00:29:26.319 --> 00:29:29.440 the interface and you want to swap that out, you can just swap it 356 00:29:29.680 --> 00:29:33.200 and there's no there's no impact that no one knows the difference except for the 357 00:29:33.200 --> 00:29:40.839 people who are required to maintain that, and you're it sounds like you're taking 358 00:29:40.880 --> 00:29:44.799 that to an infrastructure approach. You know, if you need a storage bucket, 359 00:29:45.200 --> 00:29:48.440 here's the interface for it, and who the actual provider that is doesn't 360 00:29:48.440 --> 00:29:52.720 matter. You can swap it out daily if that's what makes you happy. 361 00:29:53.480 --> 00:29:57.839 As long as it matches the interface, you're good to get the buckets. 362 00:29:57.880 --> 00:30:02.400 You have to also move all the across Oh you're not, You're not going 363 00:30:02.440 --> 00:30:07.000 to handle that part automatic, and that's that's the support teams problem. That 364 00:30:07.119 --> 00:30:11.880 line, I think that's a very apt uh, you know, very aware 365 00:30:12.000 --> 00:30:15.839 of the problem. I mean, just for those that haven't used GO versus 366 00:30:15.920 --> 00:30:19.640 other compiled languages, you normally you have to define the inner the interface. 367 00:30:19.720 --> 00:30:23.279 Is that a class implements you know, not just here are the methods, 368 00:30:23.279 --> 00:30:26.880 but explicitly that it implements an interface, and then go. You actually don't 369 00:30:26.920 --> 00:30:32.440 have to define the interface in order to pass an object around and injecting as 370 00:30:32.480 --> 00:30:34.920 long as all the properties of that class actually match. So, I mean, 371 00:30:36.000 --> 00:30:41.480 I think that's that's spot on realistically here. Yeah, there are many 372 00:30:41.599 --> 00:30:48.839 versions of this, I think in software design and dependency injection is like something 373 00:30:48.880 --> 00:30:55.599 that exists in almost every programming environment and and and it's at the heart of 374 00:30:55.640 --> 00:30:59.279 what we're doing, right, Like you're able to basically inject the dependency and 375 00:30:59.319 --> 00:31:02.119 say, okay, in the case I want to use, uh, my 376 00:31:02.240 --> 00:31:07.720 bucket instead of of the standard bucket. Yeah, I agree. I think 377 00:31:07.960 --> 00:31:10.920 I think we know how to do this as a as a you know, 378 00:31:11.759 --> 00:31:15.920 you know, as an industry. It's not we're not inventing the wheel in 379 00:31:15.920 --> 00:31:22.680 the sense of like new, completely new uh design paradigms. But but I 380 00:31:22.720 --> 00:31:30.599 think like there's a I think like I think you know there is you know 381 00:31:30.880 --> 00:31:37.519 there is a there's there. They're going and doing it right, like going 382 00:31:37.519 --> 00:31:41.000 and going and saying this is the API that we think is the right a 383 00:31:41.119 --> 00:31:47.599 PI. That's a really big challenge because designing good a PI is is is 384 00:31:47.640 --> 00:31:51.319 an art and science problem of thing right, like and and and this is 385 00:31:51.400 --> 00:31:55.319 one of the reasons we're doing this as an open source project because we believe 386 00:31:55.400 --> 00:32:00.200 that this is something that needs to be baked with the community, baked with 387 00:32:00.480 --> 00:32:06.319 use cases, baked with the real world. We don't have the oracle and 388 00:32:06.920 --> 00:32:08.880 knowledge of like exactly how to do this, and so I think like doing 389 00:32:08.880 --> 00:32:14.960 this in the open and collaboratively is the right way to do something like that 390 00:32:15.039 --> 00:32:19.720 for sure. And you've been working on us for a couple of years now, 391 00:32:19.799 --> 00:32:25.000 is that right? Yeah? Cool? How has how's the community support 392 00:32:25.279 --> 00:32:29.359 been from that? Because like with with open source projects, you know, 393 00:32:29.440 --> 00:32:36.000 that's I think that's the challenge is like getting people to make it a two 394 00:32:36.079 --> 00:32:40.359 way conversation. How has that experience been for you? It's been amazing, 395 00:32:40.480 --> 00:32:45.079 to be honest, I feel like I feel I learned a lot from my 396 00:32:45.160 --> 00:32:51.559 experience, you know, building the CDK and kind of like being not in 397 00:32:51.559 --> 00:32:55.119 a way a bit not very intentional about the community that's built around the CDK, 398 00:32:55.240 --> 00:33:01.559 but observing the organic kind of evolution of it, and then coming into 399 00:33:01.799 --> 00:33:07.200 Wing was like, Okay, I kind of know what are the important things 400 00:33:07.240 --> 00:33:13.119 about creating a community like that, And we've really made a lot of effort 401 00:33:13.200 --> 00:33:16.079 to kind of put that in place very early in the project, and it 402 00:33:16.119 --> 00:33:21.599 really pays off, right like the fact that I feel like I feel Wing 403 00:33:21.720 --> 00:33:24.759 is a really really great project to contribute to, and I'm not saying that, 404 00:33:25.240 --> 00:33:29.440 I really do think it's just a good experience as a contributor, right, 405 00:33:29.519 --> 00:33:34.559 Like, you have a really good, really reasonable documentation, definitely always 406 00:33:34.559 --> 00:33:39.319 have, always can improve the documentation with reasonable documentation, the build environment and 407 00:33:39.359 --> 00:33:45.559 the development environment is is is pretty easy to use, and it's a pretty 408 00:33:45.599 --> 00:33:49.839 complex project. So you know, being able to actually like get that right 409 00:33:49.839 --> 00:33:54.759 as took us quite a lot of iterations. We're trying to be very responsive. 410 00:33:54.839 --> 00:34:00.000 The community is very welcoming and very helpful, and we public goods first 411 00:34:00.039 --> 00:34:05.359 issues and there's a bunch of things that you can do that even things like 412 00:34:05.480 --> 00:34:13.480 I'll just give you an acdotal example. Uh, there's this to two really 413 00:34:13.679 --> 00:34:17.000 simple things that that you can do to really improve the experience of contributors. 414 00:34:17.519 --> 00:34:22.199 One is, whenever someone submits a pull request, send them a note, 415 00:34:22.559 --> 00:34:27.840 you know, send them a comment, acknowledge that there's someone on the other 416 00:34:27.880 --> 00:34:30.760 side. That's like it's a it's a dopamine rush, right, Like it's 417 00:34:30.760 --> 00:34:35.599 like, oh, sure, someone that saw me right, saw that I'm 418 00:34:36.000 --> 00:34:39.199 that I'm here. And then the other one is that once the feature that 419 00:34:39.280 --> 00:34:45.360 they or the fix that they contributed was released, add a comment to the 420 00:34:45.360 --> 00:34:50.519 pool request that says this was released in the version of V and and just 421 00:34:50.559 --> 00:34:58.119 getting that like closing the cycle and giving people the acknowledgment that what they've contributed 422 00:34:58.239 --> 00:35:05.280 is now a public release and everybody can use it is really gratifying for contributors. 423 00:35:05.280 --> 00:35:07.519 I can say that as you know, from from firsthand experience, right 424 00:35:07.519 --> 00:35:12.679 like for me when I'm contributing. And so these two things can be pretty 425 00:35:12.760 --> 00:35:16.519 much automated, right Like you really don't have to be super It doesn't require 426 00:35:16.519 --> 00:35:20.960 a lot of efforts, but it does require intention to to put them in 427 00:35:20.960 --> 00:35:22.840 place. And once you put them in place like even for me when I'm 428 00:35:23.320 --> 00:35:28.159 I'm submitting pr to our repo and I get this little note that says it 429 00:35:28.239 --> 00:35:32.599 was released and version of x y Z, it just feels good for sure. 430 00:35:32.639 --> 00:35:39.480 That's that's something that I think is worth acknowledging and mentioning, you know, 431 00:35:39.519 --> 00:35:46.000 because that's the people side of writing goods software and it's something that we 432 00:35:46.000 --> 00:35:52.719 we can easily get defocused from. You know that there are people at the 433 00:35:52.760 --> 00:35:54.679 other end of this, and so I think that's super cool to just acknowledge 434 00:35:54.719 --> 00:36:00.320 them. And you're right, it's a it's a dopamine hit. Yeah, 435 00:36:00.000 --> 00:36:02.760 I mean you you can look at it. Actually two from it just a 436 00:36:02.800 --> 00:36:08.000 statistical value driven standpoint, Your software isn't delivering value or the changes that you 437 00:36:08.079 --> 00:36:13.079 make until someone's using it. And if they don't know that the changes that 438 00:36:13.159 --> 00:36:15.480 you're deployed you've worked so hard to get out, you know, aren't there 439 00:36:15.599 --> 00:36:19.639 or you know what they've done. There are so many open source projects that 440 00:36:20.119 --> 00:36:22.400 you don't know when it's going to be released after you put in a polear 441 00:36:22.480 --> 00:36:25.880 quest. I mean my strategy now is first I start with the issue. 442 00:36:25.960 --> 00:36:29.840 I'd be like, this is a problem. Is someone like if I submit 443 00:36:29.880 --> 00:36:34.039 a pole request, will it get merged? Yeah? And ninety nine percent 444 00:36:34.079 --> 00:36:37.920 of the time I never hear back. There is like sometimes I hear back 445 00:36:37.920 --> 00:36:44.360 within six months, which is just so ridiculous to me. Frequently I hear 446 00:36:44.400 --> 00:36:49.719 back with that baby agile. Agile is thirty days. I hear back from 447 00:36:49.760 --> 00:36:52.320 their box saying, no one's meant put a comment on this for thirty days. 448 00:36:52.880 --> 00:36:58.960 We're going to close it automatically. I'm like, thank you, yeah 449 00:36:59.079 --> 00:37:00.559 and again. And I think, like we can. I think we can. 450 00:37:00.559 --> 00:37:05.400 Definitely there's things we can improve, but at least we were trying to 451 00:37:05.400 --> 00:37:09.360 be intentional about those things. I mean, I remember uh from the CDK 452 00:37:09.519 --> 00:37:15.519 at some point. It is really hard to maintain a big open source project. 453 00:37:16.159 --> 00:37:22.800 And once one of the problems with this is is that there's an asymmetry 454 00:37:23.239 --> 00:37:28.760 between the capacity you have with the team, with the core team, which 455 00:37:28.800 --> 00:37:31.159 is usually a fixed size or you know, maybe growing a little bit every 456 00:37:31.199 --> 00:37:37.519 year, and and and the user base, which is sometimes exponentially growing or 457 00:37:37.559 --> 00:37:40.800 sometimes growing like crazy, and the contribute and the contributor base as well. 458 00:37:42.719 --> 00:37:50.960 And if you don't have automation, if you don't have like really great workflows 459 00:37:51.000 --> 00:37:55.719 for like accepting contributions and dealing with them. It's just immediately, very quickly 460 00:37:55.760 --> 00:38:00.599 gets you overwhelming for the for the core team, and the CDK had like 461 00:38:01.519 --> 00:38:06.800 still I think really struggling with this because you know, anyways just keeps growing. 462 00:38:06.880 --> 00:38:10.000 There's like more and more services, more and more capabilities. The CDK 463 00:38:10.199 --> 00:38:15.679 definitely is perfect for contribution in that sense. It's like, oh, yeah, 464 00:38:15.840 --> 00:38:17.400 just they eded this new feature in Lambdough, let's just expose it in 465 00:38:17.440 --> 00:38:22.199 the CDK. So it's like these are really simple contributions and so people can 466 00:38:22.440 --> 00:38:27.119 can really participate, but you need someone to review this, you need someone 467 00:38:27.159 --> 00:38:30.039 to accept it, you need someone to and so it's it's a challenge. 468 00:38:30.079 --> 00:38:37.440 It's a big challenge with big projects. So definitely I can also you know, 469 00:38:37.719 --> 00:38:40.280 I can also be empathetic to the other side in that sense. That's 470 00:38:40.320 --> 00:38:45.960 what I'm trying to say. Yeah, for sure, so and now and 471 00:38:45.719 --> 00:38:51.880 so with weing, you've got that problem, but also with the other cloud 472 00:38:51.920 --> 00:38:55.719 providers as well, because you are supporting all the different cloud providers, right 473 00:38:55.920 --> 00:38:59.119 right, I guess we can't say all because I don't even know what all 474 00:38:59.400 --> 00:39:06.280 really. Someone someone who said the cloud flare back, right, which is 475 00:39:07.199 --> 00:39:10.119 oh, yeah, right, Uh, they seem to have all the primitives 476 00:39:10.159 --> 00:39:15.679 we need now to build the standard library. Yeah, and we don't. 477 00:39:15.719 --> 00:39:17.960 We don't. We also don't have full support for all all the kind of 478 00:39:19.079 --> 00:39:22.840 traditional providers. As I said, it's kind of like a matrix that we're 479 00:39:22.840 --> 00:39:28.719 filling up. We have the foundation for testing everything, which is really important. 480 00:39:28.760 --> 00:39:31.159 So like if you fill up something, it goes into the goes into 481 00:39:31.159 --> 00:39:35.599 the factory and starts, you know, and we start testing it every time 482 00:39:35.639 --> 00:39:43.000 you every time there's a change. And it's interesting to think about the cloud 483 00:39:43.039 --> 00:39:49.920 agnostic problem, which is I haven't mentioned it actually but in a way not 484 00:39:50.000 --> 00:39:52.159 in a way, but we also solve that problem, right like because once 485 00:39:52.199 --> 00:39:57.480 you work against the substraction, then suddenly you're not you're portable. Your application 486 00:39:57.559 --> 00:40:00.679 can be ported across different implementation. Like you said, I can change the 487 00:40:00.719 --> 00:40:05.920 bucket, I can change the cloud provider. And and I've been talking to 488 00:40:06.079 --> 00:40:09.480 like tons of you know, people from the industry in the past two years, 489 00:40:09.519 --> 00:40:15.400 and this is a growing pain. It feels like I've seen more and 490 00:40:15.480 --> 00:40:22.679 more people concerned about portability, both from a cost perspective. Just talk to 491 00:40:22.519 --> 00:40:27.039 someone yesterday and they mentioned you know, they've been an AA base shop for 492 00:40:27.199 --> 00:40:30.639 many years and at some point just became really expensive and Atabase was wouldn't you 493 00:40:30.679 --> 00:40:34.679 know, wouldn't give them any discounts, And so they said, Okay, 494 00:40:35.000 --> 00:40:38.280 we're gonna move some of our workloads to GCP or to AZURE. I think 495 00:40:38.280 --> 00:40:43.400 I don't remember what it was, but just just just pointing out that I 496 00:40:43.440 --> 00:40:47.159 think, like, as the cloud is evolving and people have bigger workloads and 497 00:40:47.199 --> 00:40:53.880 more stakes than the fact that the power is in the hands of the vendor 498 00:40:53.880 --> 00:40:59.920 as opposed as opposed to being in the hands of the of the user is 499 00:41:00.599 --> 00:41:04.559 I feel like it's not it's not the good. It's not good for the 500 00:41:04.559 --> 00:41:08.039 industry eventually, right, Like it's not good for anyone, and Wing is 501 00:41:08.039 --> 00:41:15.760 solving that problem again still early, still have a lot of work to do, 502 00:41:15.800 --> 00:41:20.079 but like at least from at least uh, you know, architecturally, 503 00:41:20.159 --> 00:41:23.239 this is a solution to this problem. And I'm seeing more and more people 504 00:41:23.480 --> 00:41:30.320 talk about this. I think the other the other anecdotally like weren't like kind 505 00:41:30.320 --> 00:41:35.320 of related to what you asked earlier. I'm seeing a lot more vendors wanting 506 00:41:35.320 --> 00:41:42.320 to support self hosted solutions because of those concerns about you know, data where 507 00:41:42.320 --> 00:41:45.159 the data is stored and going out of your account, and and so in 508 00:41:45.239 --> 00:41:50.880 those examples are like they're not they're not SaaS providers. They are vendors that 509 00:41:51.239 --> 00:41:54.599 create services, but they want to be able to deploy them in customer accounts 510 00:41:54.920 --> 00:42:01.840 across different cloud providers. And right now, the only reasonable solution, which 511 00:42:01.880 --> 00:42:06.199 is which you know, I don't actually think it's like a fully it's not 512 00:42:06.320 --> 00:42:13.079 real in a sense, it's to use pure Kubernetes, right And the reality 513 00:42:13.079 --> 00:42:15.960 of that is actually pretty harsh because first of all, you're really limited in 514 00:42:16.039 --> 00:42:21.320 terms of like the resources that you can use outside of your Kubernetes cluster. 515 00:42:21.400 --> 00:42:23.480 So once you start you need a bucket. Then okay, we need this 516 00:42:23.639 --> 00:42:30.760 abstraction again. And two is Kubernetes, as much as we wanted to think 517 00:42:30.800 --> 00:42:37.360 about it as like cloud agnostic and portable, and the reality is that the 518 00:42:37.440 --> 00:42:42.559 distributions are very different. The versioning are very are different, vms are different, 519 00:42:42.599 --> 00:42:46.599 the VM types are different, the volumes are different, the managed you 520 00:42:46.639 --> 00:42:51.559 know, Kubernetes solutions are different, and so you end up having to like 521 00:42:51.639 --> 00:42:55.639 actually test yes this works with the GCP Kubernetes, and with the abase Kubernetes, 522 00:42:55.639 --> 00:43:00.400 and and so even this is not truly so the only portable thing in 523 00:43:00.440 --> 00:43:05.360 this world is the container in a way, or you know, your application 524 00:43:05.960 --> 00:43:09.199 that's running inside Kubernetes, which is a bit unfortunate, I feel, because 525 00:43:09.599 --> 00:43:15.119 I know that a lot of people are using Kubernetes with the sense of cloud 526 00:43:15.159 --> 00:43:17.000 portability, and then when when they actually need it, it's, uh, 527 00:43:17.440 --> 00:43:23.000 it's much harder than than they expect. For sure, because you dhorn I 528 00:43:23.039 --> 00:43:27.360 would say, you heard it here first, are using Kubernetes for cloud portability. 529 00:43:27.400 --> 00:43:31.199 Stop it. You're you're not getting the value out for sure. It's 530 00:43:31.280 --> 00:43:36.199 been a it's been a slow transition like that, you know, because as 531 00:43:36.280 --> 00:43:43.280 Kubernetes has matured, you see like little things that steer you towards a cloud 532 00:43:43.719 --> 00:43:49.239 agnostic or a cloud specific solution. Like whenever you set up your ingress for 533 00:43:50.679 --> 00:43:54.480 for your service, if you're in GCEP, you know, you use one 534 00:43:54.519 --> 00:43:58.760 type of ingress, or if you're using uh, you know, the the 535 00:43:58.800 --> 00:44:00.920 Amazon managed kuberne As, you'll use a different ingress and then you try to 536 00:44:00.960 --> 00:44:05.559 move it to a different Kubernetes cluster and you're like, oh damn it, 537 00:44:06.800 --> 00:44:10.559 I've screwed. Yeah, and then you end up with like overlays and tim 538 00:44:10.679 --> 00:44:19.119 plates and patching and taint different taints, and I don't I don't even know 539 00:44:19.199 --> 00:44:24.639 all the but I just wanted to make sure that I think Kubernetes is a 540 00:44:24.679 --> 00:44:31.039 really great and powerful tool I have. I think that oftentimes people use it 541 00:44:31.480 --> 00:44:38.400 without really needing all this power and these capabilities. And oftentimes people use it 542 00:44:38.440 --> 00:44:43.239 because they think that they're not going to be locked to a cloud provider. 543 00:44:43.280 --> 00:44:46.840 But that's not really. But but there are I've seen amazing use cases of 544 00:44:46.880 --> 00:44:50.280 Kubernetes, and I think, like, you know, definitely, by the 545 00:44:50.280 --> 00:44:55.480 way, people who need like on prem container orchestration right amazing, right, 546 00:44:55.519 --> 00:44:59.199 Like I don't, I don't know that there's a better solution for them. 547 00:45:00.119 --> 00:45:02.519 No, I'm totally with you on that. I mean, I'll say the 548 00:45:02.519 --> 00:45:07.480 controversial thing, which is, I believe there's probably one percent of the use 549 00:45:07.559 --> 00:45:12.079 cases are Kubernetes, and the ninety nine percent you probably don't need that, 550 00:45:12.199 --> 00:45:15.039 you know. I feel like from experience it's something related to GPUs or on 551 00:45:15.159 --> 00:45:22.639 prem you have if you have need to deploy like a very high cardinality number 552 00:45:22.719 --> 00:45:29.239 of containers with minor tweaks to the variables or parameters for each of those containers, 553 00:45:29.519 --> 00:45:31.559 then for sure, one hundred percent Kubernetes, nothing else is going to 554 00:45:31.559 --> 00:45:36.280 give you that level of control with the repeatability. I just find that, 555 00:45:36.360 --> 00:45:42.079 as you said, there is hypothetical value associated with portability or cross platform same 556 00:45:42.079 --> 00:45:44.840 way like, oh, if we use terraform, we'll just be able to 557 00:45:45.559 --> 00:45:50.360 immediately change clouds, just like that with the infrastructure. I think it's it's 558 00:45:50.400 --> 00:45:52.320 for sure the same mistake. But at the application level. That's my highly 559 00:45:52.320 --> 00:45:58.239 controversial opinion. I'm not going to get my mind changed anytime soon, but 560 00:45:58.519 --> 00:46:00.400 you know, feel free to write me some letters to my email. Yeah 561 00:46:00.559 --> 00:46:06.199 I would. I would also add that the ecosystem that's evolved around Kubernetes is 562 00:46:06.719 --> 00:46:09.679 amazing, and I think a lot of people use Kubernetes because of that ecosystem, 563 00:46:09.679 --> 00:46:15.559 because they have, you know, great tools in Kubernetes that enable them 564 00:46:15.559 --> 00:46:20.960 to do observability and c ICD and the or and I see or you also 565 00:46:21.000 --> 00:46:24.039 have another Yeah, I know, right, this is hot take episode. 566 00:46:24.159 --> 00:46:30.599 I think that there's uh. There was a controversial AI developer Devin who I'm 567 00:46:30.599 --> 00:46:32.159 sure everyone is aware of at this point, and I feel like there's a 568 00:46:32.480 --> 00:46:38.119 it's very difficult to separate out core problem solving from solving problems that were created 569 00:46:38.159 --> 00:46:43.480 by the infrastructure or architecture that you've picked. So ideally, if using a 570 00:46:43.519 --> 00:46:46.119 cloud provider, you don't need to monitor and observe what's going on there. 571 00:46:46.119 --> 00:46:50.760 If using Kubernetes, you for sure do. So. Yes, all the 572 00:46:50.760 --> 00:46:53.400 great tools for observability only work with Kubernetes because you need them to work. 573 00:46:53.599 --> 00:47:00.400 Otherwise you're like, what is going on and by infrastructure staff? Yeah, 574 00:47:00.400 --> 00:47:04.159 what's wrong with me? Why don't I Why don't I need to use all 575 00:47:04.159 --> 00:47:08.039 these observability cool observability tools be with the cool kids. No, No, 576 00:47:08.360 --> 00:47:13.800 it's interesting. I mean you definitely get you definitely get left out right because 577 00:47:13.840 --> 00:47:15.920 you're not using that thing. I hear very frequently using Oh, we can't 578 00:47:16.000 --> 00:47:21.559 use Lambda or cloud functions or even cloud run because they don't offer the same 579 00:47:21.599 --> 00:47:23.480 sort of integration. I mean, I think the truth is almost everything offers 580 00:47:23.480 --> 00:47:28.920 hotel integration at this point, So you know, forget that, you know 581 00:47:28.920 --> 00:47:30.800 that's no longer the truth, But for sure, you just don't need to 582 00:47:30.800 --> 00:47:35.000 integrate with things because the hope is that you don't need to and I imagine, 583 00:47:35.039 --> 00:47:37.559 you know, with wing Lang you're writing stuff in a way that is 584 00:47:37.679 --> 00:47:42.159 agnostic, and you also hopefully don't need to know the observer. I don't 585 00:47:42.199 --> 00:47:44.239 know, maybe I'm saying too much. I assume you know, some sort 586 00:47:44.239 --> 00:47:50.840 of observability back end configuration or integration exists in some way. It exists in 587 00:47:50.840 --> 00:47:53.119 a roadmap. It doesn't exist yet, but it definitely exists in a roadmap. 588 00:47:53.119 --> 00:47:59.159 We want to We do want hotel to be built in to Wing, 589 00:47:59.280 --> 00:48:05.480 which is actually really exciting. I can wait to get there. I know 590 00:48:05.519 --> 00:48:07.039 a lot of people are jumping for joy over the fact that, oh I 591 00:48:07.079 --> 00:48:09.639 get that for free now, and I don't have to write a whole bunch 592 00:48:09.679 --> 00:48:15.599 of things to run a sidecar. Actually it's really timely because there was just 593 00:48:15.639 --> 00:48:22.199 a huge vulnerability discovered in a fluent bit I think like literally today, where 594 00:48:22.679 --> 00:48:28.599 there's a huge problem there and anyone running it there's a promote code execution vulnerability 595 00:48:28.599 --> 00:48:32.840 that you need to go and patch. Oh okay, well I guess I 596 00:48:32.880 --> 00:48:43.400 know what I'm doing this second. I don't over I mean so literally asked 597 00:48:43.400 --> 00:48:46.519 a question, is it worse than mug for Jay, so still being determined. 598 00:48:47.599 --> 00:48:51.519 Oh wow, the fact that you have to pause to answer that question 599 00:48:51.679 --> 00:48:59.840 is not a great indicator. This is concerning Yeah, so you mentioned that 600 00:49:00.239 --> 00:49:04.320 hotels on your roadmap. What else is on your roadmap? For Wing? 601 00:49:09.000 --> 00:49:15.400 One of the one of the pieces of of the solution is what we call 602 00:49:15.480 --> 00:49:22.719 the WING Console, which is this graphical user interface that allows you to interact 603 00:49:22.719 --> 00:49:29.679 with your cloud application. And again it starts from the developer, from the 604 00:49:29.719 --> 00:49:32.880 inner loop, right like you're because we're running inside a simulator, and so 605 00:49:34.159 --> 00:49:37.119 now you want to be able to see that when you put something in the 606 00:49:37.119 --> 00:49:39.559 bucket, it's actually there, and you know, send a request through the 607 00:49:39.599 --> 00:49:44.880 API or put some message in the queue and see that it's behaving the way 608 00:49:44.920 --> 00:49:46.679 you want it and run your tests. And so it's kind of like this. 609 00:49:47.199 --> 00:49:51.519 Currently it's kinrent of like a development tool, but one of the things 610 00:49:51.519 --> 00:49:59.079 that we're working on is getting the same view to connect to your production system. 611 00:49:59.559 --> 00:50:01.840 And and I think that I'm really excited about this because one of the 612 00:50:01.880 --> 00:50:08.239 cool things about this view is that it has a logical model of your application. 613 00:50:08.440 --> 00:50:15.440 So if you design your application, and every developer designs your application through 614 00:50:15.480 --> 00:50:19.639 composition. Right, they say, okay, this, I'm taking my problem, 615 00:50:19.760 --> 00:50:22.280 I'm breaking it down to smaller pieces, and each piece solves a certain 616 00:50:22.719 --> 00:50:27.119 part of the problem, and there's like interfaces, and you know, I 617 00:50:27.159 --> 00:50:30.239 can test each piece in isolation blah blah blah. But then you compose things 618 00:50:30.239 --> 00:50:34.239 together and it becomes this like tree. Right, so you have like your 619 00:50:34.239 --> 00:50:39.199 application and then your inger system and your storage system and your outbound connector and 620 00:50:39.280 --> 00:50:45.480 whatever. Right, So it basically create some kind of a hierarchical logical structure. 621 00:50:45.639 --> 00:50:49.960 And one of the things that I've seen with the CDK, and the 622 00:50:50.000 --> 00:50:53.480 CDK also allows you to do that, Like CDK has this concept called constructs 623 00:50:53.519 --> 00:51:00.760 that basically allow you to compose a smaller you know, composed truck together into 624 00:51:00.800 --> 00:51:05.360 higher level, higher level abstractions. And one of the things that I've seen 625 00:51:05.400 --> 00:51:08.599 with the CDK is that people are a bit reluctant to use these constructs to 626 00:51:08.639 --> 00:51:15.719 create logical abstractions because they they're lost when the abstractions are when the system is 627 00:51:15.760 --> 00:51:21.320 deployed. So you have this beautiful view right of your system and all these 628 00:51:21.480 --> 00:51:24.639 logical units, but then you end up deploying them and they break down to 629 00:51:24.760 --> 00:51:30.400 their atoms in a sense, right, like they break down become queues and 630 00:51:30.480 --> 00:51:35.760 buckets and containers and you know, topics, and like you're just you're unable 631 00:51:35.800 --> 00:51:38.880 to have like this logical you don't have this logical view of your system anymore. 632 00:51:39.760 --> 00:51:45.320 And so this console being able to actually see the same logical view in 633 00:51:45.440 --> 00:51:51.400 production, and being able to reason about your application in production the same way 634 00:51:51.440 --> 00:51:54.679 you reason about it and during development the same way you wrote your code, 635 00:51:54.960 --> 00:52:00.920 and having this trace stability between something that happens and in production on the cloud 636 00:52:01.119 --> 00:52:06.599 and the logical unit in the code that actually you know, like you know, 637 00:52:06.719 --> 00:52:10.199 I have this queue filled up. Okay, so this is a low 638 00:52:10.280 --> 00:52:15.599 level error. But then if I understand that this que belongs to some certain 639 00:52:15.920 --> 00:52:19.559 piece of the system, I can react much more much quickly. I can 640 00:52:19.639 --> 00:52:24.000 understand exactly who's responsible for this. I can diagnose problems much better. And 641 00:52:24.000 --> 00:52:29.639 and so that's another thing that we're working on. The I think it's I 642 00:52:29.639 --> 00:52:32.159 feel like that's something that's not work like definitely not to skip over, like 643 00:52:32.239 --> 00:52:36.679 when you're using stuff like the CDK, it's a bunch of transformation steps, 644 00:52:37.000 --> 00:52:39.559 and so one of the transformations you lose sort of all of the metadata that 645 00:52:39.599 --> 00:52:44.599 happens in the step before its CDK turns into CloudFormation templates, which ends up 646 00:52:44.639 --> 00:52:47.320 in AWS, and it's like one direction. All that basically means you have 647 00:52:47.360 --> 00:52:51.599 a bi directional view. You're able to look at what's actually deployed in production, 648 00:52:51.800 --> 00:52:55.039 combine it with the metadata that's in your in the written for wing, 649 00:52:55.280 --> 00:53:00.679 and see that picture from the outside without needing a WS to make fundamental changes 650 00:53:00.760 --> 00:53:04.960 to their tagging system or I mean, I'm sure there's some clever ways of 651 00:53:05.000 --> 00:53:07.840 getting that metadata am so you can pull it back out later, but they 652 00:53:07.880 --> 00:53:09.559 don't have to make changes to the cloud in order to directly be able to 653 00:53:09.559 --> 00:53:13.719 support this view, which is what we need to happen with stuff like the 654 00:53:13.719 --> 00:53:19.480 CDK or even terrorform, which doesn't command or really look into your production cloud 655 00:53:19.559 --> 00:53:22.719 environment to understand what's going on. It's just one direction, you know, 656 00:53:22.800 --> 00:53:25.239 transform, have to transform until you're there. Yeah, it's kind of leaky 657 00:53:25.280 --> 00:53:30.039 in that sense, right because basically the abstraction is leaking out and that and 658 00:53:30.039 --> 00:53:37.199 and also in many cases you have different people involved in the operations of the 659 00:53:37.239 --> 00:53:43.559 system and so not having like a shared mental model of the system is sometimes 660 00:53:43.599 --> 00:53:46.159 a huge problem, and I think you know people what people do is that 661 00:53:46.280 --> 00:53:52.960 they they use tagging, they they create dashboards. Dashboards sometimes is basically just 662 00:53:52.039 --> 00:53:57.639 a way to restore some logical view, right they Oh, all of these 663 00:53:57.679 --> 00:54:00.519 resources belong to this part of the system, and so now when I'm walking 664 00:54:00.719 --> 00:54:04.880 looking at the dashboard, I understand that something happened in this part of the 665 00:54:04.920 --> 00:54:07.760 system. But with WING, you really don't have to do this manual because 666 00:54:07.760 --> 00:54:14.599 we know all this information from your code, which is exciting. I mean 667 00:54:14.639 --> 00:54:16.599 I feel like as actually trying to go in this direction a little bit, 668 00:54:16.639 --> 00:54:21.360 but then clearly didn't get it turned into a product or a service in the 669 00:54:21.360 --> 00:54:24.719 aws's view, which is like I don't want to see the underlying primitives as 670 00:54:24.760 --> 00:54:29.000 you put it here, Like I want to see the service components and the 671 00:54:29.079 --> 00:54:31.199 architecture that I've deployed, as I understand it. When I go to the 672 00:54:31.239 --> 00:54:36.800 homepage of AWS console, I want to see my individual services laid out there 673 00:54:36.880 --> 00:54:38.920 that I can click on directly and not be like, oh wait, this 674 00:54:39.000 --> 00:54:43.199 service is made up of a container, plus it's running Kubernetes, and then 675 00:54:43.199 --> 00:54:45.000 there's these other things like I just want to see one blog and I can 676 00:54:45.000 --> 00:54:47.920 click on it and it will tell me. Data is fine, Logs are 677 00:54:47.960 --> 00:54:52.119 great, monitoring, observabili everything's great. There, connections in and out a 678 00:54:52.119 --> 00:54:54.119 shop good, right, flows fantastic. I don't want to have to jump 679 00:54:54.119 --> 00:55:00.400 into those underlying primitives to understand them. Yeah, I agree. I think 680 00:55:00.440 --> 00:55:05.519 a lot of them went too far with that, Like they tried to show 681 00:55:05.599 --> 00:55:08.760 that, but then in doing so, they ended up showing you know, 682 00:55:08.840 --> 00:55:12.760 like, oh, here's the four hundred security groups that were created. Was 683 00:55:12.960 --> 00:55:15.159 as a result of this template, and like, ah, okay, thanks, 684 00:55:15.199 --> 00:55:22.679 but really really not helpful, man. Yeah, I mean I can 685 00:55:22.760 --> 00:55:25.400 also be empathetic to a w S society of the world in that sense, 686 00:55:25.480 --> 00:55:31.159 because one of the beautiful things about Amazon, and really for me it was 687 00:55:31.239 --> 00:55:38.000 it was it was just empower incredibly empowering. Is this two pizza team model, 688 00:55:38.159 --> 00:55:43.360 you know? And I'm assuming like it's basically like this operational model of 689 00:55:43.400 --> 00:55:46.320 the company that says, you know, there's a there's a small team that's 690 00:55:46.360 --> 00:55:52.119 responsible for a certain type of product delivered to customers. They just obsess about 691 00:55:52.199 --> 00:55:57.119 making these customers happy and and it's it's and it's real, like and the 692 00:55:57.199 --> 00:56:00.440 empowerment is real, Like the ability of that team to actually make decisions and 693 00:56:00.480 --> 00:56:07.760 deliver without interruption is I haven't seen that anywhere. And I think one of 694 00:56:07.800 --> 00:56:13.559 the results of this is that it's really hard to create like a holistic view, 695 00:56:13.760 --> 00:56:16.760 right, Like I think like as customers both aws. You actually also 696 00:56:16.760 --> 00:56:20.599 see this in the Amazon website, right, Like you go to an Amazon 697 00:56:21.480 --> 00:56:27.079 product page and there's like a eleven thousand services involved in like rendering this page, 698 00:56:27.519 --> 00:56:31.800 and it's horrible, right Like, it's like it's clear that nobody has 699 00:56:31.880 --> 00:56:38.519 like this holistic you know, intention about how this needs to look. But 700 00:56:39.320 --> 00:56:44.639 it's good enough, and it's like, you know, very valuable to customers. 701 00:56:44.679 --> 00:56:47.760 And I think like this is saying kind of like DNA Amazon DNA, 702 00:56:47.880 --> 00:56:57.280 that's like leaking out to the experience because Amazon is really intentional about this trade 703 00:56:57.320 --> 00:57:02.639 office like saying, we prefer that teams would have independence because otherwise it's just, 704 00:57:02.920 --> 00:57:07.239 you know, with such a big organization, so many services and so 705 00:57:07.280 --> 00:57:12.480 many teams just becomes like a you know, a standstill at some point if 706 00:57:12.480 --> 00:57:19.199 you have to, Like so, I can't even imagine what that would look 707 00:57:19.239 --> 00:57:25.159 like if you had every developer at Amazon had to go through like a single 708 00:57:25.760 --> 00:57:30.599 infrastructure team to build something we would it takes like six months to get a 709 00:57:30.599 --> 00:57:35.239 PR through. There's a there's a couple of other cloud providers out there who 710 00:57:35.280 --> 00:57:37.360 may be following that model, and you know, maybe that's what it looks 711 00:57:37.400 --> 00:57:44.119 like. I mean, I see I see WING as this like you know, 712 00:57:44.199 --> 00:57:46.760 imagine AWS worked exactly as it did, but there are a couple of 713 00:57:46.800 --> 00:57:52.000 things that are cross cutting that just salt Like everyone's like, how can tags 714 00:57:52.039 --> 00:57:54.079 not be ubiquitous? Right? There are a couple of things like that which 715 00:57:54.079 --> 00:57:58.800 are which would really make the developer experience so much better. And I feel 716 00:57:58.840 --> 00:58:04.119 like maybe it's WING that's giving you that. I think. I think the 717 00:58:04.159 --> 00:58:09.039 way we kind of circumvent the challenge is by reducing the surface area, right, 718 00:58:10.159 --> 00:58:15.880 because trying to do this across one hundred and eighty services of ABS is 719 00:58:15.960 --> 00:58:20.119 no reasonable, right, especially not for a small startup. It's not also 720 00:58:20.159 --> 00:58:22.400 reasonable for like a team of databas. I think one of the challenges we've 721 00:58:22.400 --> 00:58:27.360 had with the CDK and constantly having with the CDK, and I think CloudFormation 722 00:58:27.559 --> 00:58:32.480 is also having this challenge is basically racing AWS and making sure there's coverage for 723 00:58:32.480 --> 00:58:37.920 all the research for the capabilities and feed new features and new services that spin 724 00:58:37.079 --> 00:58:40.119 up every year. And so what we've done with WINGS is said, Okay, 725 00:58:43.079 --> 00:58:45.679 hold on for a second, Let's see what's the foundation that is, 726 00:58:45.920 --> 00:58:51.480 you know, good enough to build a majority of the applications or a good 727 00:58:51.920 --> 00:58:54.280 you know, a good chunk of the applications and create a really great developer 728 00:58:54.320 --> 00:59:01.320 experience for that. And it is a very extensible kind of ecosystem play that 729 00:59:01.360 --> 00:59:06.360 we're doing. And so you can actually create libraries and we have like people 730 00:59:06.400 --> 00:59:10.280 starting to like publish libraries for Wing and so like it is designed to offer 731 00:59:10.360 --> 00:59:15.760 you a general purpose solution. But what we're trying to do is we're trying 732 00:59:15.800 --> 00:59:19.400 to focus on the foundation. I think like it's a it's a it's a 733 00:59:19.440 --> 00:59:22.480 reverse pyramid, uh. And I think one of the problems with AWS is 734 00:59:22.559 --> 00:59:30.280 kind of architectural philosophy is that there's no pyramid in in internally a a WS, 735 00:59:30.840 --> 00:59:36.400 all services are created equal. So s Ree and Robomaker are basically the 736 00:59:36.480 --> 00:59:39.239 same, has the same kind of you know, place in the in the 737 00:59:39.360 --> 00:59:43.639 architecture. Right, Like it's kind of like a it's a it's a mesh 738 00:59:43.719 --> 00:59:46.760 of services as opposed to being like a stack. And I think like not 739 00:59:46.880 --> 00:59:52.280 having a stack makes it really hard for a ws's teams to prioritize and say, 740 00:59:52.320 --> 00:59:55.239 okay, this is this, these are part of the foundational stack. 741 00:59:55.320 --> 00:59:59.679 Let's make sure that you know, we get it in practice, this is 742 00:59:59.719 --> 01:00:04.440 what right like in practice, when we started a CDK, we've you know, 743 01:00:04.480 --> 01:00:09.119 we've created as three abstraction API would create it like we've actually done practically, 744 01:00:09.159 --> 01:00:13.440 we've done that. But but I think it's if when you don't have 745 01:00:13.519 --> 01:00:20.280 that architecturally, then you can't really build holistic experiences based on that stock. 746 01:00:20.320 --> 01:00:23.000 And then that's what we're trying to do with me. I don't know if 747 01:00:23.000 --> 01:00:34.880 that made sense philosophical Sometimes it just goes that way. Yeah, So from 748 01:00:34.920 --> 01:00:38.719 a practical perspective, what does it look like to get started with Wing? 749 01:00:38.800 --> 01:00:45.000 Like if I have my application and of like it's it's already built and running, 750 01:00:45.079 --> 01:00:50.159 but I'm signing off on this new approach. How do I what's the 751 01:00:50.199 --> 01:00:53.639 transition project or transition process look like for saying I'm going to use Wing to 752 01:00:53.719 --> 01:00:59.119 do that? And how do I get started? So first of all, 753 01:00:59.119 --> 01:01:02.000 it's you know, open source and go to Wing lang dot io and you 754 01:01:02.039 --> 01:01:07.360 can download it and install it and run it on your machine and it's free, 755 01:01:07.519 --> 01:01:13.159 and uh, you get the simulator and the console and everything. And 756 01:01:14.440 --> 01:01:17.599 what what we've that's actually an interesting you know, it's an interest. It's 757 01:01:17.599 --> 01:01:22.239 a it's a more interesting question. I think that you that maybe we want 758 01:01:22.280 --> 01:01:25.719 it to be at this point. But what we've started to do with Wing 759 01:01:25.760 --> 01:01:31.400 is we basically said we want to start from the ideal experience. We want 760 01:01:31.480 --> 01:01:37.280 to put it to put that in place. And and so what we've done 761 01:01:37.360 --> 01:01:39.320 is we actually created a programming language. We haven't talked about this, but 762 01:01:39.360 --> 01:01:45.679 we've actually created a programming language that's that has that has these ideas baked into 763 01:01:45.719 --> 01:01:51.880 the language, and it's built on top of this standard library. It's built 764 01:01:51.880 --> 01:01:54.400 on top of this you know, set of abstractions, but it also has 765 01:01:54.440 --> 01:02:00.280 this really cool thing called in flight functions, and the idea of inflight functions 766 01:02:00.280 --> 01:02:05.719 in the way it's kind of like ACYNC functions in traditional languages, only that 767 01:02:05.880 --> 01:02:09.880 inflant functions not only run later in time, they also run in a different 768 01:02:10.039 --> 01:02:14.920 place, so you can actually package them and ship them to the cloud. 769 01:02:15.760 --> 01:02:21.119 And what you could do with inflight functions is basically represent the application logic, 770 01:02:21.159 --> 01:02:29.360 the run time behavior of your system within the same programming model that you're describing 771 01:02:29.559 --> 01:02:32.599 the cloud resources that you're using. So you can basically say new bucket, 772 01:02:32.719 --> 01:02:38.840 new queue, new container, and then you can basically specify the code that's 773 01:02:38.880 --> 01:02:43.800 running inside the container in the same programming space or new function, new Lembda 774 01:02:43.800 --> 01:02:49.400 function. And the cool thing about this is that when you write this code, 775 01:02:49.440 --> 01:02:54.239 this inflight code, you can interact between your inflight and your pre flight 776 01:02:54.320 --> 01:03:00.519 resources. So you can basically say bucket, dot put and when this, 777 01:03:00.679 --> 01:03:05.320 when this is basically compiled, it compiles to terra form or to any other 778 01:03:05.800 --> 01:03:07.679 uh you know target platform. As I said, right like, it's a 779 01:03:07.719 --> 01:03:12.280 customizable thing. So we actually have an a b c DK platform, the 780 01:03:12.320 --> 01:03:16.679 compilsitor that can be deployed through cloud formation. And we have someone asking about 781 01:03:19.320 --> 01:03:22.280 cross plane platform, which is interesting, right like, basically compiled to Kubernetes 782 01:03:22.280 --> 01:03:29.039 siamos and deployed through through Kubernetes. And but when you compile to the Staria 783 01:03:29.079 --> 01:03:32.960 platform, the compiler is able to basically bind your runt time code with your 784 01:03:34.000 --> 01:03:36.559 infrastructure. And so it basically says, okay, so you need to be 785 01:03:36.639 --> 01:03:38.440 able to put file in the bucket. Great, I need to know the 786 01:03:38.519 --> 01:03:42.400 name of the let's say I'm on S three, I need to know the 787 01:03:42.440 --> 01:03:45.280 bucket name, and I need the im permissions, these im permissions in order 788 01:03:45.320 --> 01:03:52.320 to actually deliver this this application code and and so you get this really really 789 01:03:52.360 --> 01:04:00.079 really nice end to end holistic experience. But what we're realizing, and I 790 01:04:00.079 --> 01:04:04.440 guess it's pretty obvious, but what we're doing right now is we're basically offer 791 01:04:04.480 --> 01:04:10.079 it starting to offer the ability to use WING just for the infrastructure piece. 792 01:04:10.239 --> 01:04:15.239 So basically use all these APIs, but then just bring in your own LAMB 793 01:04:15.239 --> 01:04:18.760 the function or your own container. And we already have support for containers, 794 01:04:18.760 --> 01:04:24.039 which is pretty cool. We're working on some support for LAMBDAM And in this 795 01:04:24.199 --> 01:04:28.599 case you're binding between your infrastructure and your application. Is obviously requires a bit 796 01:04:28.639 --> 01:04:34.159 more a bit more work because those things are now decoupled and not coupled together 797 01:04:34.239 --> 01:04:40.320 into the same language. And so to your question, if you have existing 798 01:04:40.360 --> 01:04:45.360 code, you can take your application code and use it and then replace your 799 01:04:45.360 --> 01:04:49.320 infrastructure code with WING. So would it be maybe it's like terraform or CloudFormation, 800 01:04:49.719 --> 01:04:54.000 So you can basically use way to define your infrastructure and basically point to 801 01:04:54.079 --> 01:04:57.719 your application code and bind it together, and then it starts running in a 802 01:04:57.760 --> 01:05:04.199 simulator and you can start compiling different cloud platforms. So yeah, it's it's, 803 01:05:04.320 --> 01:05:08.920 it's it's definitely a theme that we've we're working on now, and we 804 01:05:09.079 --> 01:05:13.760 kind of have some more work to do in order to streamline this experience because 805 01:05:14.679 --> 01:05:17.679 obviously we understand that most people already have some work clouds, and we really 806 01:05:17.719 --> 01:05:23.559 do want to be able to bring the value immediately, right Like it doesn't 807 01:05:23.599 --> 01:05:28.760 mean it, yeah for sure, And I think it's that's kind of kind 808 01:05:28.760 --> 01:05:32.159 of the reason I phrased the question the way I did, because I think 809 01:05:32.639 --> 01:05:40.320 as a community or as an industry, maybe we're all sort of looking for 810 01:05:40.400 --> 01:05:45.880 that solution that says, Okay, I'm I'm down with cloud infrastructure, but 811 01:05:45.960 --> 01:05:50.079 that's not the solution every time. And you know, we talked we've talked 812 01:05:50.079 --> 01:05:55.719 about this already in the episode, that there's a desire to have cloud agnostic 813 01:05:55.880 --> 01:06:00.360 solutions and so there's all this legacy stuff and it's problems that we haven't really 814 01:06:00.239 --> 01:06:04.679 face before or saw before. So I think you're very early in this, 815 01:06:04.960 --> 01:06:12.199 and there's there's no path right now where you're you're kind of cutting your own 816 01:06:12.280 --> 01:06:15.079 path, as are some other people in the industry to figure out what this 817 01:06:15.159 --> 01:06:19.559 looks like. And I think it's like the future of what the whole infrastructure 818 01:06:19.599 --> 01:06:24.440 world is going to look like a few years from now. They're very optimistic. 819 01:06:28.320 --> 01:06:30.760 I like the fact that you both laughed at me, like I've done. 820 01:06:31.480 --> 01:06:33.719 No, I was, I was. I was happy to hear that. 821 01:06:33.800 --> 01:06:38.960 No. Obviously obviously optimistic. I was. I was, I obviously 822 01:06:39.159 --> 01:06:41.920 you know, I always, I really do believe that. You know, 823 01:06:42.000 --> 01:06:45.199 as an engineers, we we want to solve problems. Eventually we solve them. 824 01:06:45.480 --> 01:06:48.199 It takes time. We need to crack the crack, the solutions, 825 01:06:48.320 --> 01:06:54.760 crack. The The business around solving those problems is you know, one of 826 01:06:54.800 --> 01:06:58.920 the things that I'm you know, challenged by right now is like, Okay, 827 01:06:58.960 --> 01:07:01.039 I'm an engineer, but you need to build a business act and create 828 01:07:01.079 --> 01:07:05.559 like a commercial story around this. But it's all problem solving eventually, so 829 01:07:06.360 --> 01:07:09.679 we'll figure things out. No, I mean, I think it's right on 830 01:07:09.719 --> 01:07:13.320 point, because actually last week on the episode, we were talking about the 831 01:07:13.320 --> 01:07:16.000 fact that there needs to be probably a compaction in the space. We need 832 01:07:16.039 --> 01:07:21.559 to do some sort of depth first evaluation on a bunch of different things until 833 01:07:21.559 --> 01:07:27.079 we find one that actually solves a majority of our stack, majority of the 834 01:07:27.119 --> 01:07:30.599 problems that we're having, and then sort of eliminate all of the previous examples. 835 01:07:30.800 --> 01:07:33.679 And so right now we're not really sure, especially in the infrastructure deployment 836 01:07:33.719 --> 01:07:36.800 area. I feel like, as Will you pointed out, we don't really 837 01:07:36.840 --> 01:07:40.840 know what the best answer is at this moment, and for sure what we've 838 01:07:40.840 --> 01:07:43.920 got is not appropriate. Like we can see that there's lots of churn, 839 01:07:44.039 --> 01:07:48.599 lots of struggle in the different areas, So I think realistically you may actually 840 01:07:48.639 --> 01:07:55.400 want to start fresh with something new to examine it. There's not really another 841 01:07:55.400 --> 01:07:58.639 way, But you know, Flo, as you said, it's a business, 842 01:07:58.760 --> 01:08:02.480 right, I think trying to capture those existing everyone has something today, 843 01:08:02.639 --> 01:08:08.199 likely if they're making money in some way, So trying to do that migration 844 01:08:08.360 --> 01:08:15.119 is going to be a critical path forward totally and possibly, like you were 845 01:08:15.159 --> 01:08:19.560 just alluding to Warren, maybe a bit premature. Like the first thing is 846 01:08:19.600 --> 01:08:24.560 to just do a new project and see what the see what it looks like, 847 01:08:25.840 --> 01:08:29.079 and kind of iron out that flow and then figure out, Okay, 848 01:08:29.359 --> 01:08:32.439 now, how do we use this to onboard all of the legacy stuff that 849 01:08:32.439 --> 01:08:36.800 we're that kind of forced us to look at this problem. Oh yeah, 850 01:08:36.840 --> 01:08:41.960 every company should be doing pocs with experiments like I don't know, each team 851 01:08:42.000 --> 01:08:45.439 should be doing at least once maybe once a month. And if they're not, 852 01:08:45.680 --> 01:08:48.039 you know, then you have this extra capacity where you're not actually figuring 853 01:08:48.079 --> 01:08:53.039 out how can we push our business forward with a huge step change? Right? 854 01:08:53.079 --> 01:08:55.239 You know, how what can we do with innovative in our space? 855 01:08:55.399 --> 01:08:58.720 So it doesn't really matter where it's at, the idea is, of course, 856 01:08:58.760 --> 01:09:02.119 experiment with something new and figure out how you can maybe use that effective 857 01:09:02.239 --> 01:09:08.039 in a future real business case. Yeah. So yeah, if people are 858 01:09:08.760 --> 01:09:15.319 experimenting with wing, we'd love feedback. We'd love to learn about people's use 859 01:09:15.359 --> 01:09:18.119 cases and what they're trying to achieve and what they like, what they don't 860 01:09:18.239 --> 01:09:24.760 like. More than happy to talk to anyone. What's the time commitment look 861 01:09:24.920 --> 01:09:30.079 like for checking out like the Hello World version of using wing? How long 862 01:09:30.119 --> 01:09:33.960 does it take to get up and run? In? Fifteen minutes? Ten 863 01:09:34.000 --> 01:09:40.079 minutes? Nice, super quick, super quick? Right on? I think 864 01:09:40.119 --> 01:09:43.720 you've got a I don't think you saw this a whole Discord community dedicated to 865 01:09:44.680 --> 01:09:50.399 the project to Yeah, it was a Slack community until last week. So 866 01:09:50.520 --> 01:09:55.880 yeah, come join our new Discord. It's it's uh, we're ramping it 867 01:09:56.000 --> 01:10:00.960 up and it's been just a coincidence. Has nothing to do with their policy 868 01:10:00.039 --> 01:10:05.119 change, Actually not, it's it has to do with you know, the 869 01:10:05.399 --> 01:10:10.359 community just grew to a point where it was like didn't make sense financially to 870 01:10:10.600 --> 01:10:15.560 support the slack Slack stuff. Yeah, for sure that that gets out of 871 01:10:15.560 --> 01:10:21.399 control really really quick. Yeah. Yeah, but yeah, as you mentioned, 872 01:10:21.439 --> 01:10:26.800 Warren, the policy change has been has been the best thing to happen 873 01:10:26.840 --> 01:10:31.199 to Discord in years. I mean it's right online because uh, you know, 874 01:10:31.239 --> 01:10:34.159 Discord wants to IPO at some point, so uh you know, I 875 01:10:34.199 --> 01:10:38.720 feel like having those wins in there in their bag is important. Just need 876 01:10:38.840 --> 01:10:46.880 Microsoft teams to uh continue on. It's pretty as bad. Yeah. Every 877 01:10:46.920 --> 01:10:50.560 product has their like product name and tagline. For Discord, it's going to 878 01:10:50.600 --> 01:10:58.800 be Discord. We're not Slack. Yeah, it's it's I like, I 879 01:10:59.239 --> 01:11:04.800 really like the playfulness and the like. There's some weirdness, like it takes 880 01:11:04.960 --> 01:11:10.159 use to definitely if you're coming from Slack, But I like the pay playfulness. 881 01:11:10.239 --> 01:11:14.840 I like all the community features, the events, the uh. It 882 01:11:14.880 --> 01:11:20.279 definitely feels like we've debated it when we started the when we started the community, 883 01:11:20.319 --> 01:11:24.079 and it was a mistake. I feel like we should have started with 884 01:11:24.119 --> 01:11:29.640 Discord. I feel like Discord has come a long way, and probably in 885 01:11:29.680 --> 01:11:33.920 the last two years, I'm going to say as far as like the number 886 01:11:33.960 --> 01:11:40.560 of features and options, but the biggest one for me has been the improvements 887 01:11:40.600 --> 01:11:45.239 they've made. And like the onboarding experience and getting started because it was early 888 01:11:45.279 --> 01:11:49.760 on it was a hassle to get connected and God forbid you. You get 889 01:11:49.760 --> 01:11:53.720 a second device and have to sign in again. It's like, ah, 890 01:11:54.119 --> 01:11:59.640 it's great, I'm just starting a new account. Yeah, totally. Or 891 01:11:59.680 --> 01:12:02.279 you make it through the onboarding experience and realized you did create a second account 892 01:12:02.319 --> 01:12:11.760 without meaning to cool. So anything that we should have covered that we haven't 893 01:12:11.760 --> 01:12:16.800 talked about yet. For Wing, No, I think you let me talk 894 01:12:16.800 --> 01:12:26.760 a lot. That's that's my job. Give an introvert to mic and everything 895 01:12:26.800 --> 01:12:32.520 else works itself out. Awesome, man, Well let's do some pics, 896 01:12:34.159 --> 01:12:38.039 Warren. Did you bring a pick this week? Yeah, of course, 897 01:12:38.119 --> 01:12:45.600 right, that's a sort of requirement for sure. My pick is going to 898 01:12:45.640 --> 01:12:48.600 be Building micro Services by Sam Newman, So I'm going to stay on my 899 01:12:48.680 --> 01:12:55.479 book trend. Really, I feel like this is what converted me to personally 900 01:12:55.479 --> 01:13:00.119 the micro services in my career, where the advantages are really hot, to 901 01:13:00.159 --> 01:13:02.319 think about them, how to interface between them, how to build them effectively. 902 01:13:02.920 --> 01:13:06.279 Uh, it's a really great book. Honestly, I think it's still 903 01:13:06.279 --> 01:13:11.760 in the community. It's probably considered the I don't say holy Grail, but 904 01:13:12.239 --> 01:13:17.880 for sure relic that represents how to how to push the industry forward? Ran 905 01:13:18.439 --> 01:13:28.800 excellent. What about you? I'll pick The Three Body Problem. Have you 906 01:13:28.960 --> 01:13:35.319 had a chance to watch it? Both both actually like the the I read 907 01:13:35.359 --> 01:13:41.479 the books a while ago, and probably one of the best science fiction serious 908 01:13:41.640 --> 01:13:45.920 I've ever read. I really love science fiction, and this one's like the 909 01:13:45.960 --> 01:13:48.800 first book is a bit it. I actually read the first one and only 910 01:13:48.840 --> 01:13:54.920 read the second one kind of got came back to the serious few years later. 911 01:13:55.279 --> 01:13:57.800 It didn't, it didn't make it didn't. It didn't for some reason 912 01:13:57.840 --> 01:14:00.359 then when it didn't want to continue. But then as you continue to read 913 01:14:00.399 --> 01:14:11.199 the series, it's just amazing. It's just an amazing story and beautifully written 914 01:14:11.439 --> 01:14:16.720 and creative and it goes really really really far, and so I think like 915 01:14:17.159 --> 01:14:21.279 Netflix has just released the first season and it was so much fun to watch, 916 01:14:21.520 --> 01:14:28.399 especially knowing where this is going, and so highly recommend this the book 917 01:14:28.439 --> 01:14:34.880 series and the and the show. And it's like it's it's there's something I 918 01:14:34.920 --> 01:14:41.319 think I can tell, like the kind of like the theme basically is aliens 919 01:14:41.319 --> 01:14:45.800 are coming in three hundred years. We know that they're coming. What happens 920 01:14:45.800 --> 01:14:50.479 with humanity? Right? Like what what does this knowledge due to humanity? 921 01:14:50.680 --> 01:15:00.720 Right? Like that's just crazy? So right you mentioned you you also read 922 01:15:00.720 --> 01:15:03.960 a little bit some of it. I read the first two books and seen 923 01:15:04.000 --> 01:15:08.760 the show. Honestly, they're sort of like the same concept but different, 924 01:15:08.840 --> 01:15:14.800 completely different content as far as watching or reading. Obviously the same challenge, 925 01:15:15.079 --> 01:15:18.560 but they go in different directions, so you can get the same enjoyment twice 926 01:15:18.640 --> 01:15:23.159 by by going about them. It's not really like book is better than the 927 01:15:23.279 --> 01:15:25.960 movie. Yeah, yeah, which is very rare. It's very differ. 928 01:15:26.520 --> 01:15:29.000 Both of them are very very well done, for sure. I mean I 929 01:15:29.000 --> 01:15:33.560 feel like you said something controversial when you said it's the best science fiction I 930 01:15:33.600 --> 01:15:40.159 have, you know, but I don't want to get this into an argument 931 01:15:40.920 --> 01:15:44.000 said, it's almost the best, because to me, the best always foundation. 932 01:15:44.159 --> 01:15:47.840 It's always like, oh man, see, you know, just agree 933 01:15:47.840 --> 01:15:51.560 to disagree there, Okay, no, no gloves come off, let's go. 934 01:15:53.039 --> 01:15:57.520 Oh for sure, for sure it's Frank Herbert's Dune, hands down, 935 01:15:57.600 --> 01:16:00.800 no question. I admit I didn't. I didn't read the book, so 936 01:16:00.840 --> 01:16:03.760 maybe I should. I know that I should know that I should. It's 937 01:16:04.359 --> 01:16:10.720 like the idea of world building is so far, even beyond the three body 938 01:16:10.760 --> 01:16:13.760 problem. How to think about it and the things that are generated in order 939 01:16:13.800 --> 01:16:18.000 to further the universe. Also the length of time, you know, much 940 01:16:18.039 --> 01:16:23.800 more further out than even three body problem. It's nuts, it's not you 941 01:16:23.840 --> 01:16:30.279 haven't read the last book. Yeah, so all right, So what I'm 942 01:16:30.279 --> 01:16:34.760 hearing here is Warren is going to go read the third book and then you're 943 01:16:34.760 --> 01:16:42.159 going to come back on the show and we're gonna Yeah, he's just trying 944 01:16:42.159 --> 01:16:45.720 to read The Expense now, which is also pretty good for sure, also 945 01:16:45.840 --> 01:16:51.359 great science fiction book. Will just trying to get out of sharing his pick 946 01:16:51.439 --> 01:16:58.039 though. Oh no, I'm ready with a pick. Mine is is it's 947 01:16:58.079 --> 01:17:01.560 about knife sharpening because I did not know this was a rabbit hole. I 948 01:17:01.720 --> 01:17:08.960 was gonna go down, right, So I ended up watching Alex over on 949 01:17:09.119 --> 01:17:14.399 the Outdoors fifty five YouTube channel on how to sharpen your knife. And he's 950 01:17:14.439 --> 01:17:19.439 got to have a complete list of his videos here. It doesn't say him 951 01:17:20.399 --> 01:17:26.479 two hundred and sixty three videos on how to sharpen your knives. I didn't 952 01:17:26.520 --> 01:17:29.880 know you could talk about it that many times, but they're all like super 953 01:17:30.000 --> 01:17:38.600 interesting. And as a result, I bought a diamond grit sharpening stone and 954 01:17:38.840 --> 01:17:41.600 have been going through and sharpening all my eyes And I thought I could do 955 01:17:41.640 --> 01:17:45.399 a pretty decent job of sharpening and eyes before, but this takes it to 956 01:17:45.640 --> 01:17:53.079 a whole new level, like surgical grade sharpening. And so go check out, 957 01:17:53.439 --> 01:17:59.319 go check out his channel. Outdoors fifty five is the YouTube channel for 958 01:17:59.439 --> 01:18:01.439 two reasons. One, so you can learn everything you didn't know that you 959 01:18:01.920 --> 01:18:05.600 needed to know about sharpening your knife. But also just like the content creation, 960 01:18:06.640 --> 01:18:12.279 yeah right, And but also just like for content creation, like how 961 01:18:12.279 --> 01:18:17.760 do you create two hundred and sixty three entertaining videos about the same topic, 962 01:18:18.159 --> 01:18:21.399 Because he's done that, so it's actually pretty cool to share off for two 963 01:18:21.439 --> 01:18:25.840 reasons, and that's my pick for the week. Cool, all right, 964 01:18:26.399 --> 01:18:29.720 well, thanks for joining us, Eeled. This is being cool and I'm 965 01:18:30.359 --> 01:18:33.479 yeah, I'm excited about this because I you know, I I really think 966 01:18:33.520 --> 01:18:39.199 that this is the direction our industry is going is until it's an interesting space. 967 01:18:39.760 --> 01:18:44.960 There's quite a few people working on this, and and so yeah, 968 01:18:45.079 --> 01:18:47.039 I think it's super cool. Really appreciate you taking the time to come and 969 01:18:47.119 --> 01:18:51.840 sit with us on a show. Thanks for having me guys, yeah, 970 01:18:53.600 --> 01:18:58.880 Lawren, thank you, appreciate having you here and for yeah, I guess 971 01:18:58.960 --> 01:19:03.159 most importantly to everyone listening, thanks for listening, because that's not really a 972 01:19:03.159 --> 01:19:06.640 whole lot of reason for us to do this if you're not listening. Oh 973 01:19:08.079 --> 01:19:13.479 does it for himself? Right? Awesome? All right, Well it's getting 974 01:19:13.479 --> 01:19:16.600 awkward at this point, so I'm gonna kill the stream and thanks again, 975 01:19:16.960 --> 01:19:18.239 and we'll see you all next week.