1 00:00:00,040 --> 00:00:03,080 I mentioned LinkedIn had all of these issues. 2 00:00:03,080 --> 00:00:05,160 We had issues delivering our software, right? 3 00:00:05,160 --> 00:00:07,360 It doesn't matter if you're an app developer, if we can't ship 4 00:00:07,360 --> 00:00:09,320 your code, it's not going to provide any value. 5 00:00:09,600 --> 00:00:11,080 So we got to fix how we ship code. 6 00:00:11,360 --> 00:00:14,000 What's the smallest amount I can do that gives me the benefits I 7 00:00:14,000 --> 00:00:16,600 want while minimizing the drawbacks? 8 00:00:16,880 --> 00:00:20,840 Your customers do not care what technologies you're using. 9 00:00:20,960 --> 00:00:23,960 None of them care if you're using Kubernetes or service 10 00:00:23,960 --> 00:00:26,200 meshes or whatever. Like they just don't care. 11 00:00:26,200 --> 00:00:28,360 It doesn't matter. Honestly, your investors 12 00:00:28,360 --> 00:00:30,840 probably don't care, they just want something that works. 13 00:00:31,120 --> 00:00:33,920 The better approach is to use actual incrementalism. 14 00:00:34,040 --> 00:00:36,720 And the key is you don't just chop it up into pieces. 15 00:00:37,280 --> 00:00:41,440 But each of those pieces must be something you can deliver and 16 00:00:41,440 --> 00:00:45,760 get value from by itself, even if the other pieces never 17 00:00:45,760 --> 00:00:47,960 happened. That is real incrementalism. 18 00:00:48,200 --> 00:00:50,640 If I was a betting man, I think the future is going to look a 19 00:00:50,640 --> 00:00:54,480 lot, lot more like serverless than it does like Kubernetes. 20 00:00:54,600 --> 00:00:56,760 I don't think Kubernetes is the long term direction of the 21 00:00:56,760 --> 00:00:59,480 industry right now. I would argue that the state of 22 00:00:59,480 --> 00:01:04,080 software delivery, DevOps, etcetera is not secure by 23 00:01:04,080 --> 00:01:05,800 default. You usually you build something 24 00:01:05,800 --> 00:01:07,720 and like all the networking is wide open. 25 00:01:07,760 --> 00:01:10,400 Nothing's encrypted. If you have third party 26 00:01:10,400 --> 00:01:13,360 dependencies, nobody verifies, nobody's keeping them up to 27 00:01:13,360 --> 00:01:17,600 date, there's no monitoring, and maybe worst of all is a lot of 28 00:01:17,600 --> 00:01:21,080 vendors charge extra money for the more secure things. 29 00:01:21,080 --> 00:01:23,760 Like using single sign on usually is only in the expensive 30 00:01:23,760 --> 00:01:26,760 enterprise plan, so we're the exact opposite of safe by 31 00:01:26,760 --> 00:01:41,640 default. Hello everyone, welcome back to 32 00:01:41,640 --> 00:01:43,760 another new episode of the Technician podcast. 33 00:01:43,760 --> 00:01:45,760 Today I have with me Yefgeny Brickman. 34 00:01:45,920 --> 00:01:49,440 So some of you from the infra world probably knows Yefgeny. 35 00:01:49,640 --> 00:01:52,040 Yefgeny is a Co founder of Groundwork. 36 00:01:52,320 --> 00:01:54,960 So if you are into the infrastructures code, you might 37 00:01:54,960 --> 00:01:57,000 have heard about Terra Ground or Terraform. 38 00:01:57,000 --> 00:01:58,960 He's the author of Terraform up and running. 39 00:01:59,280 --> 00:02:02,160 He's coming up with a new book which is currently in progress 40 00:02:02,320 --> 00:02:05,440 titled The fundamentals of DevOps and Software Delivery. 41 00:02:05,760 --> 00:02:09,080 So today we're going to cover topics from the book, right? 42 00:02:09,320 --> 00:02:11,440 And I'm happy to have a chat with you. 43 00:02:11,600 --> 00:02:14,520 If Guinea, welcome to the show. Thanks so much for having me. 44 00:02:15,360 --> 00:02:18,400 Right if Guinea, I always love to start my conversation by 45 00:02:18,400 --> 00:02:21,280 asking you to share a little bit about your career. 46 00:02:21,280 --> 00:02:24,080 Any turning points that you think we can learn from that 47 00:02:24,080 --> 00:02:25,880 journey? Sure. 48 00:02:26,440 --> 00:02:29,880 So really quick kind of big picture on career. 49 00:02:29,920 --> 00:02:33,480 I started my career as on the app development side of the 50 00:02:33,480 --> 00:02:37,200 house, software engineering, worked at Cisco Systems, 51 00:02:37,200 --> 00:02:41,440 TripAdvisor, LinkedIn, and then started grunt work. 52 00:02:42,360 --> 00:02:46,160 And there's been a lot of interesting twists and turns and 53 00:02:46,160 --> 00:02:47,480 things like that throughout the career. 54 00:02:47,480 --> 00:02:51,520 But maybe the biggest thing to share, and I share this with 55 00:02:51,520 --> 00:02:54,920 pretty much everyone I talked to and shared in most of my books 56 00:02:54,920 --> 00:03:00,640 as well, is just this idea of, of taking some time to learn 57 00:03:00,800 --> 00:03:04,680 every day or every week. But basically what I generally 58 00:03:04,680 --> 00:03:07,400 see is, you know, we go to school, some of us go to 59 00:03:07,400 --> 00:03:09,760 college. And so we spend this whole time 60 00:03:09,760 --> 00:03:11,680 doing this very deliberate learning. 61 00:03:12,080 --> 00:03:16,040 And then you get a job and then you stop and people kind of just 62 00:03:16,040 --> 00:03:19,200 stagnate. And so I've written a few books 63 00:03:19,200 --> 00:03:21,600 and something that's really sad to me is, and I don't know how 64 00:03:21,600 --> 00:03:23,560 accurate these statistics are, maybe they're dated, but I 65 00:03:23,560 --> 00:03:26,400 remember hearing somewhere that people read something like 4 66 00:03:26,400 --> 00:03:31,480 books a year and in the tech industry, less than one book a 67 00:03:31,480 --> 00:03:34,720 year on the tech industry itself, which makes me really 68 00:03:34,720 --> 00:03:37,080 sad. And you know, books aren't the 69 00:03:37,120 --> 00:03:40,880 only way to learn, but I think the general trend is people 70 00:03:40,880 --> 00:03:44,960 don't invest enough in just continuing to learn new things. 71 00:03:44,960 --> 00:03:47,600 And that for me has been the single biggest thing that has 72 00:03:47,600 --> 00:03:51,760 turned my career and, and let it grow, is just forcing myself to 73 00:03:51,760 --> 00:03:54,920 spend a little bit of time every week doing some sort of 74 00:03:54,920 --> 00:03:58,080 deliberate learning. And it's always fun, right? 75 00:03:58,080 --> 00:03:59,200 It's always something interesting. 76 00:03:59,200 --> 00:04:01,040 It it's not like I'm forcing myself to learn something I 77 00:04:01,040 --> 00:04:02,920 don't care about. I just go and pursue the things 78 00:04:02,920 --> 00:04:05,200 that kind of are intriguing. Oh, what's this technology that 79 00:04:05,200 --> 00:04:07,640 I read about over here? What's this kind of cool thing 80 00:04:07,640 --> 00:04:09,640 over there? And that can be by reading 81 00:04:09,640 --> 00:04:11,440 books, that can be by playing with code. 82 00:04:11,440 --> 00:04:13,400 In fact, it's better if you do a Little Mix of both. 83 00:04:13,400 --> 00:04:15,920 And just learning without doing doesn't quite work. 84 00:04:15,920 --> 00:04:18,399 And that's kind of the basis of most of my books. 85 00:04:18,399 --> 00:04:22,040 As you learn and you do, there's tons of like hands on examples. 86 00:04:22,760 --> 00:04:25,120 So that's probably the biggest thing is I would encourage folks 87 00:04:25,120 --> 00:04:29,160 it's just carve out somehow find the time to carve out every week 88 00:04:29,160 --> 00:04:31,520 to learn something. And I'll give just a couple 89 00:04:31,520 --> 00:04:35,560 examples of how that's had this just profound impact on my own 90 00:04:35,560 --> 00:04:38,440 career. One thing that I was just 91 00:04:38,640 --> 00:04:43,520 randomly curious about in that must have been like 2007, 2008, 92 00:04:43,520 --> 00:04:46,520 I started playing with CSSA lot at the time for building 93 00:04:46,520 --> 00:04:51,200 websites and decorating them. And I got curious and I'm going 94 00:04:51,200 --> 00:04:53,520 to skip all the technical details of it, but basically I 95 00:04:53,520 --> 00:04:55,960 ended up building in my spare time a little tool that had to 96 00:04:55,960 --> 00:04:58,360 do with like creating CSS sprites and things like that. 97 00:04:58,640 --> 00:05:02,400 There wasn't really good tooling around that, and I just did it 98 00:05:02,400 --> 00:05:03,320 because I thought it was interesting. 99 00:05:03,360 --> 00:05:05,320 There's no other reason I didn't do anything with it. 100 00:05:05,320 --> 00:05:06,800 It was just like a fun little hobby thing. 101 00:05:07,760 --> 00:05:11,360 As it happens, about a year later, I had an interview and 102 00:05:11,360 --> 00:05:14,320 questions around the stuff came up and I was literally able in 103 00:05:14,320 --> 00:05:17,000 the interview to bring up this tool to talk about it, to share 104 00:05:17,000 --> 00:05:19,880 with it, which was a big part of the reason I got my job at 105 00:05:19,880 --> 00:05:22,520 LinkedIn, which had a pretty profound impact on my career. 106 00:05:23,200 --> 00:05:25,480 And then I ended up meeting some of the folks that built some of 107 00:05:25,480 --> 00:05:28,560 the open source tooling like around Compass CSS, if anybody 108 00:05:28,560 --> 00:05:30,120 remembers that from back in the day. 109 00:05:30,560 --> 00:05:33,280 So just this random little project literally helped me get 110 00:05:33,280 --> 00:05:35,880 a job. Fast forward another five years 111 00:05:35,880 --> 00:05:38,720 or so working at LinkedIn and something that caught my 112 00:05:38,720 --> 00:05:41,600 curiosity at that time that I spend it just a bunch of time 113 00:05:42,160 --> 00:05:43,800 playing around. Honestly, that's what it feels 114 00:05:43,800 --> 00:05:44,760 like. It doesn't feel like learning. 115 00:05:44,760 --> 00:05:46,240 It feels like playing around with this stuff. 116 00:05:46,800 --> 00:05:48,640 I started looking at all sorts of web frameworks. 117 00:05:48,640 --> 00:05:51,320 I was looking at Ruby on Rails, and at the time there was a 118 00:05:51,360 --> 00:05:54,320 Groovy on Rails and all these different things. 119 00:05:54,880 --> 00:05:56,920 Kind of became knowledgeable on these things. 120 00:05:56,920 --> 00:06:00,440 And lo and behold, LinkedIn goes through this big dev OPS 121 00:06:00,440 --> 00:06:02,600 transformation, something maybe we'll chat about later. 122 00:06:02,920 --> 00:06:05,800 And one of the big things we end up doing there is changing the 123 00:06:05,840 --> 00:06:08,240 web framework that we use within the company. 124 00:06:08,720 --> 00:06:12,160 And I end up leading that whole project just because I had been 125 00:06:12,160 --> 00:06:14,400 playing with these things and I knew about more about it than 126 00:06:14,400 --> 00:06:20,000 most other folks. That project got me from kind of 127 00:06:20,000 --> 00:06:22,280 the application work that I've been doing as a software 128 00:06:22,280 --> 00:06:25,400 engineer into this DevOps infrastructure, soft software 129 00:06:25,400 --> 00:06:28,280 delivery side of the house, which then led to me starting a 130 00:06:28,280 --> 00:06:30,480 company in that space and writing books in that space. 131 00:06:30,480 --> 00:06:34,560 So these little things that are just kind of fun, but you know, 132 00:06:34,560 --> 00:06:38,720 I had to take time to do them, have completely caused my career 133 00:06:38,720 --> 00:06:41,360 to to change direction in in very positive ways. 134 00:06:42,120 --> 00:06:43,920 That's probably the biggest thing I can share with anybody. 135 00:06:44,000 --> 00:06:46,400 Take the time to learn. Don't stop learning as soon as 136 00:06:46,400 --> 00:06:48,480 you graduate from school or from college. 137 00:06:49,320 --> 00:06:51,840 Do you need to scale your engineering team or find 138 00:06:51,840 --> 00:06:55,280 specialized talent quickly? Finding good and experienced 139 00:06:55,280 --> 00:06:58,680 developers is hard, even for seasoned engineering leaders, 140 00:06:58,880 --> 00:07:02,400 and I've been there myself. The usual hiring cycles can take 141 00:07:02,400 --> 00:07:05,840 months while critical features sit in the backlog waiting to be 142 00:07:05,840 --> 00:07:08,160 implemented. Here's an alternative for you. 143 00:07:08,440 --> 00:07:11,800 Check out Lemon dot IO. Lemon dot IO is the go to 144 00:07:11,800 --> 00:07:15,320 platform for hiring top tier developers from Europe and Latin 145 00:07:15,320 --> 00:07:17,160 America. They can match you with 146 00:07:17,160 --> 00:07:21,280 experienced developers in just 48 hours or less, offering a 147 00:07:21,280 --> 00:07:24,080 fast, reliable and efficient hiring process. 148 00:07:24,560 --> 00:07:27,840 Lemon dot IO vets all their engineers through a rigorous 149 00:07:27,840 --> 00:07:31,880 process that involves 100% human check on every stage. 150 00:07:32,160 --> 00:07:36,560 And that's why only 1.2% of all candidates are on boarded and 151 00:07:36,560 --> 00:07:39,800 listed on the platform. And here's the interesting part, 152 00:07:40,200 --> 00:07:43,960 you work with lemon dot IO on a monthly basis with no pressure 153 00:07:44,080 --> 00:07:45,880 to commit for long term contracts. 154 00:07:46,280 --> 00:07:49,640 So go to lemon dot IO to find your experienced developers. 155 00:07:49,640 --> 00:07:53,400 Now you can search by role or by skill and they will find a match 156 00:07:53,400 --> 00:07:56,320 for you from within their thousands of vetted developers. 157 00:07:56,760 --> 00:08:00,760 And you can get 15% off for the first four weeks of work by 158 00:08:00,760 --> 00:08:03,640 mentioning Technical Journal when you reach out to them. 159 00:08:04,240 --> 00:08:07,480 So stop burning money. Hire developers smarter with 160 00:08:07,480 --> 00:08:10,640 lemon dot IO. Very interesting inside from 161 00:08:10,640 --> 00:08:12,400 your turning points in your career, right? 162 00:08:12,400 --> 00:08:15,720 So I think it's really key for everyone in the tech to actually 163 00:08:15,720 --> 00:08:18,440 spend time to learn, right, Because obviously these days 164 00:08:18,440 --> 00:08:21,520 tech moves so fast and especially there are so many 165 00:08:21,520 --> 00:08:24,520 plenty of technologies being invented being, you know, I 166 00:08:24,520 --> 00:08:27,480 don't know, maybe reinvented all over, you know, the time, right? 167 00:08:27,480 --> 00:08:30,040 So I guess without learning continuous learning, I think 168 00:08:30,040 --> 00:08:31,960 it's pretty hard to actually catch up. 169 00:08:32,400 --> 00:08:35,120 Maybe, I know it's probably to generalize, right? 170 00:08:35,120 --> 00:08:37,559 Maybe if you can give some tips for the techies here. 171 00:08:37,799 --> 00:08:39,760 How do you actually spend your time learning? 172 00:08:39,760 --> 00:08:42,760 Is it like every day you spend, I don't know, like focus time to 173 00:08:42,760 --> 00:08:45,720 actually read books? Or is there any kind of a tips 174 00:08:45,720 --> 00:08:48,840 that you would want to advise people to, you know, start their 175 00:08:48,840 --> 00:08:51,560 own learning so they can be able to maybe, I don't know, like 176 00:08:51,560 --> 00:08:53,040 improve themselves in their career? 177 00:08:54,160 --> 00:08:58,320 Yeah, there's two things that I do and exactly how I implement 178 00:08:58,320 --> 00:09:00,240 them has varied throughout my life. 179 00:09:00,240 --> 00:09:01,480 It'll be different for everybody. 180 00:09:01,840 --> 00:09:05,280 One, I used to have just a little tradition where like I'm 181 00:09:05,280 --> 00:09:07,560 a night owl, naturally. So this is something that has 182 00:09:07,560 --> 00:09:09,760 changed in my life. But for most of my life, I'd be 183 00:09:09,760 --> 00:09:12,440 up really, really late. And so one of the things I used 184 00:09:12,440 --> 00:09:14,640 to do is after everybody else around me, my girlfriend, 185 00:09:14,640 --> 00:09:17,920 everybody went to bed, I would carve out like 20 minutes to 186 00:09:17,920 --> 00:09:21,120 just either read something or watch an interesting video and 187 00:09:21,120 --> 00:09:25,720 then play with the technology. And So what, what this ends up 188 00:09:25,720 --> 00:09:29,040 looking like is I find that you learn really well if you both 189 00:09:29,040 --> 00:09:32,600 have a little bit of like theoretical conceptual learning 190 00:09:32,880 --> 00:09:35,200 and then you get to practice it on something very concrete. 191 00:09:35,680 --> 00:09:39,000 So I'd usually find some little project that I just wanted to 192 00:09:39,000 --> 00:09:40,440 do. And you don't have to like, no 193 00:09:40,440 --> 00:09:42,840 one has to see this thing. I have like dozens and dozens of 194 00:09:42,840 --> 00:09:44,840 little code snippets that will never see the light of day. 195 00:09:44,840 --> 00:09:47,280 And that's fine. Some of them, a handful of them 196 00:09:47,280 --> 00:09:49,640 made it through and I'll open source them or whatever else. 197 00:09:49,640 --> 00:09:51,160 But that, that doesn't have to be the goal. 198 00:09:51,840 --> 00:09:54,200 They're just something I wanted to try and play with. 199 00:09:54,200 --> 00:09:57,560 So I mentioned that CSS tool that was just purely a side 200 00:09:57,560 --> 00:09:59,280 project that never really saw the light of day. 201 00:09:59,560 --> 00:10:02,800 Whereas the web framework stuff, I actually built a little 202 00:10:02,800 --> 00:10:07,120 project using several different web frameworks and then actually 203 00:10:07,120 --> 00:10:08,880 ended up putting it in production with one of them, 204 00:10:09,200 --> 00:10:11,840 which was a Ruby on Rails thing. I put it on Heroku. 205 00:10:12,320 --> 00:10:15,560 But the whole point of that project was I wanted to do 206 00:10:15,560 --> 00:10:18,400 something, build something, but I didn't do it using stuff I 207 00:10:18,400 --> 00:10:20,200 already knew. I explicitly built it with 208 00:10:20,200 --> 00:10:22,520 things I hadn't used before as the way to learn them. 209 00:10:22,520 --> 00:10:25,640 So then I'd watch a video on Ruby on Rails and then I'd go 210 00:10:25,640 --> 00:10:27,200 and try to build something with Ruby on Rails. 211 00:10:27,240 --> 00:10:29,640 I'd watch a video on something or read a book on something and 212 00:10:29,640 --> 00:10:33,080 then go try to build something. So I think that's one of the key 213 00:10:33,080 --> 00:10:36,760 ingredients is just find that it's and it's not a lot of time. 214 00:10:36,760 --> 00:10:40,640 So this is the thing that really blows my mind is the difference 215 00:10:40,640 --> 00:10:45,160 between essentially 0 deliberate learning, which is I think where 216 00:10:45,160 --> 00:10:48,760 the average person is, versus somebody who just carves out an 217 00:10:48,800 --> 00:10:51,800 hour a week. You know, just find 20 minutes 218 00:10:51,800 --> 00:10:55,760 three times in a week sometime. The difference is tremendous 219 00:10:55,760 --> 00:10:57,480 because that stuff really, really adds up. 220 00:10:57,480 --> 00:10:59,800 It doesn't sound like much, but there's fifty weeks in a year. 221 00:11:00,120 --> 00:11:02,680 The years go by and all of a sudden you've spent hundreds or 222 00:11:02,680 --> 00:11:05,680 thousands of hours doing something that no one else 223 00:11:05,680 --> 00:11:07,520 around you is doing. And you look like you're some 224 00:11:07,520 --> 00:11:09,840 kind of amazing expert and you're like, I don't know, I was 225 00:11:09,840 --> 00:11:13,160 like in my pyjamas like like 2:00 in the morning, like 226 00:11:13,160 --> 00:11:15,760 playing with this thing. But you still are far ahead of 227 00:11:15,760 --> 00:11:19,360 everybody who isn't doing that. So that's one piece is to carve 228 00:11:19,360 --> 00:11:22,360 out that little bit of time when it is really various. 229 00:11:22,360 --> 00:11:24,680 I used to do it late at night. I'm no longer a night owl with 230 00:11:24,680 --> 00:11:27,240 kind of rework my schedule. Now I do it kind of a different 231 00:11:27,240 --> 00:11:28,440 time of day. It doesn't matter. 232 00:11:28,440 --> 00:11:31,800 Just find some little time. The one other thing that I would 233 00:11:31,800 --> 00:11:36,200 suggest that really makes this effective is to also, if you 234 00:11:36,200 --> 00:11:39,960 can, and this is a little bit of a bigger ask, but it has, it's 235 00:11:39,960 --> 00:11:43,440 even higher leverage in my opinion, Share what you learned 236 00:11:43,480 --> 00:11:46,720 with others. And that can be in the form of 237 00:11:46,720 --> 00:11:49,720 writing blog posts, that can be in the form of giving talks, 238 00:11:49,800 --> 00:11:53,400 doing podcasts, writing books, whatever you're able to do, 239 00:11:54,000 --> 00:11:57,280 share it. And this is something, I think 240 00:11:57,280 --> 00:12:00,840 it was a Steve Yegi blog post I read years and years ago. 241 00:12:01,440 --> 00:12:03,480 What are the biggest fears when I tell people, you know, start 242 00:12:03,480 --> 00:12:06,480 blogging, you know, start sharing what you know, is they 243 00:12:06,480 --> 00:12:07,760 say, but who's going to read my stuff? 244 00:12:07,760 --> 00:12:09,760 No ones going to want to read what I write, right? 245 00:12:09,760 --> 00:12:11,600 I'm, I'm not good at it. No one cares. 246 00:12:11,600 --> 00:12:13,560 Yeah, yeah, yeah. So first of all, that doesn't 247 00:12:13,560 --> 00:12:16,040 matter. You're sharing this stuff 248 00:12:16,040 --> 00:12:19,680 primarily for yourself. The act of trying to write down 249 00:12:19,680 --> 00:12:22,320 and share something that you learned will make you learn it 250 00:12:22,320 --> 00:12:24,200 better. It makes it stick better. 251 00:12:24,200 --> 00:12:26,880 It makes you, you know, you'll do a little bit of extra 252 00:12:26,880 --> 00:12:28,320 research. You'll connect it to some other 253 00:12:28,320 --> 00:12:29,520 concept you hadn't thought about. 254 00:12:29,520 --> 00:12:32,400 So the primary audience really is yourself. 255 00:12:32,760 --> 00:12:34,440 So even if no one reads it, that doesn't matter. 256 00:12:35,120 --> 00:12:38,960 But the reality is almost anybody can write something that 257 00:12:38,960 --> 00:12:41,360 will find at least a small audience. 258 00:12:41,480 --> 00:12:44,080 And this is this Steve Yankee blog post where he talks about 259 00:12:44,080 --> 00:12:49,520 this idea where we picture in our heads that other people know 260 00:12:49,520 --> 00:12:52,160 more than us, right? They have this giant mass of 261 00:12:52,160 --> 00:12:54,520 knowledge. And I only know this tiny little 262 00:12:54,520 --> 00:12:56,880 bit of the world. And that's not really what 263 00:12:57,440 --> 00:12:59,280 reality looks like. What reality looks like is 264 00:12:59,280 --> 00:13:02,280 everybody has these random, like a Venn diagram, random little 265 00:13:02,280 --> 00:13:05,320 circles of the world that they know, and then these huge, vast 266 00:13:05,320 --> 00:13:06,560 areas that we know nothing about. 267 00:13:07,080 --> 00:13:09,560 And everyone, everyone's collection of these little 268 00:13:09,560 --> 00:13:11,480 circles of what they know is different. 269 00:13:11,560 --> 00:13:13,840 And everyone has a different path for how they navigate 270 00:13:13,840 --> 00:13:16,760 through it. So if you start sharing what you 271 00:13:16,760 --> 00:13:20,560 know, you are going to find someone else out there who's on 272 00:13:20,560 --> 00:13:24,120 a similar path to you or on a path that benefits from what you 273 00:13:24,120 --> 00:13:27,840 know, but might not benefit from others writing because it's a 274 00:13:27,840 --> 00:13:32,200 different path. So you probably will find an 275 00:13:32,200 --> 00:13:35,280 audience, and by writing you will learn this stuff a lot 276 00:13:35,280 --> 00:13:37,840 better. And the other thing is you will 277 00:13:37,840 --> 00:13:41,440 again, get these really random, serendipitous, completely 278 00:13:41,440 --> 00:13:44,760 unpredictable impacts on your life, on your career. 279 00:13:45,280 --> 00:13:48,520 And I'll give again a couple examples from my own career. 280 00:13:49,240 --> 00:13:51,360 I'll give just one example because it's such a bizarre and 281 00:13:51,360 --> 00:13:55,520 unexpected 1. While I was at LinkedIn working 282 00:13:55,520 --> 00:13:58,000 on some of this web framework stuff, redoing Linkedin's 283 00:13:58,000 --> 00:14:01,200 infrastructure, I decided to start blogging about that on 284 00:14:01,240 --> 00:14:03,800 Linkedin's engineering blog. And so I was just writing and 285 00:14:03,800 --> 00:14:06,240 kind of sharing what I learned and it found a small audience of 286 00:14:06,240 --> 00:14:09,720 people that found it valuable. That led to a few talks, which 287 00:14:09,720 --> 00:14:12,080 was kind of cool. Got invited to some conferences. 288 00:14:12,720 --> 00:14:17,600 But the really unexpected 1 is I was at work one day and this guy 289 00:14:17,600 --> 00:14:19,800 who I've never seen before just comes up to my desk and he says, 290 00:14:19,800 --> 00:14:21,840 hey, you're, you've got any brickman, right? 291 00:14:21,840 --> 00:14:24,040 I'm like, yeah, you know, who are you? 292 00:14:24,520 --> 00:14:29,600 He's like, oh, I found your blog posts on this framework stuff 293 00:14:30,080 --> 00:14:32,160 and I read them and I really liked them. 294 00:14:32,160 --> 00:14:33,680 And I thought, oh, this is so cool. 295 00:14:33,960 --> 00:14:36,640 LinkedIn is doing this kind of cutting edge, interesting stuff. 296 00:14:37,120 --> 00:14:40,760 And that's what made me decide to be OK with LinkedIn acquiring 297 00:14:40,760 --> 00:14:42,440 my company. So this was a guy who had 298 00:14:42,440 --> 00:14:44,920 started a little startup and they got acquired by LinkedIn. 299 00:14:44,920 --> 00:14:47,800 And obviously this wasn't the only factor, but like, it kind 300 00:14:47,800 --> 00:14:49,800 of shared the culture and it made him excited. 301 00:14:49,800 --> 00:14:52,240 So I got to know the guy who's a really smart guy, really 302 00:14:52,240 --> 00:14:53,600 interesting. So first of all, that was just 303 00:14:53,600 --> 00:14:55,320 one random thing where I just connected with him. 304 00:14:56,200 --> 00:14:59,320 And believe it or not, a few years later, I leave LinkedIn, I 305 00:14:59,320 --> 00:15:01,960 start grunt work. And one of my absolute first 306 00:15:01,960 --> 00:15:05,120 customers is this guy. He had moved on to a different 307 00:15:05,120 --> 00:15:07,040 company. They needed some infrastructure 308 00:15:07,040 --> 00:15:08,960 work and they ended up hiring grunt work. 309 00:15:08,960 --> 00:15:11,400 And it's one of the customers that helped us get off the 310 00:15:11,400 --> 00:15:15,520 ground, honestly, as a company, all because and and he knew he 311 00:15:15,520 --> 00:15:18,280 could trust me and he met me and all of this all cuz like years 312 00:15:18,280 --> 00:15:20,760 and years ago, I'd taken a few hours to write a couple blog 313 00:15:20,760 --> 00:15:24,800 posts on some stuff I learned. So you never know where the 314 00:15:24,800 --> 00:15:28,240 stuff will go, but it probably will go somewhere. 315 00:15:28,240 --> 00:15:30,960 Almost everyone I talk to who regularly shares their work. 316 00:15:31,360 --> 00:15:33,680 And I'm sure you've seen this in your own career. 317 00:15:34,320 --> 00:15:37,720 It, it just has this weird, unexpected, profound impact. 318 00:15:38,080 --> 00:15:41,400 So yeah, I guess in terms of how to learn, find a little bit of 319 00:15:41,400 --> 00:15:44,840 time and then if you can, share what you learned with others. 320 00:15:45,960 --> 00:15:48,320 Thank you for sharing your interesting personal story, 321 00:15:48,320 --> 00:15:50,080 right? I think I can relate to some of 322 00:15:50,080 --> 00:15:51,600 what you've shared just now, right? 323 00:15:51,600 --> 00:15:54,600 So I think the first thing is cover time to actually do some 324 00:15:54,680 --> 00:15:56,760 kind of learning or maybe do some project, right? 325 00:15:56,960 --> 00:16:00,240 You can do some mini project even like I had one guest 326 00:16:00,240 --> 00:16:02,360 before, John Cricket coding challenges, right? 327 00:16:02,360 --> 00:16:05,160 He advised people to actually do some kind of mini project to 328 00:16:05,160 --> 00:16:07,800 actually get hands on experience and learn some fundamental 329 00:16:07,800 --> 00:16:09,600 concepts. And sometimes actually 330 00:16:09,680 --> 00:16:12,800 initially, if we cover up maybe 20 minutes, if you like that 331 00:16:12,800 --> 00:16:15,920 kind of project, you'll easily find time to actually do more 332 00:16:15,920 --> 00:16:17,920 because simply you enjoy what you do, right? 333 00:16:18,200 --> 00:16:21,240 And I think sharing definitely, yes, I find also the great tips 334 00:16:21,240 --> 00:16:23,840 just now you mentioned, right? Don't share it for other people. 335 00:16:23,840 --> 00:16:26,560 Share it for yourself first. So I think make yourself as the 336 00:16:26,560 --> 00:16:29,480 first audience. So one thing that I also pick 337 00:16:29,480 --> 00:16:31,560 interest from what you shared in the beginning, right? 338 00:16:31,560 --> 00:16:35,200 So you came from the application development background and then 339 00:16:35,200 --> 00:16:38,400 gradually, slowly moving into the infrastructure and you know, 340 00:16:38,400 --> 00:16:41,320 DevOps kind of world. I find some engineers actually 341 00:16:41,400 --> 00:16:44,960 are interested in doing this, although some people actually 342 00:16:45,280 --> 00:16:48,120 find it really hard because they are typically two different 343 00:16:48,120 --> 00:16:51,160 worlds all together, right? One is more like application 344 00:16:51,160 --> 00:16:53,800 design, system design and things like that, while infrastructure, 345 00:16:53,800 --> 00:16:56,680 maybe things like cloud, you know, data centers, you know, 346 00:16:56,720 --> 00:17:00,280 servers and things like that. So maybe from your experience as 347 00:17:00,280 --> 00:17:03,600 well, how do you actually bridge the gap between, you know, like 348 00:17:03,680 --> 00:17:06,480 knowing application development and then moving into 349 00:17:06,480 --> 00:17:09,000 infrastructure world? Because for some people, this is 350 00:17:09,000 --> 00:17:12,880 typically a hard thing to do. Yeah, that's a good question. 351 00:17:13,000 --> 00:17:18,160 So one thing that I'll say part of the reason I ended up on the 352 00:17:18,160 --> 00:17:22,079 infrastructure side of the world was I mentioned LinkedIn had all 353 00:17:22,079 --> 00:17:24,400 of these issues. Honestly with all of its, the, 354 00:17:24,640 --> 00:17:27,880 the term DevOps didn't really exist or had just appeared on 355 00:17:27,880 --> 00:17:28,960 the scene. So we didn't call it that. 356 00:17:28,960 --> 00:17:31,480 But we had issues delivering our software, right. 357 00:17:31,480 --> 00:17:34,240 We had a bunch of app developers who wrote code and built this 358 00:17:34,240 --> 00:17:37,880 stuff and then getting it out to users and running it and 359 00:17:37,880 --> 00:17:40,160 maintaining it and scaling it and securing it. 360 00:17:40,160 --> 00:17:42,400 Those were really, really, really tough. 361 00:17:42,400 --> 00:17:45,520 We struggle with that enormously, and so part of what 362 00:17:45,520 --> 00:17:47,680 got me in there was kind of being thrown into the middle of 363 00:17:47,680 --> 00:17:49,280 this and it's like, well, we got to fix it. 364 00:17:50,000 --> 00:17:52,320 Doesn't matter if you're an app developer, if we can't ship your 365 00:17:52,320 --> 00:17:54,160 code, it's not going to provide any value. 366 00:17:54,440 --> 00:17:55,880 So we got to fix how we ship code. 367 00:17:56,480 --> 00:17:59,880 In terms of learning it, I personally struggled 368 00:18:00,160 --> 00:18:04,600 tremendously to learn it. I found the space, especially 369 00:18:04,600 --> 00:18:09,240 back when I was starting to do this stuff, like 2011, that's 370 00:18:09,240 --> 00:18:11,680 roughly the time frame. So it's a little different now. 371 00:18:11,680 --> 00:18:14,720 But back then it was just legit hard. 372 00:18:14,720 --> 00:18:17,480 It seemed like there was this app development side of the 373 00:18:17,480 --> 00:18:20,400 world, which like takes a while to learn, but there seemed to be 374 00:18:20,400 --> 00:18:22,800 a lot of resources for understanding it and learning 375 00:18:22,800 --> 00:18:24,800 it. And then there was the other 376 00:18:24,800 --> 00:18:28,320 side of the house, which was just felt like magic, right? 377 00:18:28,320 --> 00:18:30,480 Like there's just these people that like literally knew these 378 00:18:30,480 --> 00:18:35,560 little magic incantations in Linux or in DNS or in whatever 379 00:18:35,560 --> 00:18:36,800 else. And then they would wave their 380 00:18:36,800 --> 00:18:40,240 wand and suddenly your app was running and then it would crash. 381 00:18:40,240 --> 00:18:41,480 And they're like out on vacation. 382 00:18:41,480 --> 00:18:43,920 You have no idea what to do about this. 383 00:18:44,680 --> 00:18:47,360 And it was, it was very frustrating, to be quite honest. 384 00:18:47,760 --> 00:18:50,040 So I kind of learned it the hard way. 385 00:18:50,840 --> 00:18:53,320 And I think a lot of people learn it the hard way. 386 00:18:53,320 --> 00:18:56,080 That is something breaks. You go through a tremendous 387 00:18:56,080 --> 00:18:58,040 amount of pain. You maybe fix it. 388 00:18:58,040 --> 00:18:59,320 You probably fixed it the wrong way. 389 00:18:59,320 --> 00:19:01,600 It'll probably break again. You'll be awake again at 4:00 in 390 00:19:01,600 --> 00:19:02,400 the morning. You'll fix it. 391 00:19:02,680 --> 00:19:04,480 And eventually you kind of figure out better and better 392 00:19:04,480 --> 00:19:07,720 ways to do it. But it was a slow and painful 393 00:19:07,720 --> 00:19:12,560 process, to be just honest, that one of the reasons I built grunt 394 00:19:12,560 --> 00:19:15,560 work is 'cause this stuff was driving me nuts. 395 00:19:15,720 --> 00:19:18,720 Like, it's a little weird to say, but I started a company to 396 00:19:18,720 --> 00:19:21,200 work on something that I just really didn't like. 397 00:19:21,920 --> 00:19:25,320 I just really did not like this aspect of software development 398 00:19:25,320 --> 00:19:29,440 where I'd have a great idea, I'd build it, I'd design it, we'd 399 00:19:29,560 --> 00:19:32,360 all be excited. And then you're like, oh, God, 400 00:19:32,360 --> 00:19:35,200 how do we get it out there in a way that's like not a security 401 00:19:35,200 --> 00:19:37,320 nightmare and like is maintainable, right? 402 00:19:37,320 --> 00:19:39,040 You can like, deploy it, but then how do you update it 403 00:19:39,040 --> 00:19:42,240 without breaking everything? It was just really, really tough 404 00:19:42,240 --> 00:19:43,520 space. And that's part of the 405 00:19:43,520 --> 00:19:46,480 motivation for building grunt work was all I could think to 406 00:19:46,480 --> 00:19:50,520 myself was there must be an easier way to do this. 407 00:19:51,240 --> 00:19:54,640 And this is also the motivation for writing this new book is I 408 00:19:54,640 --> 00:19:58,280 couldn't find a single kind of comprehensive resource for 409 00:19:58,280 --> 00:20:00,720 learning this stuff. As I said, I had to learn it the 410 00:20:00,720 --> 00:20:02,600 hard way. Piece it a little bit from here 411 00:20:02,600 --> 00:20:04,800 and a little bit from there, some from doing it wrong. 412 00:20:04,800 --> 00:20:07,520 OOP, I found a book that accidentally mentioned, oh, now 413 00:20:07,520 --> 00:20:10,320 I understand how to do this. This guy over here knows how to 414 00:20:10,320 --> 00:20:11,720 do it. This person over there knows how 415 00:20:11,720 --> 00:20:14,440 to do it. So I tried to, in this book, 416 00:20:14,440 --> 00:20:19,720 kind of bring together. A very hands on guide to the 417 00:20:19,720 --> 00:20:23,280 most common things you have to deal with to deliver software. 418 00:20:23,960 --> 00:20:27,360 There are a lot of resources these days on the DevOps side 419 00:20:27,400 --> 00:20:31,160 that will teach you the cultural aspects of DevOps, and I think 420 00:20:31,160 --> 00:20:33,760 that's also incredibly valuable and I do recommend reading 421 00:20:33,760 --> 00:20:35,080 those. At the end of the book, I have a 422 00:20:35,080 --> 00:20:38,640 whole set of recommended reading on a variety of topics including 423 00:20:38,640 --> 00:20:40,640 that. And so things like, you know, 424 00:20:40,640 --> 00:20:43,800 how do you structure your teams or how do you do a post mortem 425 00:20:44,120 --> 00:20:47,520 or how do you do things like error budgets and SLA's and 426 00:20:47,520 --> 00:20:50,320 SLO's and all of these things. And I think those are really 427 00:20:50,320 --> 00:20:52,800 valuable. But as far as I know, I still 428 00:20:52,800 --> 00:20:55,560 haven't found a single guide that's like, hey, you built an 429 00:20:55,560 --> 00:20:57,800 app, you know, here's your little Java app, your Ruby on 430 00:20:57,800 --> 00:21:01,040 Rails app, What's next? How do you put it on 431 00:21:01,040 --> 00:21:05,520 www.something.com so everyone can use it and it scales and 432 00:21:05,520 --> 00:21:08,320 it's secure, etcetera. So that was a big motivation for 433 00:21:08,320 --> 00:21:13,480 the book as well. So I guess my answer now in 2024 434 00:21:13,600 --> 00:21:15,760 for how to learn this stuff is, you know, get my book, 435 00:21:16,880 --> 00:21:20,440 obviously. And beyond that, there's a few 436 00:21:20,440 --> 00:21:22,440 other things that are quite valuable. 437 00:21:22,440 --> 00:21:24,720 I list, again, a whole bunch of them in the back of the book. 438 00:21:25,320 --> 00:21:28,640 There are a few guides, the cultural aspects of DevOps that 439 00:21:28,640 --> 00:21:33,040 I think are very solid, and there are a few online courses 440 00:21:33,040 --> 00:21:35,120 that do a decent job walking through things. 441 00:21:35,720 --> 00:21:38,400 Other than that, do it. Just practice it. 442 00:21:38,400 --> 00:21:42,240 Find some kind of a side project, find something at work, 443 00:21:42,240 --> 00:21:46,440 find some way where you need to deploy an application in front 444 00:21:46,440 --> 00:21:49,280 of other human beings and just start practicing it. 445 00:21:49,280 --> 00:21:51,840 And I think that'll make all these concepts kind of come 446 00:21:51,840 --> 00:21:55,200 together. So it's still not easy to learn. 447 00:21:55,480 --> 00:21:57,840 It's a little easier. And maybe with this book it can 448 00:21:57,840 --> 00:22:00,520 be a whole lot easier. And one of the things I write 449 00:22:00,520 --> 00:22:03,560 right in the preface of the book is I'm really, really hopeful 450 00:22:03,560 --> 00:22:06,720 that we're going to have a generation of application 451 00:22:06,720 --> 00:22:08,880 developers and infrastructure developers who can learn this 452 00:22:08,880 --> 00:22:12,880 stuff not the hard way. Because here's the other truth. 453 00:22:13,240 --> 00:22:16,960 When you have bugs in your application code, occasionally 454 00:22:16,960 --> 00:22:18,920 there's some pretty severe bugs. And we all have, you know, 455 00:22:18,920 --> 00:22:21,920 occasional nightmare stories, but usually they're minor 456 00:22:21,920 --> 00:22:23,880 things, they're annoying, and you kind of fix them. 457 00:22:24,400 --> 00:22:27,400 When you have bugs on the software delivery side, you tend 458 00:22:27,400 --> 00:22:28,960 to like, just take everything down. 459 00:22:29,720 --> 00:22:32,440 You tend to like, accidentally delete your production database. 460 00:22:32,440 --> 00:22:34,160 You tend to have a security breach, right? 461 00:22:34,160 --> 00:22:38,040 Like these are serious problems. So learning the stuff the hard 462 00:22:38,040 --> 00:22:41,120 way is not only just painful and unpleasant for you, it's also 463 00:22:41,120 --> 00:22:44,880 legit harmful for the software industry in general, right? 464 00:22:44,920 --> 00:22:48,080 Like we're building software in a way that isn't very secure, 465 00:22:48,080 --> 00:22:51,240 that isn't very reliable, that isn't very stable because people 466 00:22:51,240 --> 00:22:54,160 don't know how to do it. So I'm really hopeful that the 467 00:22:54,160 --> 00:22:57,240 next generation of folks that comes along will benefit from 468 00:22:57,240 --> 00:22:59,840 some of the stuff and maybe learn it just a little better 469 00:22:59,840 --> 00:23:02,920 than than what I had to do. Thanks for a good segue to 470 00:23:02,920 --> 00:23:05,160 actually explain the motivation behind your book, right? 471 00:23:05,160 --> 00:23:07,560 So I find also like for application developers, right? 472 00:23:07,720 --> 00:23:11,120 It is definitely very, very valuable if you also know the 473 00:23:11,120 --> 00:23:13,120 infrastructure or software delivery side, right? 474 00:23:13,120 --> 00:23:16,240 Because you cannot just write code and let someone else ship 475 00:23:16,240 --> 00:23:18,080 it, you know, like making it into production, right? 476 00:23:18,320 --> 00:23:21,240 If you actually know end to end how you can deliver your 477 00:23:21,240 --> 00:23:24,040 software to production and to users, even better, right? 478 00:23:24,040 --> 00:23:26,840 If you know how to scale it, if you know how to make it secure, 479 00:23:26,840 --> 00:23:29,440 right? And making sure how you can, you 480 00:23:29,440 --> 00:23:31,320 know, update, rollback and things like that. 481 00:23:31,480 --> 00:23:34,760 I think that will make you as a very, very valuable engineer. 482 00:23:34,880 --> 00:23:37,600 And those skills is really valuable in the industry. 483 00:23:38,080 --> 00:23:40,800 So I think you mentioned something about software 484 00:23:40,800 --> 00:23:43,560 delivery that is a hard thing to learn. 485 00:23:43,640 --> 00:23:46,240 You typically learn from your mistakes. 486 00:23:46,480 --> 00:23:49,120 And there are so many concepts, especially now you know, you 487 00:23:49,120 --> 00:23:52,800 have cloud, you have different products, different paradigms, 488 00:23:52,800 --> 00:23:56,040 like for example, VMS, containers, serverless and all 489 00:23:56,040 --> 00:23:58,600 that. I think there's just too many 490 00:23:58,600 --> 00:24:00,120 permutations for some people, right? 491 00:24:00,320 --> 00:24:03,200 And I think I find your book is pretty one of the rarest 492 00:24:03,280 --> 00:24:05,720 resources that you can actually use to learn because it's 493 00:24:05,720 --> 00:24:09,200 there's a mix of infrastructure related and there's a mix of 494 00:24:09,240 --> 00:24:12,040 application development and software delivery practices as 495 00:24:12,040 --> 00:24:14,000 well. So I highly encourage people who 496 00:24:14,000 --> 00:24:16,800 are interested in learning this to actually pick up your book 497 00:24:16,800 --> 00:24:18,520 and actually try to learn from there. 498 00:24:19,240 --> 00:24:22,200 So you mentioned about the story of LinkedIn, right? 499 00:24:22,200 --> 00:24:25,000 So initially they were struggling, you know, to deliver 500 00:24:25,200 --> 00:24:28,000 great software, right, in terms of, you know, scaling and all 501 00:24:28,000 --> 00:24:31,160 that. So what makes these kind of 502 00:24:31,160 --> 00:24:34,720 skills really valuable? So maybe if you can tell us why 503 00:24:34,720 --> 00:24:38,480 someone should learn how to deliver their software in a much 504 00:24:38,480 --> 00:24:40,360 better way. Yeah. 505 00:24:41,120 --> 00:24:44,960 So I'll add a little bit of context on this LinkedIn story 506 00:24:44,960 --> 00:24:47,000 and that that might help answer this question. 507 00:24:47,120 --> 00:24:52,040 So back in, it was around 2011 to some extent, LinkedIn was 508 00:24:52,040 --> 00:24:55,280 looking great. We had just had our initial 509 00:24:55,280 --> 00:24:58,120 public offering. The stock price was going way 510 00:24:58,120 --> 00:25:01,320 up. The product was doing great. 511 00:25:01,320 --> 00:25:04,200 We were adding something like 2 new members to the website every 512 00:25:04,200 --> 00:25:07,040 single second of the day. So it was just crazy hyper 513 00:25:07,040 --> 00:25:08,600 growth. It also sometimes felt like we 514 00:25:08,600 --> 00:25:11,320 were like hiring 2 employees every single second of the day 515 00:25:11,320 --> 00:25:13,600 because the company internally was also growth through hyper 516 00:25:13,600 --> 00:25:15,880 growth. So things seemed really, really 517 00:25:15,880 --> 00:25:18,320 good. Revenue was way up etcetera. 518 00:25:18,920 --> 00:25:22,480 But the reality was we got to the point with our software 519 00:25:22,480 --> 00:25:25,600 delivery practices where we could not deploy. 520 00:25:25,720 --> 00:25:28,880 And I don't mean hypothetically, I mean like in actual practice, 521 00:25:29,360 --> 00:25:31,680 what we were doing back then is there'd be a deployment once 522 00:25:31,680 --> 00:25:35,240 every two weeks. And so this was like this 523 00:25:35,280 --> 00:25:37,800 release train model. You know, if the train leaves 524 00:25:37,800 --> 00:25:40,240 the station, either you're on it or you got to wait for the next 525 00:25:40,240 --> 00:25:43,160 1-2 weeks from now. And so we had one of these. 526 00:25:43,160 --> 00:25:45,480 We did all the stuff, the release branch, etcetera, and 527 00:25:45,480 --> 00:25:49,840 then we went to deploy it and we rolled out a bunch of code and a 528 00:25:49,840 --> 00:25:53,080 whole bunch of things died and broke and crashed and things 529 00:25:53,080 --> 00:25:54,920 were pretty bad. So then we spent a bunch of time 530 00:25:54,920 --> 00:25:57,280 bringing everything back up and trying to fix the bugs and 531 00:25:57,280 --> 00:25:59,520 rolled out new code and that broke more stuff. 532 00:25:59,800 --> 00:26:02,120 And then we rolled out new code to fix those issues and that 533 00:26:02,120 --> 00:26:05,400 broke more stuff. And it went on for a day and 534 00:26:05,400 --> 00:26:09,240 into a second day. And we just could not stabilize 535 00:26:09,240 --> 00:26:10,560 the new code. And we literally just have to 536 00:26:10,560 --> 00:26:14,200 roll everything back and kind of patch things up and mostly get 537 00:26:14,200 --> 00:26:16,240 things back to working before the deployment started. 538 00:26:16,240 --> 00:26:18,640 So we literally could not deploy. 539 00:26:18,640 --> 00:26:20,840 Like we were completely, totally stuck. 540 00:26:21,640 --> 00:26:23,480 And so the company had no option. 541 00:26:23,680 --> 00:26:26,800 At this point, a new VP of engineering came in and he 542 00:26:26,800 --> 00:26:29,960 basically saw no other option. And we had to put all product 543 00:26:29,960 --> 00:26:33,360 development on hold completely. This was something called 544 00:26:33,360 --> 00:26:36,000 Project Inversion. You can Google it if you want a 545 00:26:36,000 --> 00:26:39,320 lot more of the details, but literally we just said no more 546 00:26:39,320 --> 00:26:41,440 product development. Every single person in the 547 00:26:41,440 --> 00:26:43,720 company, whether you're an app engineer, whether you're a 548 00:26:43,720 --> 00:26:47,360 designer, marketing, whatever, is going to go and work on 549 00:26:47,360 --> 00:26:51,040 internal stuff and tooling. And again, there was no DevOps 550 00:26:51,040 --> 00:26:53,320 term at the time, but that's basically what we're trying to 551 00:26:53,320 --> 00:26:55,160 figure out. It's like DevOps processes and 552 00:26:55,160 --> 00:26:59,160 software delivery practices until we could reliably and 553 00:26:59,160 --> 00:27:00,960 quickly and effectively ship code. 554 00:27:01,760 --> 00:27:07,640 So maybe the very first reason to learn software delivery is so 555 00:27:07,640 --> 00:27:10,480 you don't get into that state. That's not a good place to be. 556 00:27:10,560 --> 00:27:13,600 That's the kind of thing that put the entire company at risk. 557 00:27:14,000 --> 00:27:17,200 And we got through it and you know, we went from deploying 558 00:27:17,200 --> 00:27:21,360 once every two weeks or or not as the case may be, to deploying 559 00:27:21,360 --> 00:27:25,040 hundreds of times per day with far fewer outages and issues. 560 00:27:25,040 --> 00:27:27,160 So it ended up being a success story. 561 00:27:27,480 --> 00:27:29,920 A lot of good technology came out of that work, like Apache 562 00:27:29,920 --> 00:27:33,080 Kafka was developed at LinkedIn during this kind of period. 563 00:27:33,760 --> 00:27:37,080 It worked out OK, but it could have gone very, very poorly. 564 00:27:37,840 --> 00:27:40,800 And so that, that's one reason that it doesn't matter if you're 565 00:27:40,800 --> 00:27:43,560 app engineer or whatever your career is understanding some of 566 00:27:43,560 --> 00:27:47,200 these basics of software delivery, you, you don't want to 567 00:27:47,200 --> 00:27:48,920 go there. You don't want to get to the 568 00:27:48,920 --> 00:27:53,120 kind of the darkest long nights that you can get to. 2nd reason 569 00:27:53,120 --> 00:27:55,440 to learn it is honestly to be independent. 570 00:27:55,960 --> 00:28:00,080 There are companies where you can work, and I early in my 571 00:28:00,080 --> 00:28:02,200 career did this as well, where you're the app engineer, you 572 00:28:02,200 --> 00:28:04,960 build a thing and then you kind of toss it over the wall and 573 00:28:04,960 --> 00:28:07,240 again, somebody magically deploys it for you. 574 00:28:07,760 --> 00:28:09,720 That's actually more rare these days. 575 00:28:10,080 --> 00:28:13,080 But even if you are today at a company where that's the case, 576 00:28:13,800 --> 00:28:16,240 there's a real good chance you won't be tomorrow. 577 00:28:16,720 --> 00:28:18,720 One of those reasons is you might want to start your own 578 00:28:18,720 --> 00:28:21,240 company or a side project or something for fun. 579 00:28:21,800 --> 00:28:27,440 And so understanding how to take your app and do something useful 580 00:28:27,440 --> 00:28:29,600 with it so it works in production in a reasonable 581 00:28:29,600 --> 00:28:32,040 capacity is incredibly liberating. 582 00:28:32,120 --> 00:28:34,960 This is one of my favorite kind of discoveries as part of this 583 00:28:34,960 --> 00:28:38,040 process is all of a sudden I could take any idea I had and 584 00:28:38,040 --> 00:28:39,720 ship it, right? This is one of the things that 585 00:28:39,720 --> 00:28:42,080 gave me confidence to like start a company and also do a lot of 586 00:28:42,080 --> 00:28:45,360 other projects even before that. It's just understanding some of 587 00:28:45,360 --> 00:28:50,760 these real basic things. So being independent and these 588 00:28:50,760 --> 00:28:54,040 days more than ever, I think these days it's hard to get a 589 00:28:54,040 --> 00:28:56,560 startup noticed. So the marketing thing is still 590 00:28:56,560 --> 00:29:00,000 really, really hard, but oh man, is it easier to start a startup 591 00:29:00,000 --> 00:29:03,640 now than ever, ever before, because of the cloud, because of 592 00:29:03,640 --> 00:29:05,920 the technologies out there, because of the knowledge that's 593 00:29:05,920 --> 00:29:08,720 out there, because of the reach through the Internet, through 594 00:29:08,720 --> 00:29:12,400 mobile apps or things like this. It is easier than ever to start 595 00:29:12,400 --> 00:29:15,280 your own thing. But if you don't know how to 596 00:29:15,280 --> 00:29:17,480 deploy things, you're not going to go very far. 597 00:29:17,600 --> 00:29:20,360 So that's I think a real good second reason to learn this 598 00:29:20,360 --> 00:29:23,960 stuff. The third one is even if you're 599 00:29:23,960 --> 00:29:27,440 in a place where somebody else does the DevOps E software 600 00:29:27,440 --> 00:29:30,600 delivery stuff, for you to call it out frankly, and I can say 601 00:29:30,600 --> 00:29:33,640 this 'cause this was me early in my career, you are not a 602 00:29:33,640 --> 00:29:37,120 particularly good app developer if you don't understand how the 603 00:29:37,120 --> 00:29:39,680 stuff gets deployed and maintained on the site. 604 00:29:40,000 --> 00:29:42,440 The code you write is probably terrible. 605 00:29:43,280 --> 00:29:46,120 And again, I can say this because the code I was writing 606 00:29:46,120 --> 00:29:48,120 was terrible. I see that now. 607 00:29:48,600 --> 00:29:52,520 And you understand that once you understand things like you have 608 00:29:52,520 --> 00:29:54,760 to understand the architecture of your site, right? 609 00:29:54,760 --> 00:29:58,320 That is kind of the one of these places where app development and 610 00:29:58,320 --> 00:29:59,920 infrastructure development overlap. 611 00:30:00,760 --> 00:30:04,120 It's the architecture, right? Is there one copy of your app 612 00:30:04,160 --> 00:30:07,600 running in the world or are there 200 copies on different 613 00:30:07,600 --> 00:30:11,440 servers? Are you a single monolith or are 614 00:30:11,440 --> 00:30:14,600 you 127 micro services that communicate over the network? 615 00:30:14,840 --> 00:30:18,640 These have profound impacts on how you build your application. 616 00:30:19,240 --> 00:30:23,560 Security is another huge one. The amount of insecure code out 617 00:30:23,560 --> 00:30:26,360 there that exists just because people don't have the concepts 618 00:30:26,360 --> 00:30:30,160 of what is really happening on these servers is kind of 619 00:30:30,160 --> 00:30:34,360 terrifying for our industry. So that I think is a huge reason 620 00:30:34,360 --> 00:30:36,680 is you don't have to be an expert in this stuff. 621 00:30:36,680 --> 00:30:38,840 You don't have to go super, super deep like the people that 622 00:30:38,840 --> 00:30:40,880 are handling this. But if you are completely 623 00:30:40,880 --> 00:30:44,440 unaware of how code is deployed, scaled, you know what high 624 00:30:44,440 --> 00:30:47,280 availability means, things like CAP theorem, etcetera. 625 00:30:47,280 --> 00:30:49,800 If you're completely blind to those, you're going to be 626 00:30:49,800 --> 00:30:54,120 writing terrible, terrible application code and your career 627 00:30:54,120 --> 00:30:57,280 probably won't go very far. Your bosses won't be happy, your 628 00:30:57,280 --> 00:30:59,760 customers won't be happy. So I think that's a very 629 00:30:59,760 --> 00:31:02,400 compelling reason for everybody to learn at least a little bit 630 00:31:02,400 --> 00:31:04,000 from the other side of the house. 631 00:31:04,960 --> 00:31:07,320 I highly agree for your last point there, right. 632 00:31:07,320 --> 00:31:10,200 So if an application developer doesn't know how the code gets 633 00:31:10,200 --> 00:31:12,760 shipped skilled and being secured, right? 634 00:31:12,760 --> 00:31:15,920 So I think typically the the code that they wrote won't be 635 00:31:16,040 --> 00:31:18,800 that great simply because they don't know how to support the 636 00:31:18,800 --> 00:31:21,880 system later on, how what kind of issues that typically happen. 637 00:31:22,120 --> 00:31:24,840 And worse, they don't actually have ownership because they 638 00:31:24,880 --> 00:31:27,400 think their job is just to write code and somebody will operate 639 00:31:27,400 --> 00:31:28,920 that. So I think if you want to be a 640 00:31:28,920 --> 00:31:31,880 good software engineer, right, So make sure that you know how 641 00:31:31,880 --> 00:31:34,760 to deliver the software. And thank you for sharing your 642 00:31:34,960 --> 00:31:37,520 LinkedIn story as well. I find it really fascinating, 643 00:31:37,520 --> 00:31:39,280 right? So almost every company that 644 00:31:39,280 --> 00:31:42,560 goes big, right or whatever scale up out there, right, would 645 00:31:42,720 --> 00:31:45,320 face this challenge at, I don't know, a certain point in their, 646 00:31:45,480 --> 00:31:47,560 you know, life, right? So it typically they couldn't 647 00:31:47,560 --> 00:31:50,240 deploy, they couldn't scale when there are so many traffic and 648 00:31:50,240 --> 00:31:53,240 demands, they couldn't release new features or new updates or 649 00:31:53,240 --> 00:31:56,200 it takes a long while to actually deploy their features. 650 00:31:56,520 --> 00:31:58,880 So I think typically these are the turning points where company 651 00:31:58,880 --> 00:32:01,160 would invest a lot more in doing software delivery. 652 00:32:01,480 --> 00:32:04,280 And I'm sure we don't want to wait until that time before it 653 00:32:04,280 --> 00:32:07,600 actually happened, right? So I think the other thing that 654 00:32:07,600 --> 00:32:10,440 you mentioned in the book is something that I find really, 655 00:32:10,440 --> 00:32:13,640 really important to discuss here because typically when people 656 00:32:13,640 --> 00:32:15,680 talk about software delivery these days, there are so many 657 00:32:15,680 --> 00:32:17,880 technologies. OK, let's use Kubernetes, let's 658 00:32:17,880 --> 00:32:20,680 use, you know, serverless, let's use containers, let's use 659 00:32:20,680 --> 00:32:23,000 whatever, whatever technologies that are available out there. 660 00:32:23,000 --> 00:32:25,360 And they start, you know, even though it's a simple problem, 661 00:32:25,360 --> 00:32:27,760 they start with, you know, all these different technologies and 662 00:32:27,760 --> 00:32:30,160 techniques available. In your book, you mentioned this 663 00:32:30,160 --> 00:32:32,480 concept called minimum dose, right? 664 00:32:32,480 --> 00:32:35,560 Minimum kind of like MVP style, you know, like the the minimum 665 00:32:35,560 --> 00:32:37,680 thing that you need. So maybe tell us why this is 666 00:32:37,680 --> 00:32:40,560 important to actually think of software delivery in this 667 00:32:40,680 --> 00:32:45,560 manner. So one of the things that our 668 00:32:45,560 --> 00:32:50,760 industry is very much guilty of is following, we're like the 669 00:32:50,760 --> 00:32:54,400 fashion industry, right? Somebody puts A blog post out 670 00:32:54,400 --> 00:32:57,200 there that's like, look at this micro service architecture that 671 00:32:57,200 --> 00:33:00,360 Netflix moved to. And now you have thousands of 672 00:33:00,360 --> 00:33:03,080 developers that are like, we must do micro services like 673 00:33:03,080 --> 00:33:06,480 Netflix and then somebody else put something out about service 674 00:33:06,480 --> 00:33:08,520 meshes. And now everybody rushes to do 675 00:33:08,520 --> 00:33:10,240 service meshes. They're the hot new thing. 676 00:33:10,240 --> 00:33:13,760 And we kind of are following these trends, these things that 677 00:33:13,760 --> 00:33:17,880 sound cool and sexy and this like resume driven development, 678 00:33:17,880 --> 00:33:19,520 right? Oh, I have to put Kubernetes on 679 00:33:19,520 --> 00:33:22,080 my resume, right, to get hired. So we're all going to use 680 00:33:22,080 --> 00:33:25,880 Kubernetes. And I think what people really 681 00:33:25,880 --> 00:33:30,920 miss out on is context, right? Netflix, just to use them as an 682 00:33:30,920 --> 00:33:34,040 example, you know, when they move to microservices, there's a 683 00:33:34,040 --> 00:33:36,920 certain context in which that decision makes sense. 684 00:33:37,280 --> 00:33:40,120 And that context is typically in, in the sense that they have 685 00:33:40,120 --> 00:33:44,360 like thousands of developers working on just millions and 686 00:33:44,360 --> 00:33:47,160 millions of lines of code to serve hundreds of millions of 687 00:33:47,160 --> 00:33:50,760 customers to serve I don't know how many petabytes of data going 688 00:33:50,760 --> 00:33:52,280 through their systems and things like that. 689 00:33:52,800 --> 00:33:56,320 And within that context, the technical decisions that they're 690 00:33:56,320 --> 00:33:59,960 making are a good fit. If you are a three person 691 00:33:59,960 --> 00:34:03,320 startup trying to get off the ground and you have 0 customers, 692 00:34:03,880 --> 00:34:06,880 you don't have that context. And if you try to apply their 693 00:34:06,880 --> 00:34:11,880 solutions to this wrong context, it will be actively harmful. 694 00:34:12,199 --> 00:34:14,679 It'll be a really, really poor fit. 695 00:34:14,679 --> 00:34:18,159 And I've seen this again and again, the classic one is again, 696 00:34:18,159 --> 00:34:21,679 this like three person startup. They've 3 developers and they 697 00:34:21,679 --> 00:34:25,400 have like 37 microservices to manage and like a service mesh 698 00:34:25,400 --> 00:34:27,600 and they're using Kubernetes and all these fancy things. 699 00:34:28,440 --> 00:34:31,040 It's just not the right fit. Like the amount of complexity, 700 00:34:31,040 --> 00:34:33,800 like these things have a cost. They all have overhead, they all 701 00:34:33,800 --> 00:34:35,880 have drawbacks. Every technology, right? 702 00:34:36,080 --> 00:34:38,120 That's almost like the hallmark of a senior engineer. 703 00:34:38,159 --> 00:34:39,840 A junior engineer will tell you what's cool. 704 00:34:40,120 --> 00:34:42,600 The the senior engineer will tell you all the drawbacks to 705 00:34:42,600 --> 00:34:44,760 every single thing because all of them have drawbacks. 706 00:34:44,840 --> 00:34:48,280 Every single thing you use has advantages and drawbacks. 707 00:34:48,920 --> 00:34:53,000 And those drawbacks are worth it in a certain context like micro 708 00:34:53,000 --> 00:34:55,840 services have. And in the book I have like, I 709 00:34:55,840 --> 00:34:58,120 don't know how many pages of drawbacks to using microservices 710 00:34:58,120 --> 00:34:59,680 architectures. There's a huge number of 711 00:35:00,160 --> 00:35:04,560 drawbacks, but those are worth it in a certain context, you 712 00:35:04,560 --> 00:35:07,240 know, a la Netflix or Google or LinkedIn. 713 00:35:07,760 --> 00:35:09,480 They don't make sense in all contexts. 714 00:35:09,480 --> 00:35:13,000 So one of the things I talk about is you typically want the 715 00:35:13,000 --> 00:35:17,320 minimum effective dose. This is a term from medicine 716 00:35:17,840 --> 00:35:21,320 where in the world of medicine, if you take some kind of a pill, 717 00:35:21,920 --> 00:35:26,480 the reality is most medicines at the wrong dose will kill you. 718 00:35:27,600 --> 00:35:29,480 That's a reality. They'll be really bad for you. 719 00:35:29,840 --> 00:35:32,680 So you usually aim for the minimum effective dose. 720 00:35:32,680 --> 00:35:35,720 What's the smallest amount of this medicine I can take that 721 00:35:35,720 --> 00:35:38,440 gives me the benefits I'm looking for without all the 722 00:35:38,440 --> 00:35:40,360 drawbacks, without killing me, essentially. 723 00:35:41,120 --> 00:35:45,000 And you want the same thing with almost any technology choice, 724 00:35:45,120 --> 00:35:48,040 and that includes all of these dev OPS and software delivery 725 00:35:48,040 --> 00:35:50,240 processes. What's the smallest amount I can 726 00:35:50,240 --> 00:35:53,520 do that gives me the benefits I want while minimizing the 727 00:35:53,520 --> 00:35:56,920 drawbacks? So jumping to like a giant ultra 728 00:35:56,920 --> 00:35:59,320 super fancy microservices architecture, that's probably 729 00:35:59,320 --> 00:36:01,600 not the minimum effective dose, right? 730 00:36:01,600 --> 00:36:05,560 Sometimes you need to look and ask like, what's the concrete 731 00:36:05,560 --> 00:36:08,880 problem we are actually facing? So for example, if the problem 732 00:36:08,880 --> 00:36:12,840 is that you have an outage every time you do a deployment, maybe 733 00:36:12,840 --> 00:36:15,240 moving to a microservices architecture will help that. 734 00:36:15,240 --> 00:36:18,720 But maybe all you need is to automate your deployment, right? 735 00:36:18,720 --> 00:36:21,040 Maybe you need a little bit of infrastructure as code or some 736 00:36:21,040 --> 00:36:22,640 scripting or things like that, right? 737 00:36:23,200 --> 00:36:24,840 Maybe you need a better CICD pipeline. 738 00:36:24,840 --> 00:36:26,880 Maybe you just need better automated testing in your 739 00:36:26,880 --> 00:36:30,480 existing code. And the key thing is you want to 740 00:36:30,480 --> 00:36:35,040 invest as little as you can in the stuff and still get the 741 00:36:35,040 --> 00:36:36,800 benefits and minimize the drawbacks. 742 00:36:37,560 --> 00:36:40,280 Because here's the other thing I can tell you as a startup 743 00:36:40,280 --> 00:36:44,040 founder and someone that's, you know, seen the business world, 744 00:36:44,480 --> 00:36:48,440 your customers do not care what technologies you're using. 745 00:36:48,520 --> 00:36:51,560 None of them care if you're using Kubernetes or service 746 00:36:51,560 --> 00:36:53,800 meshes or whatever. Like they just don't care. 747 00:36:53,800 --> 00:36:55,920 It doesn't matter. Honestly, your investors 748 00:36:55,920 --> 00:36:57,720 probably don't care. Nobody cares. 749 00:36:58,280 --> 00:37:00,000 They just want something that works. 750 00:37:00,520 --> 00:37:05,160 And so every single minute that you invest in the under the hood 751 00:37:05,160 --> 00:37:07,960 stuff that isn't absolutely necessary is probably wasteful. 752 00:37:08,320 --> 00:37:11,520 Like most companies live or die based on the product, based on 753 00:37:11,520 --> 00:37:12,960 their ability to reach customers. 754 00:37:12,960 --> 00:37:16,560 So product I'm using is a broad umbrella for marketing, sales 755 00:37:16,560 --> 00:37:18,800 product, right? That's the stuff that matters. 756 00:37:18,800 --> 00:37:22,320 And if you get to the scale of a Netflix, yes, you're going to 757 00:37:22,320 --> 00:37:25,600 need to do a lot of crazy stuff in your architecture to make 758 00:37:25,600 --> 00:37:28,200 that product work. But it's the product. 759 00:37:28,200 --> 00:37:31,400 Like making that work is the real goal, not the under the 760 00:37:31,400 --> 00:37:33,760 hood craziness, the under the hood craziness. 761 00:37:33,800 --> 00:37:37,320 It's a cost. It's the cost you pay to support 762 00:37:37,320 --> 00:37:39,640 that product. So if you don't need to pay that 763 00:37:39,640 --> 00:37:42,280 cost, don't. Absolutely don't. 764 00:37:42,960 --> 00:37:45,640 So yeah, I talk about that quite in the book. 765 00:37:46,120 --> 00:37:50,000 I talk about how architectures and software delivery processes 766 00:37:50,000 --> 00:37:53,360 tend to evolve within companies because there's some very, very 767 00:37:53,360 --> 00:37:56,120 common patterns, right? Almost everybody starts with 768 00:37:56,120 --> 00:37:59,680 like the single monolithic app and maybe it's connected to a 769 00:37:59,680 --> 00:38:01,720 little database and that's it. And that's fine. 770 00:38:01,720 --> 00:38:04,360 That's actually the minimum effective dose to start out. 771 00:38:04,760 --> 00:38:08,200 There are tremendous businesses that use that architecture very 772 00:38:08,200 --> 00:38:11,880 successfully and there's not one compelling reason to make that 773 00:38:11,880 --> 00:38:13,800 any more complicated if they don't need to. 774 00:38:14,360 --> 00:38:17,080 But if you have to, right, If you now have millions of users, 775 00:38:17,080 --> 00:38:19,280 well, now you start to make it a little more complicated and you 776 00:38:19,280 --> 00:38:20,840 have some caches and you have some this. 777 00:38:20,840 --> 00:38:24,760 And eventually, usually not from scale in terms of customers, but 778 00:38:24,760 --> 00:38:27,560 from scale from the number of teams internally, then you might 779 00:38:27,560 --> 00:38:29,880 break the monolith into some services and then you could do 780 00:38:29,880 --> 00:38:33,080 service ownership. But you want to align your 781 00:38:33,080 --> 00:38:36,760 company to the right kind of stage in this evolutionary 782 00:38:36,760 --> 00:38:39,000 process. And it really, it does feel like 783 00:38:39,040 --> 00:38:40,440 evolution. It feels like growth. 784 00:38:40,680 --> 00:38:44,480 Every company just, we don't design, build our technology, 785 00:38:44,480 --> 00:38:47,360 right, It grows. And if you try to design and 786 00:38:47,360 --> 00:38:50,400 build it and jump 10 steps ahead, it usually doesn't work. 787 00:38:50,400 --> 00:38:52,400 And then you have to go back, you know, go back to the simple 788 00:38:52,400 --> 00:38:55,320 thing and let it grow. So yeah, think of it as the 789 00:38:55,320 --> 00:38:58,480 minimum effect of dosed. Think of it as incrementalism, 790 00:38:58,480 --> 00:39:01,720 which I can talk about at some point, maybe today, as the way 791 00:39:01,720 --> 00:39:03,120 you want to approach these things. 792 00:39:03,520 --> 00:39:06,120 Don't go for the technology because you read A blog post. 793 00:39:06,120 --> 00:39:09,400 That's not the best way to design your architecture, right? 794 00:39:09,680 --> 00:39:12,040 I think this is gold, right? For everyone who just listened 795 00:39:12,040 --> 00:39:14,680 to the explanation, right? So I think context is king, 796 00:39:14,720 --> 00:39:16,280 right? Whatever technologies that you 797 00:39:16,280 --> 00:39:18,320 read or whatever technologies that you learn, right? 798 00:39:18,560 --> 00:39:21,720 So obviously they will paint all the great stuff, but sometimes 799 00:39:21,720 --> 00:39:24,560 it has a cost associated behind it, be it for example, 800 00:39:24,560 --> 00:39:26,800 maintaining it, the skill set that you need to learn. 801 00:39:26,800 --> 00:39:29,120 Don't forget about that. And typically, right, it's not 802 00:39:29,120 --> 00:39:31,760 just, OK, I managed to run it the first, right? 803 00:39:31,760 --> 00:39:33,600 So there are many other things that you need to take care 804 00:39:33,600 --> 00:39:36,480 about, like for example, the administrative stuff, for 805 00:39:36,480 --> 00:39:39,480 example, if there are massive scales suddenly coming, do you 806 00:39:39,480 --> 00:39:41,760 know how to operate that in a most efficient manner? 807 00:39:42,040 --> 00:39:43,800 And also the security part, right? 808 00:39:43,800 --> 00:39:46,800 How do you secure the actual infrastructure and the thing 809 00:39:46,800 --> 00:39:48,480 that you use, right? I think that's also another 810 00:39:48,480 --> 00:39:51,680 thing that you should not forget and the people aspect don't 811 00:39:51,680 --> 00:39:54,680 forget when you operate in multiple microservices, you will 812 00:39:54,680 --> 00:39:57,880 probably need more people, right to actually help you maintain 813 00:39:57,880 --> 00:39:59,720 that. So definitely context is king 814 00:39:59,720 --> 00:40:01,720 and I really agree with you. Fully agree. 815 00:40:01,720 --> 00:40:06,240 If you're a small startup, don't start with the fancy kind of 816 00:40:06,240 --> 00:40:09,400 technologies. So I think definitely stage also 817 00:40:09,400 --> 00:40:13,480 matters because I think in most of the stories that I heard or 818 00:40:13,480 --> 00:40:16,440 read as well, there will be some time where you will need to 819 00:40:16,440 --> 00:40:18,760 split rewrite re architect, right? 820 00:40:18,760 --> 00:40:22,240 But that is associated with the growth or the success of the 821 00:40:22,240 --> 00:40:24,520 company, right? People like to kind of like go 822 00:40:24,520 --> 00:40:26,920 play their solution, right? They think, OK, we will succeed, 823 00:40:27,120 --> 00:40:29,760 but don't actually assume that you will reach that stage, 824 00:40:29,760 --> 00:40:31,560 right? So I think just wait until the 825 00:40:31,560 --> 00:40:34,160 growth happens and then you can adapt accordingly. 826 00:40:34,640 --> 00:40:37,000 So you mentioned about minimum effective dose. 827 00:40:37,080 --> 00:40:39,880 From your experience working with many infrastructure staff 828 00:40:39,880 --> 00:40:43,680 or DevOps, is there any other anti patterns or pitfall that 829 00:40:43,680 --> 00:40:45,280 you want to advise people to avoid? 830 00:40:46,040 --> 00:40:48,920 There's a whole bunch, and again, they're going to often be 831 00:40:49,040 --> 00:40:52,160 context specific. One of the ones that comes up 832 00:40:52,160 --> 00:40:54,600 quite often. I think you actually touched on 833 00:40:54,600 --> 00:40:58,320 it a little bit. I've seen this especially with 834 00:40:58,480 --> 00:41:02,080 the infrastructure's code space, but it comes up just about 835 00:41:02,080 --> 00:41:07,440 everywhere is somebody gets excited about a technology that 836 00:41:07,440 --> 00:41:11,320 they ostensibly adopted in the company, but they didn't 837 00:41:11,320 --> 00:41:14,440 actually do the legwork to get everyone bought in and to get 838 00:41:14,440 --> 00:41:18,720 everyone the time to learn and really master this technology. 839 00:41:19,400 --> 00:41:22,440 So in the infrastructures code space, this happens a lot. 840 00:41:22,600 --> 00:41:25,840 Somebody gets really excited about Terraform, open Tofu, 841 00:41:25,840 --> 00:41:30,720 Palumi, whatever kind of tech. And the most common pattern is 842 00:41:30,720 --> 00:41:33,680 there's just the one guy at the company who just loves it, and 843 00:41:33,680 --> 00:41:36,800 he brings it in and he writes tons and tons of code. 844 00:41:36,800 --> 00:41:39,560 And it's like, it could be amazing code and it's lovely and 845 00:41:39,560 --> 00:41:43,000 it's beautiful, but the rest of the team has no idea what that 846 00:41:43,000 --> 00:41:44,720 guy's doing. They haven't been given the time 847 00:41:44,720 --> 00:41:46,600 to learn. It's not something they've used 848 00:41:46,600 --> 00:41:50,520 before. And inevitably what happens is 849 00:41:50,640 --> 00:41:54,000 there's some sort of problem, an outage, something crashed, they 850 00:41:54,000 --> 00:41:57,280 need to fix it, and they don't know how to use the code to fix 851 00:41:57,280 --> 00:41:58,800 it. So what do they do? 852 00:41:58,880 --> 00:42:01,360 They fix it manually. Well, the thing with 853 00:42:01,360 --> 00:42:04,800 infrastructure's code and a lot of these tools is if you go and 854 00:42:04,800 --> 00:42:07,840 do something manual over here, well, now your code doesn't 855 00:42:07,840 --> 00:42:10,480 really reflect that. And the next time you try to use 856 00:42:10,480 --> 00:42:13,640 the code, it's going to run into issues because of this mismatch. 857 00:42:14,200 --> 00:42:17,040 So now the code doesn't work. So that even if somebody tries 858 00:42:17,040 --> 00:42:19,520 to do it the right way and use the code, they can't. 859 00:42:19,560 --> 00:42:20,800 They hit a bug, they hit a problem. 860 00:42:20,880 --> 00:42:23,640 So then they go and do some more stuff by hand, manually click 861 00:42:23,640 --> 00:42:27,080 UPS essentially, which makes the code even more problematic. 862 00:42:27,080 --> 00:42:29,920 And you know, rinse and repeat a couple times and suddenly the 863 00:42:29,920 --> 00:42:32,760 code doesn't work at all. And all of this work that this 864 00:42:32,760 --> 00:42:35,520 one guy did is essentially just throw it away and they have to 865 00:42:35,520 --> 00:42:37,480 start from scratch or do something different. 866 00:42:38,160 --> 00:42:40,200 And that's wasteful. And it's a shame. 867 00:42:40,200 --> 00:42:42,760 And people of course blame the infrastructure as code tool, but 868 00:42:42,760 --> 00:42:45,120 the reality is it's not really the tool. 869 00:42:45,120 --> 00:42:49,160 It's just that the team never had the time to adopt it, to buy 870 00:42:49,160 --> 00:42:52,760 into it, because it is. It's a genuine change in your 871 00:42:52,760 --> 00:42:54,840 process, right? You're taking folks that are 872 00:42:54,840 --> 00:42:58,080 used to like SSH ING to a server and running a bunch of commands 873 00:42:58,160 --> 00:43:00,320 as the way to do things. And you're asking them to like, 874 00:43:00,320 --> 00:43:04,360 go check out a repo, open it in an editor, find some piece of 875 00:43:04,360 --> 00:43:08,400 code, maybe run some tests, commit the code, maybe some more 876 00:43:08,400 --> 00:43:10,320 tests, run. Then there's some automated 877 00:43:10,320 --> 00:43:12,160 process, right? Like it's a completely different 878 00:43:12,160 --> 00:43:14,640 way of doing things and it has advantages. 879 00:43:14,840 --> 00:43:17,600 But if the team's not bought in, if they don't have the time to 880 00:43:17,600 --> 00:43:20,200 learn it, you're not going to gain those advantages, 881 00:43:20,200 --> 00:43:22,480 essentially. So that that has been something 882 00:43:22,480 --> 00:43:26,280 I've seen again and again and again, just not getting that 883 00:43:26,280 --> 00:43:30,560 full buy in and adoption. And that sometimes happens 884 00:43:30,560 --> 00:43:31,960 because there's one person excited. 885 00:43:32,160 --> 00:43:34,320 That sometimes happens because somebody at the top just 886 00:43:34,360 --> 00:43:36,920 mandates something, just marching orders. 887 00:43:36,920 --> 00:43:41,320 We will use technology X and everyone below them kind of 888 00:43:41,320 --> 00:43:44,120 shrugs and says, OK, but you know, they're not really bought 889 00:43:44,120 --> 00:43:47,520 in, so they don't do it. So that's usually, that's a 890 00:43:47,520 --> 00:43:50,120 very, very common pain point. And honestly, I would say you're 891 00:43:50,120 --> 00:43:53,640 better off not using the quote UN quote better technology if 892 00:43:53,640 --> 00:43:55,520 you don't have time to to do it properly. 893 00:43:55,560 --> 00:43:57,400 Like if you're going to do it, you need to do it the right way. 894 00:43:57,720 --> 00:44:00,000 Otherwise use your time for something else that's more 895 00:44:00,000 --> 00:44:02,080 valuable. Again, minimum effective dose. 896 00:44:02,880 --> 00:44:06,040 The second, I think closely related issue. 897 00:44:06,080 --> 00:44:09,040 And this also really, really ties into the minimum effective 898 00:44:09,040 --> 00:44:11,040 dose concept. And I mentioned incrementalism, 899 00:44:11,040 --> 00:44:14,840 so probably a good time to talk about it is the attempt to do 900 00:44:14,840 --> 00:44:20,200 The Big Bang migration, right. This usually happens from 901 00:44:20,200 --> 00:44:25,040 somebody above says we will move out of our on Prem data center 902 00:44:25,600 --> 00:44:28,760 in six months. And also we're going to adopt 903 00:44:28,760 --> 00:44:31,360 DevOps, whatever that means. And we're going to use 904 00:44:31,360 --> 00:44:33,240 Kubernetes and we're going to be cloud native. 905 00:44:33,240 --> 00:44:35,200 And it's like buzzword, buzzword, buzzword, buzzword, 906 00:44:35,600 --> 00:44:38,120 long list of things. And we have to do all the things 907 00:44:38,160 --> 00:44:40,840 all at once. And if you have any degree of 908 00:44:40,840 --> 00:44:42,520 complexity, right? Like in mostly, these are 909 00:44:42,520 --> 00:44:45,000 companies that have been around for a decade or two and they 910 00:44:45,000 --> 00:44:47,440 have, you know, millions of lines of code and lots of 911 00:44:47,440 --> 00:44:49,520 customers. Like you can't do that stuff 912 00:44:49,720 --> 00:44:52,040 quickly. And you don't even want to try 913 00:44:52,040 --> 00:44:56,520 to do it as one giant kind of ball of mud essentially is what 914 00:44:56,520 --> 00:44:59,200 it turns into trying to do everything at once. 915 00:44:59,200 --> 00:45:02,960 Trying to do like a massive rewrite usually ends poorly. 916 00:45:02,960 --> 00:45:05,520 And I would say usually, But if I'm being completely honest, I 917 00:45:05,520 --> 00:45:08,960 would say 100% of the time, every single one of these large 918 00:45:08,960 --> 00:45:11,600 companies, and I've had the privilege to work at this point 919 00:45:11,600 --> 00:45:14,920 with probably over 1000 different companies, I've not 920 00:45:14,920 --> 00:45:18,720 seen a single one of these big projects completed on time, on 921 00:45:18,720 --> 00:45:23,920 budget, or usually at all. What I typically recommend is to 922 00:45:23,920 --> 00:45:27,680 do things incrementally. And the best way to understand 923 00:45:27,680 --> 00:45:29,680 the word incrementally, because it's this is one that's very 924 00:45:29,680 --> 00:45:31,800 easy to misinterpret. A lot of people here 925 00:45:31,800 --> 00:45:34,400 incrementally and they just think, OK, chop it up into small 926 00:45:34,400 --> 00:45:37,000 pieces and that's not really what it means. 927 00:45:37,360 --> 00:45:39,760 So to understand what incrementally means, the most 928 00:45:39,760 --> 00:45:42,440 useful way to do it is to look at the opposite, which is false 929 00:45:42,720 --> 00:45:45,880 incrementalism. False incrementalism is where 930 00:45:45,880 --> 00:45:50,560 you take a project and you slice it up into small pieces, but 931 00:45:50,560 --> 00:45:55,000 until the very last item is delivered, the project does not 932 00:45:55,000 --> 00:45:58,560 provide any value whatsoever. So if you're doing this big 933 00:45:58,560 --> 00:46:00,880 rewrite where you got to rewrite, maybe the way your 934 00:46:00,880 --> 00:46:03,520 front end app works and the way the back end app works, and the 935 00:46:03,520 --> 00:46:05,840 way you deliver these apps and the way you secure these apps. 936 00:46:06,200 --> 00:46:09,720 And until every, and even though you could do these as one piece, 937 00:46:09,720 --> 00:46:11,960 and that's what a lot of people think of with incrementalism, 938 00:46:12,440 --> 00:46:15,200 but until they're all done, you can't actually ship it live. 939 00:46:15,200 --> 00:46:16,880 You can't put any production traffic in it. 940 00:46:17,400 --> 00:46:20,200 That's not incrementalism. That is a Big Bang migration 941 00:46:20,200 --> 00:46:23,120 that you just happen to do in little pieces, but you got 0 942 00:46:23,120 --> 00:46:25,800 value until the very last item is delivered. 943 00:46:26,640 --> 00:46:30,480 And that's a really, really risky way to approach a project. 944 00:46:30,600 --> 00:46:35,480 Cause in the tech industry, large projects almost always 945 00:46:35,760 --> 00:46:37,200 fail. They just, they don't get 946 00:46:37,200 --> 00:46:39,000 completed. And there's a million reasons 947 00:46:39,000 --> 00:46:40,520 for that. We're not going to have the time 948 00:46:40,520 --> 00:46:42,840 to dig into them. But the most common one honestly 949 00:46:42,840 --> 00:46:46,080 is people just lose patience. The CEO says, yes, you can do 950 00:46:46,080 --> 00:46:49,440 that rewrite, but after 18 months of waiting for your 951 00:46:49,440 --> 00:46:51,440 rewrite to complete, they're like, no, we got a business to 952 00:46:51,440 --> 00:46:53,120 run. Your rewrite has been cancelled, 953 00:46:53,120 --> 00:46:55,680 right? And if at 18 months is that, you 954 00:46:55,680 --> 00:46:58,200 know, that person upstairs says you're done, you're out of time. 955 00:46:58,560 --> 00:47:01,200 If you haven't gotten any value from your work, well, 956 00:47:01,200 --> 00:47:03,640 congratulations, you just threw away 18 months and you got 957 00:47:03,640 --> 00:47:05,920 nothing in return. That's the worst possible 958 00:47:05,920 --> 00:47:08,640 outcome. So the better approach is to use 959 00:47:08,680 --> 00:47:11,520 actual incrementalism. And the key is you don't just 960 00:47:11,520 --> 00:47:15,440 chop it up into pieces, but each of those pieces must be 961 00:47:15,440 --> 00:47:20,600 something you can deliver and get value from by itself, even 962 00:47:20,600 --> 00:47:22,200 if the other pieces never happen. 963 00:47:22,720 --> 00:47:26,040 That is real incrementalism. So you're able to do 1 little 964 00:47:26,040 --> 00:47:28,920 thing, and if the rest of the project is cancelled, well, that 965 00:47:28,920 --> 00:47:31,440 little thing was still worth doing. 966 00:47:31,440 --> 00:47:33,680 It's still made your company better in some way. 967 00:47:34,240 --> 00:47:36,920 That's the way to approach this, to approach these things that 968 00:47:37,080 --> 00:47:38,640 actually works in the real world. 969 00:47:39,320 --> 00:47:44,040 And in practice, what that translates into is you look for 970 00:47:44,240 --> 00:47:47,720 concrete, specific pain points that your company is facing. 971 00:47:48,040 --> 00:47:50,880 You don't look to do DevOps, you don't look to do cloud 972 00:47:50,880 --> 00:47:52,440 migrations. These are solutions. 973 00:47:52,840 --> 00:47:56,840 You look for problems. The problems might be outages. 974 00:47:56,840 --> 00:47:59,040 The problems might be security problems. 975 00:47:59,320 --> 00:48:01,960 The problems might be that your team is really slow, like you're 976 00:48:01,960 --> 00:48:04,200 not agile or you're not delivering software as quickly, 977 00:48:04,200 --> 00:48:06,800 right? And you fix 1, whatever that 978 00:48:06,800 --> 00:48:10,640 most painful problem is, you fix one at a time and you fix it all 979 00:48:10,640 --> 00:48:12,400 the way. And then you go to the next 980 00:48:12,400 --> 00:48:16,520 highest priority problem and you pick the minimum effective dose 981 00:48:16,520 --> 00:48:21,400 to solve each of these problems. So if the team is slow, maybe 982 00:48:21,400 --> 00:48:24,560 what you need to do is to deploy more often, or maybe you need to 983 00:48:24,560 --> 00:48:27,760 test in production, or maybe you need to change the web 984 00:48:27,760 --> 00:48:30,280 framework, right? And you have to find out why is 985 00:48:30,280 --> 00:48:32,360 the team slow, which is the most important thing you can ask. 986 00:48:32,360 --> 00:48:33,920 The answer isn't just do DevOps, right? 987 00:48:33,920 --> 00:48:37,240 Like there's a cause and you want to fix that very specific 988 00:48:37,240 --> 00:48:39,360 cause. So that's the approach I 989 00:48:39,360 --> 00:48:41,920 recommend. Go find very, very specific 990 00:48:41,920 --> 00:48:45,400 problems, fix those very, very specific problems, and then just 991 00:48:45,400 --> 00:48:47,800 repeat the process over and over and over. 992 00:48:48,240 --> 00:48:51,240 And eventually you'll have something where you maybe are 993 00:48:51,240 --> 00:48:53,280 using the cloud or infrastructure coders, whatever, 994 00:48:53,760 --> 00:48:57,280 but you get there in a way where every single step has delivered 995 00:48:57,280 --> 00:49:00,840 a little bit of value, which makes the person upstairs happy, 996 00:49:01,280 --> 00:49:04,120 which makes you happy and actually makes your company more 997 00:49:04,160 --> 00:49:07,640 successful, even if eventually somebody runs out of patience 998 00:49:07,640 --> 00:49:09,160 and you're not allowed to do any more of those. 999 00:49:10,160 --> 00:49:12,600 Well, I think those are really great learning points, right? 1000 00:49:12,600 --> 00:49:14,920 The first is about bringing people in, you know, getting the 1001 00:49:14,920 --> 00:49:17,400 buy in, making sure they follow the journey, right? 1002 00:49:17,400 --> 00:49:20,120 And not something that just few people want to champion. 1003 00:49:20,120 --> 00:49:22,120 But then it dies off after some time, right? 1004 00:49:22,440 --> 00:49:24,480 Incrementalism. Thanks for explaining the 1005 00:49:24,480 --> 00:49:27,160 concept, right, the false incrementalism and the true 1006 00:49:27,160 --> 00:49:29,720 incrementalism. And the last thing is probably 1007 00:49:30,040 --> 00:49:33,680 find from the pinpoints first the problems rather than, you 1008 00:49:33,680 --> 00:49:36,400 know, implementing from buzzwords or resume driven 1009 00:49:36,400 --> 00:49:38,880 development. So speaking about, you know, 1010 00:49:38,880 --> 00:49:42,840 some of these evolution, right? So I know that recently we have 1011 00:49:42,840 --> 00:49:45,680 this AI and so many other new cool technologies coming. 1012 00:49:45,680 --> 00:49:48,320 What do you think is the future of dev OPS and software 1013 00:49:48,320 --> 00:49:50,480 delivery? Maybe you have some crystal ball 1014 00:49:50,480 --> 00:49:56,200 here that you can share. Yeah, the very last chapter in 1015 00:49:56,200 --> 00:49:58,480 the book. I try to take some guesses at 1016 00:49:58,480 --> 00:50:00,160 some interesting trends that are coming. 1017 00:50:00,680 --> 00:50:02,880 I'll put a big caveat here. Anytime you try to guess the 1018 00:50:02,880 --> 00:50:06,240 future like you're hilariously wrong and that's OK. 1019 00:50:06,760 --> 00:50:08,920 I don't mind being wrong. I think this is just interesting 1020 00:50:08,920 --> 00:50:11,800 to look at and kind of what what are the kind of cool trends that 1021 00:50:11,800 --> 00:50:13,960 are coming out? And my guess is a few of these 1022 00:50:13,960 --> 00:50:16,760 will be kind of interesting and then it really what'll happen is 1023 00:50:16,760 --> 00:50:19,960 something none of us saw coming will be the big thing and that's 1024 00:50:19,960 --> 00:50:22,200 fine. So what are some of the trends 1025 00:50:22,200 --> 00:50:24,840 that I, I've been seeing? I'll list a few of them, 1026 00:50:25,160 --> 00:50:26,840 probably won't have time to get into all of them. 1027 00:50:26,840 --> 00:50:31,760 But the first one, and I think it's the pattern that kind of is 1028 00:50:31,760 --> 00:50:35,520 we're going to see through all the trends is this idea towards 1029 00:50:35,520 --> 00:50:38,800 a move to higher and higher level abstractions. 1030 00:50:39,320 --> 00:50:42,120 The analogy that I use is if you look at the history of 1031 00:50:42,120 --> 00:50:45,440 programming languages, what we've seen is a move to higher 1032 00:50:45,440 --> 00:50:47,040 and higher level programming languages. 1033 00:50:47,040 --> 00:50:50,440 So you started with, you know, binary machine code, you moved 1034 00:50:50,440 --> 00:50:53,320 on to assembly languages, you moved on to, you know, things 1035 00:50:53,320 --> 00:50:57,800 like C, eventually Java, and then, you know, these days Scala 1036 00:50:57,800 --> 00:51:00,040 and even more modern languages over the last few years. 1037 00:51:00,840 --> 00:51:05,400 And at each level, a couple things happen. 1, you give up 1038 00:51:05,600 --> 00:51:08,760 some degree of low level control and power, right? 1039 00:51:08,800 --> 00:51:11,720 And we can all hear like the C programmers yelling at Java 1040 00:51:11,720 --> 00:51:14,480 programmers, you know, hey, I can't control memory the way I 1041 00:51:14,480 --> 00:51:16,040 want to. And, you know, I need this 1042 00:51:16,040 --> 00:51:17,840 control. And they're right, right. 1043 00:51:18,560 --> 00:51:21,760 For some percentage of applications, if you need that 1044 00:51:21,760 --> 00:51:23,640 control, yeah, stick with a lower language. 1045 00:51:24,560 --> 00:51:28,080 But in reality, the vast majority of use cases don't need 1046 00:51:28,080 --> 00:51:30,920 the lower level control. And so the second thing that 1047 00:51:30,920 --> 00:51:33,600 happens with these higher level languages is they make it 1048 00:51:33,600 --> 00:51:36,400 easier, they make it faster, they make it more productive to 1049 00:51:36,400 --> 00:51:39,120 do what you need to do when you don't need the lower level 1050 00:51:39,320 --> 00:51:42,040 control over things. And so that makes programming 1051 00:51:42,040 --> 00:51:44,680 more accessible to more people and that lets us build things 1052 00:51:44,680 --> 00:51:47,200 faster. And so that's why the whole 1053 00:51:47,200 --> 00:51:50,400 industry gradually is shifting towards higher level languages. 1054 00:51:50,600 --> 00:51:53,200 Never 100%, you know, there's still code being written in C 1055 00:51:53,200 --> 00:51:56,080 and machine code and assembly, and there will be for a long 1056 00:51:56,080 --> 00:51:59,360 time, but the majority of developers gradually move to 1057 00:51:59,360 --> 00:52:03,000 these higher level languages. I think the same thing is 1058 00:52:03,320 --> 00:52:06,280 happening and will continue to happen in the DevOps and 1059 00:52:06,280 --> 00:52:08,960 software delivery space we moved from. 1060 00:52:09,040 --> 00:52:11,960 You know, I need to buy a physical server and shove it in 1061 00:52:11,960 --> 00:52:15,200 a rack and deploy my software on it and hook up cables and all 1062 00:52:15,200 --> 00:52:20,120 this stuff to the cloud using virtual machines to the cloud 1063 00:52:20,120 --> 00:52:23,400 using containers to now serverless where it's not even 1064 00:52:23,400 --> 00:52:24,640 containers. It's kind of this little 1065 00:52:24,640 --> 00:52:27,920 deployment package and I think there's going to be, we're going 1066 00:52:27,920 --> 00:52:30,160 to keep climbing that abstraction ladder. 1067 00:52:30,560 --> 00:52:33,040 I don't have a good name for it. I kind of pitched this idea of 1068 00:52:33,120 --> 00:52:36,800 infrastructureless, which is the next evolution from serverless. 1069 00:52:36,800 --> 00:52:38,600 So serverless today is pretty close. 1070 00:52:38,600 --> 00:52:41,720 And if I was a betting man, and again, I could be hilariously 1071 00:52:41,720 --> 00:52:44,680 wrong here, but if I was a betting man, I think the future 1072 00:52:44,680 --> 00:52:47,920 is going to look a lot, lot more like serverless than it does 1073 00:52:48,000 --> 00:52:50,720 like Kubernetes, for example. I don't think Kubernetes is the 1074 00:52:50,720 --> 00:52:52,120 long term direction of the industry. 1075 00:52:52,880 --> 00:52:55,880 And when I say serverless, you know what, what we have today is 1076 00:52:55,880 --> 00:52:57,560 you kind of hand it a deployment package. 1077 00:52:57,560 --> 00:53:00,120 Here's a little piece of code, sometimes a function with an 1078 00:53:00,120 --> 00:53:03,320 entry point and you say please run it when a certain trigger 1079 00:53:03,320 --> 00:53:05,560 happens, like an HTTP request comes in. 1080 00:53:05,960 --> 00:53:07,200 So that's pretty high level, right? 1081 00:53:07,240 --> 00:53:08,920 Here's code, you go figure out how to run it. 1082 00:53:08,960 --> 00:53:12,240 I don't want to be bothered with the details, but in practice, 1083 00:53:12,240 --> 00:53:15,800 I'm still bothered with an awful lot of details with serverless. 1084 00:53:15,800 --> 00:53:17,520 I still have to think about, you know, if you're using, for 1085 00:53:17,520 --> 00:53:21,120 example, Lambda in AWS, you still have to think about AWS 1086 00:53:21,120 --> 00:53:22,520 accounts. You still have to think about 1087 00:53:22,520 --> 00:53:25,160 the networking aspects. You still think have to think 1088 00:53:25,160 --> 00:53:28,840 about provisioning, concurrency. If you need to talk to a 1089 00:53:28,840 --> 00:53:31,040 database, you have to think about how to do long running 1090 00:53:31,040 --> 00:53:33,520 connections with server. So there's just a bunch of 1091 00:53:34,080 --> 00:53:35,960 infrastructure stuff that is still left. 1092 00:53:36,560 --> 00:53:38,920 I think when we go from serverless to the concept of 1093 00:53:38,920 --> 00:53:41,400 infrastructure list, and just as a reminder, serverless doesn't 1094 00:53:41,400 --> 00:53:43,680 mean there aren't servers, There's obviously still servers 1095 00:53:43,680 --> 00:53:45,680 and infrastructure list doesn't mean there isn't infrastructure. 1096 00:53:45,680 --> 00:53:48,120 It's still there. It's just not something you have 1097 00:53:48,120 --> 00:53:50,600 to think about as a developer on a regular basis. 1098 00:53:50,600 --> 00:53:54,360 You give up some control, right? I can't control what's happening 1099 00:53:54,360 --> 00:53:56,600 under the hood, and in certain use cases that'll be a problem 1100 00:53:56,600 --> 00:53:58,320 and I won't be able to use it, and that's OK. 1101 00:53:58,880 --> 00:54:01,600 But for the majority of use cases, I don't need that 1102 00:54:01,600 --> 00:54:03,880 control. I instead just want to hand you 1103 00:54:03,880 --> 00:54:07,080 some code and say you go figure out how to run it, how to scale 1104 00:54:07,080 --> 00:54:10,480 it, how to secure it, how to handle a lot of these details. 1105 00:54:11,200 --> 00:54:13,880 So I think that's what we're going to, I think serverless is 1106 00:54:13,880 --> 00:54:16,800 like a very early glimpse of what that can look like. 1107 00:54:17,160 --> 00:54:20,160 And you can tell it's not a very mature technology yet. 1108 00:54:20,160 --> 00:54:22,680 So there's all these like problems and drawbacks to using 1109 00:54:22,680 --> 00:54:24,960 it. But it really it like, to me, it 1110 00:54:24,960 --> 00:54:27,880 smells like the future. And I think if you extrapolate 1111 00:54:27,880 --> 00:54:30,560 it out, things are going to look much more like that and kind of 1112 00:54:30,560 --> 00:54:32,920 turn into this infrastructureless thing for the 1113 00:54:32,920 --> 00:54:35,800 most companies, not everyone. There will always be companies 1114 00:54:35,800 --> 00:54:38,040 that need the lower level control and they'll stick with 1115 00:54:38,080 --> 00:54:40,120 either running their own servers or something a little lower 1116 00:54:40,120 --> 00:54:42,720 level, but most use cases will move on. 1117 00:54:43,360 --> 00:54:45,480 So I think that's one interesting pattern. 1118 00:54:45,960 --> 00:54:49,800 A second one I'll talk about 3, I guess a second one that I 1119 00:54:49,800 --> 00:54:52,040 think is interesting, and I get questions about this all the 1120 00:54:52,040 --> 00:54:57,160 time, is what's the impact of AI on the infrastructure and DevOps 1121 00:54:57,160 --> 00:54:59,720 world? And when they talk about AI, 1122 00:54:59,720 --> 00:55:02,480 they're usually referring to these large language models, 1123 00:55:02,480 --> 00:55:06,000 LLMS, the things like ChatGPT and technologies of that sort. 1124 00:55:06,880 --> 00:55:09,560 I'm not an expert on this AI stuff, so I will put that right 1125 00:55:09,560 --> 00:55:11,360 out there. My experience is with using a 1126 00:55:11,360 --> 00:55:14,280 whole bunch of them and usually tearing out a lot of hair with 1127 00:55:14,280 --> 00:55:17,680 it. I think there's some early 1128 00:55:17,960 --> 00:55:20,840 enthusiasm from folks that are saying, OK, AI is going to 1129 00:55:20,840 --> 00:55:23,240 replace us. It's going to write all the code 1130 00:55:23,240 --> 00:55:26,280 for us. It's so productive to me. 1131 00:55:26,560 --> 00:55:29,560 Again, could be hilariously wrong, but that strikes me as 1132 00:55:29,560 --> 00:55:35,480 less likely to be our future, and especially in the DevOps and 1133 00:55:35,480 --> 00:55:38,600 infrastructure world. The reason I say that is the 1134 00:55:38,600 --> 00:55:42,000 things that matter more than almost anything else on the 1135 00:55:42,000 --> 00:55:45,080 infrastructure side of the house are things like reliability, 1136 00:55:45,760 --> 00:55:49,840 reproducibility, security, predictability, right? 1137 00:55:49,840 --> 00:55:53,800 Like, it's kind of the boring stuff, but that's what matters 1138 00:55:53,840 --> 00:55:56,720 in the DevOps world. And the problem with at least 1139 00:55:56,760 --> 00:55:59,600 all the LLM things that I've seen to the state is those are 1140 00:55:59,600 --> 00:56:02,440 the exact areas where they're really, really, really weak, 1141 00:56:02,640 --> 00:56:05,200 right? LLMS are notorious for just 1142 00:56:05,200 --> 00:56:07,800 hallucinating things, right? Just making things up. 1143 00:56:08,320 --> 00:56:11,000 And that doesn't seem like a small bug of one LLM 1144 00:56:11,000 --> 00:56:14,080 implementation. I think that's just core to the 1145 00:56:14,080 --> 00:56:16,160 infrastructure, to the way that they're designed. 1146 00:56:16,920 --> 00:56:19,840 They're also kind of random. Like literally they have a 1147 00:56:19,840 --> 00:56:23,720 random seed built in and the tiniest little change to a 1148 00:56:23,720 --> 00:56:26,760 prompt can profoundly impact the results, right? 1149 00:56:26,760 --> 00:56:29,800 You change like 2 words like a pronoun here and all of a sudden 1150 00:56:29,800 --> 00:56:31,280 you get a completely different response. 1151 00:56:31,800 --> 00:56:35,400 So it's really hard to get like repeatable, dependable results. 1152 00:56:35,920 --> 00:56:39,560 And the last thing I want is like the security of my company 1153 00:56:40,120 --> 00:56:44,080 being dependent upon an AI that will like hallucinate an answer 1154 00:56:44,560 --> 00:56:46,560 or will give me a slightly different answer. 1155 00:56:46,560 --> 00:56:49,080 You know, it used to work, but now today they changed something 1156 00:56:49,080 --> 00:56:51,440 in the model or I changed my prompt and now I get something 1157 00:56:51,440 --> 00:56:55,520 that's not actually secure. So I'm not very bullish on the 1158 00:56:56,120 --> 00:56:59,120 AI is going to replace this angle that strikes me at least 1159 00:56:59,120 --> 00:57:01,720 with what I'm seeing today as not super plausible. 1160 00:57:02,440 --> 00:57:05,560 I think the place where AI can get interesting on the DevOps 1161 00:57:05,560 --> 00:57:09,960 world is what's called retrieval augmented generation. 1162 00:57:10,120 --> 00:57:13,320 RAGI don't know if you're supposed to pronounce it as rag 1163 00:57:13,320 --> 00:57:14,400 or not. You know, I don't know if this 1164 00:57:14,400 --> 00:57:17,400 is like the GIF GIF debate, but anyway, I'll call it rag. 1165 00:57:18,000 --> 00:57:20,360 And the idea here is you take one of these large language 1166 00:57:20,360 --> 00:57:24,680 models and then what you add is some additional context, usually 1167 00:57:24,680 --> 00:57:28,560 some sort of database with extra up to date information about 1168 00:57:28,560 --> 00:57:32,840 your very specific use case. And so this thing can combine 1169 00:57:32,840 --> 00:57:35,400 these two pieces of information, the model it was trained on and 1170 00:57:35,400 --> 00:57:39,240 your up to date info to give you hopefully much better responses 1171 00:57:39,520 --> 00:57:43,520 about your specific context. And I think there's two ways 1172 00:57:43,520 --> 00:57:45,960 that that can be interesting. The basic 1, and that's the one 1173 00:57:45,960 --> 00:57:48,200 we do see today, and there's a bunch of tools trying to do this 1174 00:57:48,560 --> 00:57:53,320 is you feed it the information about your infrastructure as it 1175 00:57:53,320 --> 00:57:55,520 is today. Here's how I deploy things. 1176 00:57:55,520 --> 00:57:58,600 Here's all my metrics, here's all my structured events going 1177 00:57:58,600 --> 00:58:01,400 through my systems. And now that's the additional 1178 00:58:01,400 --> 00:58:04,000 context that I give these RAG tools. 1179 00:58:04,640 --> 00:58:08,000 Now they can answer questions for me about my own 1180 00:58:08,000 --> 00:58:10,480 infrastructure. So if I have an outage, I can 1181 00:58:10,480 --> 00:58:12,800 say what changed? What did we just deploy? 1182 00:58:12,800 --> 00:58:15,440 What happened, what metrics changed, right? 1183 00:58:15,920 --> 00:58:18,000 And so we're starting to see that, you know, there's like a 1184 00:58:18,000 --> 00:58:20,840 tool called Honeycomb and it's starting to use AI to kind of 1185 00:58:20,840 --> 00:58:24,120 intelligently help you debug outages, for example. 1186 00:58:24,480 --> 00:58:27,240 And we're seeing that in some monitoring tools where they are 1187 00:58:27,240 --> 00:58:31,000 trying to predict you're about to have an outage based on some 1188 00:58:31,000 --> 00:58:33,440 kind of metrics. I think that stuff is pretty 1189 00:58:33,440 --> 00:58:35,760 interesting. And I, I do think eventually 1190 00:58:35,760 --> 00:58:38,280 it'll be reliable enough that you can really use it and really 1191 00:58:38,280 --> 00:58:42,080 accelerate either preventing outages or debugging outages and 1192 00:58:42,080 --> 00:58:44,800 under even just navigating and understanding how your 1193 00:58:44,800 --> 00:58:47,280 infrastructure works. I think this could be very 1194 00:58:47,280 --> 00:58:49,720 useful. The one that I'm more excited 1195 00:58:49,720 --> 00:58:53,360 about, but I don't know if we can do it, is if I can feed in 1196 00:58:53,360 --> 00:58:57,880 not just my context, but the context of 1000 other companies 1197 00:58:58,600 --> 00:59:04,160 and now these AI models. No, can see these common 1198 00:59:04,160 --> 00:59:06,040 patterns amongst all the companies. 1199 00:59:06,360 --> 00:59:09,760 So when there's another security vulnerability, it's not me 1200 00:59:09,760 --> 00:59:12,000 having to go in there and say I need to update my code. 1201 00:59:12,000 --> 00:59:15,600 It's this model can say, hey, I saw that 957 other companies 1202 00:59:15,600 --> 00:59:17,880 just updated their open SSL library. 1203 00:59:18,080 --> 00:59:21,440 Here's a patch to update yours and I've already rolled it out 1204 00:59:21,440 --> 00:59:23,200 into your test environment. Does this look good? 1205 00:59:23,200 --> 00:59:24,360 Should we push to prod? Right? 1206 00:59:24,720 --> 00:59:28,400 It's the ability to see patterns that everyone is facing and to 1207 00:59:28,400 --> 00:59:32,400 extrapolate those into my case. I think that would be an 1208 00:59:32,400 --> 00:59:34,480 incredible thing. Because that's the reality, 1209 00:59:34,480 --> 00:59:36,600 right? Like there are 1000 DevOps 1210 00:59:36,600 --> 00:59:40,160 engineers at 1000 companies doing the same stupid thing over 1211 00:59:40,360 --> 00:59:43,040 and over and over again. But we don't get to leverage a 1212 00:59:43,040 --> 00:59:45,240 lot of that work, so maybe it'll help. 1213 00:59:45,920 --> 00:59:50,240 The challenge as far as I can tell is how you get one of these 1214 00:59:50,320 --> 00:59:53,720 large language models to expose information about other 1215 00:59:53,720 --> 00:59:58,480 companies without leaking that company's proprietary data 1216 00:59:58,480 --> 01:00:00,520 secret sauce. Can those models tell the 1217 01:00:00,520 --> 01:00:04,040 difference and not hallucinate and not, you know, get it wrong 1218 01:00:04,280 --> 01:00:06,920 between what should be kept private and what's OK to share. 1219 01:00:06,920 --> 01:00:08,240 I think that's going to be a challenge. 1220 01:00:08,720 --> 01:00:10,840 But if we can pull it off, I think that could be a really 1221 01:00:10,840 --> 01:00:13,760 profound acceleration to how we build software. 1222 01:00:14,200 --> 01:00:16,480 So that's the second item. Third one that I'll mention a 1223 01:00:16,480 --> 01:00:20,120 little bit tied to that, but I think it's it's own thing is. 1224 01:00:20,560 --> 01:00:25,520 The idea of secure by default, and this is something I'm 1225 01:00:25,520 --> 01:00:28,240 starting to see a little bit of it, and some of it is like 1226 01:00:28,240 --> 01:00:30,240 wishful thinking. And maybe if I say it enough, 1227 01:00:30,240 --> 01:00:32,200 maybe people in the industry will start going in this 1228 01:00:32,200 --> 01:00:34,960 direction. So what do I mean by this? 1229 01:00:35,440 --> 01:00:38,640 The analogy I use actually has to do with elevators. 1230 01:00:39,280 --> 01:00:41,680 There's this really famous demonstration, and there's a 1231 01:00:41,680 --> 01:00:44,200 little bit of controversy of whether it actually happened 1232 01:00:44,200 --> 01:00:45,760 this way, but it makes for a great story. 1233 01:00:45,840 --> 01:00:49,160 So back in the early 20th century, we wanted to make our 1234 01:00:49,160 --> 01:00:51,640 cities taller, you know, taller and taller buildings. 1235 01:00:52,160 --> 01:00:56,680 And we had elevators, but people were terrified of the cable 1236 01:00:56,680 --> 01:00:58,800 snapping and plunging you to your death. 1237 01:00:59,440 --> 01:01:04,320 And so this Elijah Otis guy of Otis Elevator comes along and he 1238 01:01:04,320 --> 01:01:07,600 does this amazing demonstration in front of huge crowds where he 1239 01:01:07,600 --> 01:01:11,040 has this open elevator shaft and he has this assistant lift him 1240 01:01:11,040 --> 01:01:12,840 up. And he's Elijah's standing on 1241 01:01:12,840 --> 01:01:15,760 the elevator as it's raised to like the fifth story or 60 feet 1242 01:01:15,760 --> 01:01:18,400 up or something like that. And then the assistant comes up 1243 01:01:18,400 --> 01:01:21,720 with a knife and cuts the cable of the elevator while Elijah's 1244 01:01:21,720 --> 01:01:24,320 standing on it. And the elevator drops about an 1245 01:01:24,320 --> 01:01:27,960 inch and then immediately stops. And Elijah's like all safe, all 1246 01:01:27,960 --> 01:01:29,080 safe gentlemen, everything's fine. 1247 01:01:29,200 --> 01:01:30,600 And it's a really cool demonstration. 1248 01:01:30,720 --> 01:01:33,040 And the way that it works is incredibly clever. 1249 01:01:33,680 --> 01:01:36,560 The basic idea with what's called the safety elevator, this 1250 01:01:36,560 --> 01:01:39,560 thing that Elijah came up with and has been improved on since, 1251 01:01:40,200 --> 01:01:44,400 is that if you look at the outside of the elevator, it has 1252 01:01:44,400 --> 01:01:48,120 these metal hooks that stick out into the elevator shaft. 1253 01:01:48,440 --> 01:01:50,720 And the elevator shaft has a bunch of metal teeth running 1254 01:01:50,720 --> 01:01:53,040 along the side of it. So these hooks stick out and 1255 01:01:53,040 --> 01:01:55,800 they grab onto those teeth and the elevator can't move at all. 1256 01:01:55,880 --> 01:01:58,120 And that's its default state. It cannot move. 1257 01:01:58,800 --> 01:02:02,840 The only way to pull these hooks in is if there's an intact 1258 01:02:03,000 --> 01:02:05,800 elevator cable. If there's an intact cable, it 1259 01:02:05,800 --> 01:02:08,760 kind of pulls up and this little springs come in and these little 1260 01:02:08,840 --> 01:02:12,160 hooks come into the elevator. Now the elevator can move and as 1261 01:02:12,160 --> 01:02:15,480 soon as the cable is not intact, if somebody cuts it, they spring 1262 01:02:15,480 --> 01:02:17,680 right back out into the shaft and the elevator can't move. 1263 01:02:18,560 --> 01:02:21,200 Why do I bring this up? What's so clever about this 1264 01:02:21,200 --> 01:02:24,600 design is that it is secure by default. 1265 01:02:25,160 --> 01:02:27,520 The default state of the elevator is safe. 1266 01:02:27,560 --> 01:02:31,160 It cannot move, It cannot fall. And the only way it moves is 1267 01:02:31,160 --> 01:02:33,800 when something else proves that it's in a safe state, which is, 1268 01:02:33,840 --> 01:02:36,960 you know, the cable. And so that made people 1269 01:02:37,000 --> 01:02:39,840 confident enough to ride in elevators, transform cities, 1270 01:02:39,840 --> 01:02:41,400 allowed us to build tall buildings. 1271 01:02:41,400 --> 01:02:44,440 Really cool stuff. So right now I would argue that 1272 01:02:44,440 --> 01:02:49,760 the state of software delivery, DevOps, etcetera is not secure 1273 01:02:49,760 --> 01:02:51,800 by default. We are very much in that early 1274 01:02:51,800 --> 01:02:54,640 20th century state of like, we want to build fancy tall 1275 01:02:54,640 --> 01:02:57,280 buildings and infrastructure, but we can't because we're 1276 01:02:57,280 --> 01:02:58,640 afraid of plunging to our deaths. 1277 01:02:59,400 --> 01:03:02,720 It feels like all the defaults are not secure, right? 1278 01:03:03,120 --> 01:03:05,880 Usually you build something and like all the networking is wide 1279 01:03:05,880 --> 01:03:07,680 open. Nothing's encrypted. 1280 01:03:08,000 --> 01:03:10,720 If you have third party dependencies, nobody verifies 1281 01:03:10,720 --> 01:03:11,880 you know where the hell they came from. 1282 01:03:11,880 --> 01:03:13,200 Nobody's keeping them up to date. 1283 01:03:13,200 --> 01:03:17,200 There's no monitoring. And maybe worst of all is a lot 1284 01:03:17,200 --> 01:03:20,760 of vendors charge extra money for the more secure things. 1285 01:03:20,760 --> 01:03:23,440 Like using single sign on usually is only in the expensive 1286 01:03:23,440 --> 01:03:25,880 enterprise plan. So we're like we're, we're the 1287 01:03:25,880 --> 01:03:27,720 exact opposite of safe by default. 1288 01:03:27,720 --> 01:03:30,920 We're like horrifically dangerous and deadly by default. 1289 01:03:30,920 --> 01:03:33,320 And if you pay us enough, maybe we'll make you more secure. 1290 01:03:34,120 --> 01:03:37,920 So that's bad. The good news is there are some 1291 01:03:38,080 --> 01:03:40,640 signs. The industry is starting to move 1292 01:03:40,680 --> 01:03:43,880 towards a more secure by default state. 1293 01:03:44,000 --> 01:03:46,000 And there's a whole bunch of little signs. 1294 01:03:46,000 --> 01:03:48,760 And hopefully we'll get more. And I'll mention just a few of 1295 01:03:48,760 --> 01:03:51,200 these. One that's been appearing more 1296 01:03:51,200 --> 01:03:53,800 and more recently is this concept of shift left. 1297 01:03:54,560 --> 01:03:59,160 And the idea here is if you kind of look at like a, a diagram of 1298 01:03:59,160 --> 01:04:02,280 how something goes from code to being deployed on the site, you 1299 01:04:02,280 --> 01:04:04,800 know, from left to right, there's like write the code, 1300 01:04:04,800 --> 01:04:06,760 test the code, deployment, etcetera. 1301 01:04:07,120 --> 01:04:10,400 The idea with shift left is to move security testing further 1302 01:04:10,400 --> 01:04:13,160 and further left. In other words, closer and 1303 01:04:13,160 --> 01:04:14,920 closer to the development of the code. 1304 01:04:14,920 --> 01:04:18,440 So you catch security issues as early in the life cycle as 1305 01:04:18,440 --> 01:04:21,200 possible, which is when they're easiest to fix and is the most 1306 01:04:21,200 --> 01:04:22,320 secure. You certainly don't want them 1307 01:04:22,320 --> 01:04:24,520 all the way on the right when you're already in production and 1308 01:04:24,520 --> 01:04:26,720 you've been hacked. That would be the catching it on 1309 01:04:26,720 --> 01:04:29,240 the very right side. So there's a whole bunch of 1310 01:04:29,240 --> 01:04:33,520 these shift left tools from things that allow you to enforce 1311 01:04:33,520 --> 01:04:36,600 policies around your code to all sorts of automated testing 1312 01:04:36,600 --> 01:04:39,160 tools. So those are really nice to see. 1313 01:04:39,440 --> 01:04:42,440 Basically thinking about security really early on. 1314 01:04:43,320 --> 01:04:46,840 A second pattern is you're going to hear a lot more, I think, in 1315 01:04:46,840 --> 01:04:49,320 the future about supply chain security. 1316 01:04:49,920 --> 01:04:53,400 So in the world of software, your supply chain is basically 1317 01:04:53,400 --> 01:04:55,800 all the software you depend on, right? 1318 01:04:55,800 --> 01:04:58,280 All of your open source libraries that you use, all the 1319 01:04:58,280 --> 01:05:01,640 vendor libraries, even the cloud that you deploy into, those are 1320 01:05:01,640 --> 01:05:04,560 all software written and maintained by somebody else. 1321 01:05:04,840 --> 01:05:06,240 They're part of your supply chain. 1322 01:05:06,640 --> 01:05:10,280 And the reality is if somebody compromises any part of that, 1323 01:05:10,640 --> 01:05:13,200 they can do some amazing, amazing damage. 1324 01:05:13,240 --> 01:05:15,840 And hackers have caught on to this and they're trying real 1325 01:05:15,840 --> 01:05:18,840 hard. I think these days, I forget the 1326 01:05:18,840 --> 01:05:22,560 exact number, but something like 70% of the code that a typical 1327 01:05:22,560 --> 01:05:25,680 company deploys is not written by that company. 1328 01:05:25,800 --> 01:05:27,240 And I guess that's an underestimate that. 1329 01:05:27,240 --> 01:05:29,040 I think that's just the open source portion. 1330 01:05:29,280 --> 01:05:32,080 I think if you factor in things like, you know, the cloud that 1331 01:05:32,080 --> 01:05:34,400 you're running on and the Linux operating system and all the 1332 01:05:34,400 --> 01:05:37,400 tools on, there is probably like 99% of the code that you rely 1333 01:05:37,400 --> 01:05:38,840 on. You didn't have anything to do 1334 01:05:38,840 --> 01:05:40,520 with it. And hackers know that. 1335 01:05:40,520 --> 01:05:43,320 So if they can go into some little library hidden somewhere 1336 01:05:43,320 --> 01:05:46,360 in Linux and put a little back door in there, well, they can 1337 01:05:46,360 --> 01:05:48,240 take over everybody's software, right? 1338 01:05:48,240 --> 01:05:51,360 And everybody's hardware. So this is a big battle that's 1339 01:05:51,360 --> 01:05:54,360 happening right now is how do you secure the supply chain? 1340 01:05:54,360 --> 01:05:57,240 How can you be confident that all the software you depend on 1341 01:05:57,720 --> 01:06:00,320 is the software you think it is and is secure? 1342 01:06:00,320 --> 01:06:02,520 And maybe they shifted left and has been tested. 1343 01:06:02,520 --> 01:06:04,960 And so there's a lot of interesting technologies 1344 01:06:04,960 --> 01:06:08,960 emerging in that space. I think it's super, super early 1345 01:06:08,960 --> 01:06:10,200 days. I think our answers there are 1346 01:06:10,200 --> 01:06:13,600 still really weak, but I think I'm, I'm so happy to see someone 1347 01:06:13,600 --> 01:06:15,000 who's thinking about it at least. 1348 01:06:15,000 --> 01:06:17,960 So supply chain security is going to be, I think a big, big 1349 01:06:17,960 --> 01:06:20,600 deal. Another trend with secure by 1350 01:06:20,600 --> 01:06:24,360 default is a push to move to memory safe languages. 1351 01:06:25,120 --> 01:06:27,440 Again, this is moving up the abstraction ladder. 1352 01:06:27,520 --> 01:06:31,960 As I mentioned before, it turns out that something like 70%, 1353 01:06:31,960 --> 01:06:34,280 again, I don't remember the exact number, but very, very 1354 01:06:34,280 --> 01:06:37,680 high percentage of bugs, security bugs specifically, are 1355 01:06:37,680 --> 01:06:41,560 due to memory safety issues. You take a language like C where 1356 01:06:41,560 --> 01:06:43,880 you have, you know, pointer arithmetic and things like that, 1357 01:06:43,880 --> 01:06:45,160 and you put a little bug in there. 1358 01:06:45,160 --> 01:06:47,680 You didn't quite do the arithmetic and somebody can pass 1359 01:06:47,680 --> 01:06:50,320 in some little input and makes you read or write to memory 1360 01:06:50,320 --> 01:06:53,520 they're not supposed to. It turns out 70% of the security 1361 01:06:53,520 --> 01:06:58,200 issues we face as an industry, 70% are due to that issue alone. 1362 01:06:58,600 --> 01:07:02,480 And those bugs do not exist for the most part in memory safe 1363 01:07:02,480 --> 01:07:04,760 languages. You just can't do them in higher 1364 01:07:04,760 --> 01:07:07,240 level languages where memory is managed automatically. 1365 01:07:07,840 --> 01:07:11,400 So if we switch programming languages, 70% of our security 1366 01:07:11,400 --> 01:07:14,800 issues go away. Like that's a huge, huge deal. 1367 01:07:15,200 --> 01:07:17,360 And so you're starting to see that the US government is now 1368 01:07:17,360 --> 01:07:20,560 pushing to move away from languages like C and on to 1369 01:07:20,560 --> 01:07:23,600 languages like Rust and Go and things that are more memory 1370 01:07:23,600 --> 01:07:25,720 safe. And I think that's a really good 1371 01:07:25,720 --> 01:07:27,040 thing. That's a really hard thing 1372 01:07:27,040 --> 01:07:29,160 because like all of our operating systems are written in 1373 01:07:29,160 --> 01:07:32,240 not memory safe language. So there's a tremendous amount 1374 01:07:32,240 --> 01:07:34,840 of work to do there. But if we can do it, we will 1375 01:07:34,840 --> 01:07:38,320 make things vastly, vastly, vastly more secure by default. 1376 01:07:38,880 --> 01:07:41,640 And then the final one, another pattern that's appearing more 1377 01:07:41,640 --> 01:07:44,160 and more is this idea of 0 trust networking. 1378 01:07:44,600 --> 01:07:46,040 I talk a lot about this in the book. 1379 01:07:46,600 --> 01:07:51,040 The kind of the older way of doing things is the Moat and 1380 01:07:51,040 --> 01:07:53,880 castle approach. The idea is you create this 1381 01:07:53,920 --> 01:07:57,680 really secure perimeter around your infrastructure, a little 1382 01:07:57,680 --> 01:07:59,200 bit like a castle with a Moat, right? 1383 01:07:59,200 --> 01:08:01,920 You have a really tall wall and you have a Moat with alligators. 1384 01:08:02,080 --> 01:08:04,920 So the perimeter is really hard to is really secure, really hard 1385 01:08:04,920 --> 01:08:07,120 to get through. But once you're inside that 1386 01:08:07,120 --> 01:08:08,880 perimeter, you can do whatever you want. 1387 01:08:09,720 --> 01:08:12,120 And the equivalent of that in the software world, in the 1388 01:08:12,120 --> 01:08:15,880 networking world, is you have really, really strong firewalls 1389 01:08:15,880 --> 01:08:17,840 and things like that on the edge of your network. 1390 01:08:18,200 --> 01:08:20,640 But once you're in, if you somehow found a way in, well, 1391 01:08:20,640 --> 01:08:23,000 now you can access the wiki page over there, and you can access 1392 01:08:23,000 --> 01:08:26,120 that service over there, and you can access that database and do 1393 01:08:26,120 --> 01:08:28,399 whatever you want. You know you have free rein once 1394 01:08:28,399 --> 01:08:30,960 you're inside. Turns out that approach used to 1395 01:08:30,960 --> 01:08:33,600 make sense. When everybody was in an office 1396 01:08:33,600 --> 01:08:36,560 owned by the company, All the infrastructure was in probably 1397 01:08:36,560 --> 01:08:38,160 the same building owned by the company. 1398 01:08:38,439 --> 01:08:41,160 All the computers are used were in that office owned by the 1399 01:08:41,160 --> 01:08:42,479 company, right? It kind of worked. 1400 01:08:43,200 --> 01:08:44,520 That's not the world we live in, right? 1401 01:08:44,520 --> 01:08:47,359 We all now work from home. The network now extends into 1402 01:08:47,359 --> 01:08:51,439 like, coffee shops and libraries and coworking spaces. 1403 01:08:51,760 --> 01:08:54,520 Your infrastructure isn't in your office, it's in somebody 1404 01:08:54,520 --> 01:08:57,640 else's cloud. The devices you're using are 1405 01:08:57,640 --> 01:09:00,920 these smartphones, right? That are not particularly 1406 01:09:00,920 --> 01:09:03,680 secured. So it doesn't really make sense 1407 01:09:03,680 --> 01:09:05,880 to use the Moat and Castle model anymore. 1408 01:09:06,000 --> 01:09:10,000 The new model IS0 trust networking, and the idea is your 1409 01:09:10,120 --> 01:09:12,800 location in the network. The fact that you're in the 1410 01:09:12,800 --> 01:09:15,800 network doesn't give you any special privileges of any kind. 1411 01:09:16,200 --> 01:09:19,040 Every single request, every connection must be 1412 01:09:19,240 --> 01:09:22,640 authenticated, authorized and encrypted, every single thing. 1413 01:09:22,640 --> 01:09:25,880 So just because I'm able to access the wiki page does not 1414 01:09:25,880 --> 01:09:28,880 give me any access to that database or any access to that 1415 01:09:28,880 --> 01:09:30,920 issue tracker or anything else at all. 1416 01:09:31,160 --> 01:09:33,680 Every single thing has to authenticate, authorize, and 1417 01:09:33,680 --> 01:09:37,200 encrypt separately. And we're starting to see that 1418 01:09:37,240 --> 01:09:40,439 appearing from vendors. It's not the default, It's very 1419 01:09:40,439 --> 01:09:44,000 far from being the default, but things like service meshes and 1420 01:09:44,000 --> 01:09:46,720 and tools of that sort are starting to at least make it a 1421 01:09:46,720 --> 01:09:48,880 little easier to do it because it's really hard to actually to 1422 01:09:48,880 --> 01:09:50,520 do zero trust networking properly. 1423 01:09:50,960 --> 01:09:55,040 So we're at least making it more accessible and maybe at some 1424 01:09:55,040 --> 01:09:57,240 point in the future, it'll become the default, which I 1425 01:09:57,240 --> 01:10:00,400 think will be a tremendous, tremendous improvement to 1426 01:10:00,600 --> 01:10:02,960 security. So yeah, those are the three 1427 01:10:02,960 --> 01:10:04,360 patterns that I'm seeing in the future. 1428 01:10:04,440 --> 01:10:07,880 Higher level abstractions some role for generative AI, 1429 01:10:07,880 --> 01:10:12,560 especially RAG, and this move towards secure by default. 1430 01:10:13,360 --> 01:10:15,960 Wow, really fascinating just hearing, you know, all the 1431 01:10:15,960 --> 01:10:18,480 predictions and you know, up and coming technologies and 1432 01:10:18,480 --> 01:10:20,320 techniques that you just mentioned and shared, right. 1433 01:10:20,320 --> 01:10:23,920 So I think definitely we are optimistic to the future, right? 1434 01:10:23,920 --> 01:10:26,760 So higher level abstractions, memory safe language, secure by 1435 01:10:26,760 --> 01:10:29,880 default, Hopefully software gets easier and easier to deliver, 1436 01:10:30,400 --> 01:10:32,600 but at the same time also hearing about, you know, this 1437 01:10:32,600 --> 01:10:35,280 supply chain attack and all that, sometimes we have to be 1438 01:10:35,280 --> 01:10:38,680 paranoid as well to what we use from the open source world. 1439 01:10:39,240 --> 01:10:41,000 Speaking about supply chain attack, right? 1440 01:10:41,000 --> 01:10:44,280 And I know one other trend that happens quite recently is the 1441 01:10:44,280 --> 01:10:46,520 changes in the open source licensing. 1442 01:10:46,760 --> 01:10:49,960 And I know you are one of the core founding member of open 1443 01:10:49,960 --> 01:10:52,520 Tofu, right? So the alternative to Terraform, 1444 01:10:52,920 --> 01:10:55,600 maybe also tell us a little bit about your, I don't know, 1445 01:10:55,800 --> 01:10:59,080 prediction about what actually happening in the open source 1446 01:10:59,120 --> 01:11:02,200 licensing. And what should we all know 1447 01:11:02,200 --> 01:11:05,440 about, you know, as a software developers, what should we know 1448 01:11:05,440 --> 01:11:08,880 about in terms of how do we protect ourselves from all these 1449 01:11:08,880 --> 01:11:11,480 open source changes? Yeah. 1450 01:11:11,520 --> 01:11:13,960 So to add a little bit of context for folks that haven't 1451 01:11:13,960 --> 01:11:16,040 been following along specifically with like the 1452 01:11:16,040 --> 01:11:20,600 Terraform open tofu thing, the context there is Terraform and a 1453 01:11:20,600 --> 01:11:24,240 bunch of other Hashicorp tools were open source under fairly 1454 01:11:24,240 --> 01:11:29,760 permissive license, the MPL license for ten years plus for a 1455 01:11:29,760 --> 01:11:33,600 long time and built up huge communities, tons of 1456 01:11:33,600 --> 01:11:35,560 contributors, third parties, etcetera. 1457 01:11:36,160 --> 01:11:39,680 Recently Mahashi Corp made a change from this open source 1458 01:11:39,680 --> 01:11:42,800 license, shifted almost everything they have to a what's 1459 01:11:42,800 --> 01:11:45,840 called this business source license, which isn't really an 1460 01:11:45,840 --> 01:11:48,440 open source license. The short version, as it says 1461 01:11:48,440 --> 01:11:51,160 you can use this stuff unless you're competitive with Hashi 1462 01:11:51,160 --> 01:11:55,520 Corp and that's problematic for a whole bunch of reasons, but 1463 01:11:55,520 --> 01:11:56,520 Hash of Corp is not the only one. 1464 01:11:56,520 --> 01:11:58,920 Many, many other companies across the industry have been 1465 01:11:58,920 --> 01:12:04,040 changing from permissive open source licenses to some flavor 1466 01:12:04,040 --> 01:12:06,760 of these kind of business friendly licenses that basically 1467 01:12:06,760 --> 01:12:09,000 say you can use this stuff as long as you don't compete with 1468 01:12:09,000 --> 01:12:11,600 us or various other restrictions. 1469 01:12:12,440 --> 01:12:13,640 I have a lot of thoughts on this. 1470 01:12:13,640 --> 01:12:18,400 I'll, I'll try to keep it short. I, I'll say first, I am a huge, 1471 01:12:18,440 --> 01:12:22,840 huge believer in actual open source, proper open source, not 1472 01:12:22,840 --> 01:12:26,080 these business licenses, but you know, these permissive MIT 1473 01:12:26,120 --> 01:12:29,560 Apache, those types of licenses, I think they are one of the most 1474 01:12:29,560 --> 01:12:32,360 important and valuable things we've done as an industry. 1475 01:12:32,760 --> 01:12:36,520 I think they're one of the biggest accelerators to all of 1476 01:12:36,520 --> 01:12:39,720 software. And I personally find it 1477 01:12:40,240 --> 01:12:44,960 devastating to see companies doing anything to hurt trust in 1478 01:12:44,960 --> 01:12:46,960 open source. I think that is going to have 1479 01:12:46,960 --> 01:12:50,920 profound negative consequences on the industry because as I 1480 01:12:50,920 --> 01:12:53,720 said, there's 1000 DevOps engineers and 1000 companies 1481 01:12:53,720 --> 01:12:55,960 doing the same thing. And that's true of every kind of 1482 01:12:55,960 --> 01:12:58,480 software development. We are often doing the exact 1483 01:12:58,480 --> 01:13:01,760 same things and sometimes we can share that stuff commercially, 1484 01:13:01,960 --> 01:13:04,720 but we've seen that the open source stuff, especially for 1485 01:13:04,720 --> 01:13:07,800 things like infrastructure for these building blocks of the 1486 01:13:07,800 --> 01:13:10,360 entire Internet and our operating systems, etc. 1487 01:13:11,120 --> 01:13:14,400 They need to be open source, truly open source to be 1488 01:13:14,400 --> 01:13:16,960 reliable. So to an extent, I'm personally 1489 01:13:16,960 --> 01:13:20,040 just devastated to see the industry again and again move 1490 01:13:20,040 --> 01:13:23,360 away from these licenses. I'm hopeful there are a lot of 1491 01:13:23,360 --> 01:13:26,200 people like me. And so now we can ask, well, how 1492 01:13:26,200 --> 01:13:28,120 do we solve this and, and what led to this? 1493 01:13:28,720 --> 01:13:31,080 I don't have any internal visibility into the companies 1494 01:13:31,080 --> 01:13:32,640 that that made these license changes. 1495 01:13:32,640 --> 01:13:35,160 So this is me speculating. I'm sure they can tell you, you 1496 01:13:35,160 --> 01:13:38,520 know, a more accurate story. But what I've generally seen as 1497 01:13:38,520 --> 01:13:44,080 a pattern is the things that were open sourced by companies 1498 01:13:44,080 --> 01:13:46,640 that are trying to do hyper growth. 1499 01:13:47,120 --> 01:13:50,560 Typically these are companies that are venture backed, either 1500 01:13:50,560 --> 01:13:53,040 trying to be public or just became public. 1501 01:13:53,400 --> 01:13:57,200 And their goal isn't to just make a profit, it's to grow 1502 01:13:57,320 --> 01:14:01,120 massively huge to produce tremendous investment returns. 1503 01:14:01,800 --> 01:14:05,040 What I've generally seen is these are the companies that are 1504 01:14:05,040 --> 01:14:08,520 doing these license shifts on us and it makes sense, right? 1505 01:14:08,560 --> 01:14:11,520 They that's literally why they took venture capital. 1506 01:14:11,520 --> 01:14:13,320 It's to, you know, produce that kind of growth. 1507 01:14:13,320 --> 01:14:15,240 So in a sense that was part of the contract. 1508 01:14:15,920 --> 01:14:19,000 But we, I don't think those sorts of license shifts have 1509 01:14:19,000 --> 01:14:22,160 happened in cases where someone isn't trying for that growth, 1510 01:14:22,160 --> 01:14:24,280 right? It's rare to see somebody shift 1511 01:14:24,280 --> 01:14:26,320 license just because like they can't afford to pay 2 1512 01:14:26,320 --> 01:14:29,000 developers, right? Like that's it happens and we 1513 01:14:29,000 --> 01:14:32,280 need a better way to do that. But it's mostly the VCBF company 1514 01:14:32,280 --> 01:14:35,520 that isn't happy with making only hundreds of millions of 1515 01:14:35,520 --> 01:14:37,640 dollars. They need to be making billions 1516 01:14:37,640 --> 01:14:39,600 of dollars. And if you need to be making 1517 01:14:39,600 --> 01:14:42,440 billions of dollars, yeah, you got to find every little lever 1518 01:14:42,440 --> 01:14:45,320 and advantage and eliminate competition and basically build 1519 01:14:45,320 --> 01:14:48,920 a monopoly, hence the license change to be not competitive 1520 01:14:48,920 --> 01:14:51,160 with them. I think there's a few key 1521 01:14:51,160 --> 01:14:55,000 takeaways from that. I think if I was picking 1522 01:14:55,080 --> 01:14:57,520 technology for my company to depend on, especially like 1523 01:14:57,520 --> 01:15:00,240 really important foundational technologies, that would be very 1524 01:15:00,240 --> 01:15:03,600 painful to swap out. First of all, I would only pick 1525 01:15:03,600 --> 01:15:07,200 things that at least as of today are on some sort of truly open 1526 01:15:07,200 --> 01:15:09,320 source license. Chat with your lawyers about 1527 01:15:09,320 --> 01:15:11,960 what that means, but it's usually things like MIT, Apache, 1528 01:15:11,960 --> 01:15:14,640 MPL and handful of others, Berkeley, etcetera. 1529 01:15:15,320 --> 01:15:18,400 Second of all, I would look very, very carefully at the 1530 01:15:18,400 --> 01:15:22,040 company's behind those projects. If there's a company, some 1531 01:15:22,040 --> 01:15:26,520 projects are just an individual developer, some are built by 1532 01:15:26,560 --> 01:15:29,600 foundations, which I think is a much more secure thing to do. 1533 01:15:29,840 --> 01:15:32,440 But basically look who is behind this project. 1534 01:15:33,080 --> 01:15:37,280 If it's owned and primarily operated by a venture backed 1535 01:15:37,280 --> 01:15:39,560 company, you know somebody that wants to go hyper growth, 1536 01:15:39,840 --> 01:15:41,840 another pattern might be somebody that got acquired by 1537 01:15:41,840 --> 01:15:44,120 private equity firms. That's a very similar kind of 1538 01:15:44,120 --> 01:15:47,120 set of incentives. Be really, really cautious. 1539 01:15:47,160 --> 01:15:50,840 I think at this point you just need to think twice if that's a 1540 01:15:50,840 --> 01:15:52,880 good idea to adopt or if you're better. 1541 01:15:52,880 --> 01:15:57,120 Not because eventually the incentives are going to push 1542 01:15:57,120 --> 01:15:59,160 them to change the license. That's just what we're seeing. 1543 01:15:59,800 --> 01:16:02,880 And instead of venture backed companies try to pick tools. 1544 01:16:02,880 --> 01:16:05,480 The best version I think is if it's something that's managed by 1545 01:16:05,480 --> 01:16:09,880 Foundation, Linux Foundation, CNCF, things like that, because 1546 01:16:09,880 --> 01:16:12,960 those are specifically designed so no one company, due to 1547 01:16:13,040 --> 01:16:15,160 whatever incentives they have, can go and mess with the 1548 01:16:15,160 --> 01:16:16,560 license. That's the best option. 1549 01:16:17,000 --> 01:16:20,760 Second best is going to be either like solo developer, 1550 01:16:21,120 --> 01:16:23,760 which has the advantage of, well, if they can make enough 1551 01:16:23,760 --> 01:16:26,400 money or have enough spare time, they can make it work. 1552 01:16:26,920 --> 01:16:30,160 And they're not likely to chase, you know, venture back returns 1553 01:16:30,840 --> 01:16:33,840 or possibly something that's backed by a large company where 1554 01:16:33,840 --> 01:16:36,760 they're not trying to make money off of this piece of open 1555 01:16:36,760 --> 01:16:38,920 source, right? You know, Google open source and 1556 01:16:38,920 --> 01:16:40,320 stuff, Facebook open source and stuff. 1557 01:16:40,360 --> 01:16:42,480 They're not trying to sell a lot of that stuff. 1558 01:16:42,960 --> 01:16:45,480 Those can be reasonably safe bets as well. 1559 01:16:45,520 --> 01:16:47,600 But the Foundation 1 is the best. 1560 01:16:48,280 --> 01:16:50,280 So that's, I guess in the short term what I would really look 1561 01:16:50,280 --> 01:16:51,400 for. There's a lot of other things 1562 01:16:51,400 --> 01:16:53,880 you need to look for when picking open source libraries or 1563 01:16:53,880 --> 01:16:55,920 anything else, you know, part of supply chain security. 1564 01:16:55,920 --> 01:16:59,040 But at least from a licensing perspective, that's kind of the 1565 01:16:59,040 --> 01:17:03,160 hard lesson learned for me is be really wary of who is behind the 1566 01:17:03,160 --> 01:17:07,440 project and what license it has. I think in the longer term, this 1567 01:17:07,440 --> 01:17:09,600 is something we need to grapple with as an industry. 1568 01:17:09,880 --> 01:17:12,920 What does open source mean? Do we need to start creating? 1569 01:17:12,920 --> 01:17:15,440 And maybe there are some out there licenses that basically 1570 01:17:15,440 --> 01:17:18,880 say, hey, this is not only open source, but I also pledge to 1571 01:17:18,880 --> 01:17:21,720 never swap this thing. You know, I legally prevent 1572 01:17:21,720 --> 01:17:25,120 myself from swapping this to some sort of not open source 1573 01:17:25,120 --> 01:17:27,600 license in the future. Maybe we need some sort of 1574 01:17:27,600 --> 01:17:31,160 guarantees along those lines. But even more generally, you 1575 01:17:31,160 --> 01:17:32,760 know, how do we fund open source? 1576 01:17:32,760 --> 01:17:34,640 And this is something a lot of people have been thinking about. 1577 01:17:34,640 --> 01:17:37,480 There are some interesting directions that I've seen. 1578 01:17:37,480 --> 01:17:40,960 I haven't seen anything that seems like a great solution, but 1579 01:17:40,960 --> 01:17:43,800 there are at least some positive trends for solo developers or 1580 01:17:43,800 --> 01:17:47,560 really small teams where you can make like a good salary to live 1581 01:17:47,560 --> 01:17:50,280 on and to be able to afford to focus on open source. 1582 01:17:50,280 --> 01:17:52,960 And I think that's great. And so really what we're going 1583 01:17:52,960 --> 01:17:56,240 to have to reckon with as an industry is do we trust 1584 01:17:56,560 --> 01:17:59,920 companies with hyper growth as an incentive to release 1585 01:17:59,920 --> 01:18:02,360 something open source that is core to their business? 1586 01:18:02,360 --> 01:18:04,000 So I should put that as a big asterisk. 1587 01:18:04,000 --> 01:18:07,560 Again, it's with Hashicorp, you know, Terraform is what they 1588 01:18:07,560 --> 01:18:10,000 make money on with Mongo DB. Mongo DB was what they make 1589 01:18:10,000 --> 01:18:12,040 money on, right? So if it's the thing they're 1590 01:18:12,040 --> 01:18:15,400 trying to monetize and some aspect of it is open source, 1591 01:18:15,760 --> 01:18:18,800 should we really trust that? Or is that just like clearly an 1592 01:18:18,800 --> 01:18:21,640 anti pattern in our industry? Is there a way we can build 1593 01:18:21,640 --> 01:18:24,680 trust around that? I think that's something that 1594 01:18:24,840 --> 01:18:27,400 smarter people than me will have to look at and figure out. 1595 01:18:28,080 --> 01:18:30,840 Yeah, so I guess that's that's where my mind goes with that 1596 01:18:30,840 --> 01:18:33,840 stuff today. And the final thing is if you do 1597 01:18:33,840 --> 01:18:37,800 pick projects that have truly open source licenses, Apache, 1598 01:18:37,880 --> 01:18:41,680 MIT, etcetera, then if the worst thing happens and somebody does 1599 01:18:41,680 --> 01:18:45,840 change the license or in any way move the project in a direction 1600 01:18:45,880 --> 01:18:47,040 that you really don't agree with. 1601 01:18:47,360 --> 01:18:49,920 Well, the whole point of open source is that you have the 1602 01:18:49,920 --> 01:18:52,520 right, honestly even the responsibility to fork it. 1603 01:18:53,000 --> 01:18:55,480 And you know, you still can use the code and you're not 1604 01:18:55,480 --> 01:18:57,960 completely stuck. So that is what we're seeing 1605 01:18:57,960 --> 01:18:59,400 happening with a lot of these projects. 1606 01:18:59,400 --> 01:19:02,760 We are seeing major forks being developed, open Tofu for 1607 01:19:02,760 --> 01:19:06,520 Terraform as an example, Open Bow for Vault and many others, 1608 01:19:06,680 --> 01:19:10,280 open search or Elasticsearch. So that's kind of the fall back. 1609 01:19:10,400 --> 01:19:14,160 But if nobody wants to fork things, right, I, we, we ended 1610 01:19:14,160 --> 01:19:16,400 up forking Terraform. It's not great. 1611 01:19:16,440 --> 01:19:19,240 We asked Hashicorp to not change the license. 1612 01:19:19,240 --> 01:19:22,560 I think that's the best option. You want to have one joint 1613 01:19:22,560 --> 01:19:24,240 strong community. That's the best option for 1614 01:19:24,240 --> 01:19:26,680 everyone. And that can only happen around 1615 01:19:26,680 --> 01:19:30,560 a truly open source license. But if things happen and you 1616 01:19:30,560 --> 01:19:32,960 don't have any other choice, well, make sure that you at 1617 01:19:32,960 --> 01:19:35,760 least have the option to then fork the code and do what you 1618 01:19:35,760 --> 01:19:39,080 need to do as the backup. Thank you for expanding the 1619 01:19:39,080 --> 01:19:41,120 intricacies of these open source changes, right? 1620 01:19:41,120 --> 01:19:43,680 Because I find that many engineers just use open source 1621 01:19:43,680 --> 01:19:45,960 because it's so simple, you know, like, I don't know, MPM 1622 01:19:45,960 --> 01:19:48,440 install whatever install, right? But they don't actually 1623 01:19:48,440 --> 01:19:51,680 understand the true intricacies behind open source and 1624 01:19:51,680 --> 01:19:53,640 especially these licensing changes, right? 1625 01:19:53,680 --> 01:19:56,360 Because sometimes it can affect, you know, the software that you 1626 01:19:56,360 --> 01:19:59,000 are delivering, right? Like you mentioned 70% to maybe 1627 01:19:59,000 --> 01:20:02,000 90% things that we use now relying on open source 1628 01:20:02,000 --> 01:20:04,560 technology and dependencies. So if something changes, 1629 01:20:04,560 --> 01:20:07,360 definitely it can break your software altogether, right? 1630 01:20:07,360 --> 01:20:09,640 Or you have to. Find a way to rewrite or change 1631 01:20:09,720 --> 01:20:13,040 some parts of your code base, which is not easy to do and 1632 01:20:13,280 --> 01:20:15,560 typically can be risky. And I personally would like to 1633 01:20:15,560 --> 01:20:17,920 thank you as well for championing, you know, this open 1634 01:20:17,920 --> 01:20:21,280 tofu, you know, making sure that open source stays truly open 1635 01:20:21,280 --> 01:20:22,640 source. I think it's really, really 1636 01:20:22,640 --> 01:20:23,720 important, as you mentioned, right? 1637 01:20:23,720 --> 01:20:26,120 Open source has been accelerating the progress in the 1638 01:20:26,120 --> 01:20:28,160 world today. So many technologies, so many 1639 01:20:28,160 --> 01:20:31,080 apps being built simply because of the existence of open source 1640 01:20:31,080 --> 01:20:33,680 technologies. So Yvgeni, thank you so much for 1641 01:20:33,680 --> 01:20:36,160 your time today. I think we cover a lot of things 1642 01:20:36,160 --> 01:20:38,680 and I'm sure listeners here are quite fascinated by some of the 1643 01:20:38,680 --> 01:20:40,840 things you mentioned. Unfortunately, due to time, we 1644 01:20:40,840 --> 01:20:42,640 have to, you know, wrap it up soon. 1645 01:20:42,840 --> 01:20:45,680 I have one last question which I always ask my guests, what I 1646 01:20:45,680 --> 01:20:47,400 call the three technical leadership wisdom. 1647 01:20:47,440 --> 01:20:49,000 You can think of it just like advice. 1648 01:20:49,160 --> 01:20:52,120 Maybe if you can share something for us to learn, maybe from your 1649 01:20:52,120 --> 01:20:53,960 journey or from your experience, what would they be? 1650 01:20:54,840 --> 01:20:56,160 I'll keep it really, really short. 1651 01:20:56,240 --> 01:20:58,680 Just repeat a few of the points we talked about earlier. 1652 01:20:59,080 --> 01:21:02,920 One, never stop learning. Always, always, always carve out 1653 01:21:02,920 --> 01:21:05,800 time for learning. Two, share what you learned. 1654 01:21:06,680 --> 01:21:10,120 And three, do things incrementally and iterate, 1655 01:21:10,280 --> 01:21:12,400 iterate and iterate. That's it. 1656 01:21:13,160 --> 01:21:14,720 Beautiful. So I think that kind of like 1657 01:21:14,720 --> 01:21:17,160 sums up pretty nice the conversation that we did today. 1658 01:21:17,400 --> 01:21:21,160 So if many people want to reach out to you or speak to you, ask 1659 01:21:21,160 --> 01:21:23,360 you more questions, is there a place where they can find you 1660 01:21:23,360 --> 01:21:26,120 online? Yeah, I'm on most of the typical 1661 01:21:26,120 --> 01:21:29,240 social media things. I'm on Twitter, LinkedIn, 1662 01:21:29,240 --> 01:21:31,960 Facebook, etcetera. And my homepage is Y 1663 01:21:31,960 --> 01:21:35,040 brickman.com. If you Google my name, anything 1664 01:21:35,040 --> 01:21:36,720 else, one of those things will come up. 1665 01:21:36,720 --> 01:21:38,600 I'm happy to chat on on any of those. 1666 01:21:39,640 --> 01:21:42,200 All right, so thank you so much, you know, for speaking with me 1667 01:21:42,200 --> 01:21:44,000 today. I hope you good luck for the 1668 01:21:44,000 --> 01:21:45,480 writing the last part of the book. 1669 01:21:45,480 --> 01:21:47,280 So looking forward for the release of the book. 1670 01:21:47,400 --> 01:21:49,120 So thank you so much for your time if Guinea. 1671 01:21:49,960 --> 01:21:51,200 Thanks for having me, it was fun.