1 00:00:00,040 --> 00:00:04,440 I saw a lot of people doing was just assuming that micro 2 00:00:04,440 --> 00:00:09,440 services were mini web servers. And sure a mini web server with 3 00:00:09,440 --> 00:00:13,600 a small API and sort of database is a micro service, but it's 4 00:00:13,600 --> 00:00:17,040 horrible architecture. So I think the way to do micro 5 00:00:17,040 --> 00:00:20,800 services, the Tao of micro services, is not to be obsessed 6 00:00:20,800 --> 00:00:24,240 with the network and Kubernetes and all that other stuff. 7 00:00:24,920 --> 00:00:29,840 To think of them first as software components and all the 8 00:00:29,840 --> 00:00:34,240 other stuff is, is just a consequence to get Legos, to get 9 00:00:34,240 --> 00:00:36,960 components. You can't have complex 10 00:00:36,960 --> 00:00:41,640 interfaces. I was very inspired by Unix 11 00:00:41,720 --> 00:00:43,760 pipes. So if you think about it, that's 12 00:00:43,760 --> 00:00:46,520 one of the most successful composer models ever built in 13 00:00:46,520 --> 00:00:49,360 the history of computing. And that's because the interface 14 00:00:49,840 --> 00:00:53,280 is really simple. It's just a stream of bytes from 15 00:00:53,280 --> 00:00:56,120 one process to another. Just because the network is 16 00:00:56,120 --> 00:00:58,760 unreliable doesn't mean a monolith is unreliable either. 17 00:00:59,320 --> 00:01:01,320 It's a fallacy to assume that you can build an error free 18 00:01:01,320 --> 00:01:03,440 system. The seven network fallacies are 19 00:01:03,440 --> 00:01:07,840 100% true, but you don't deal with them by trying to make the 20 00:01:07,840 --> 00:01:10,640 network infallible. You deal with them by accepting 21 00:01:10,640 --> 00:01:14,200 that system overall, even if it's a monolith, has a baseline 22 00:01:14,200 --> 00:01:16,520 error rate. And that's a business 23 00:01:16,520 --> 00:01:32,040 requirements issue. Hey guys, welcome back to 24 00:01:32,040 --> 00:01:34,320 another new episode of the Techni General Podcast. 25 00:01:34,320 --> 00:01:37,400 Today I have with me and author an interesting book, I must say, 26 00:01:37,440 --> 00:01:40,760 at the Tower of Micro Services. His name is Richard. 27 00:01:40,760 --> 00:01:42,680 Roger Richard, welcome to the show. 28 00:01:43,160 --> 00:01:46,760 Henry, thanks for having me on. Yeah, let's start arguing about 29 00:01:46,760 --> 00:01:50,000 micro services I'm looking forward to right, because, you 30 00:01:50,040 --> 00:01:52,440 know, everybody agrees on what micro services are and how to do 31 00:01:52,440 --> 00:01:54,480 them. There's no controversy at all. 32 00:01:55,320 --> 00:01:58,720 I'm sure we we'll get to a lot of different perspectives about 33 00:01:58,720 --> 00:02:00,640 microservices and monolith and things like that. 34 00:02:00,800 --> 00:02:03,880 But maybe let's start the show by asking about yourself, as if 35 00:02:03,880 --> 00:02:07,040 you can introduce, maybe telling us any highlights or turning 36 00:02:07,040 --> 00:02:09,280 points in your career that we all can learn from you. 37 00:02:10,080 --> 00:02:15,440 Yeah, I graduated in 97 and I studied mathematics and 38 00:02:15,440 --> 00:02:20,320 philosophy and by random luck the mathematics course at AC 39 00:02:20,320 --> 00:02:25,240 plus plus module. So I learned to code on VI, 40 00:02:25,240 --> 00:02:29,960 original VI on VT100, green screen terminals in the attic of 41 00:02:30,080 --> 00:02:33,520 the maths department. So of course I ended up in going 42 00:02:33,520 --> 00:02:37,040 into web development, right? It was just the pre.com boom 43 00:02:37,160 --> 00:02:39,640 era. The website that I'm most proud 44 00:02:39,640 --> 00:02:43,920 of, the fastest one I ever built was in C pure C. 45 00:02:44,440 --> 00:02:48,640 It was a real estate website. I didn't know about malloc so 46 00:02:48,680 --> 00:02:50,840 everything was statically allocated which is why it was 47 00:02:50,840 --> 00:02:55,200 really fast, but literally every operation was a buffer overflow 48 00:02:55,440 --> 00:02:58,120 waiting to happen. But it remains the fastest 49 00:02:58,120 --> 00:03:01,000 website I've ever built. I spent the 1st 10 years of my 50 00:03:01,000 --> 00:03:03,880 career as a back office Java developer. 51 00:03:03,880 --> 00:03:07,680 I pretty much went to no conferences, did almost no 52 00:03:07,680 --> 00:03:11,560 community stuff. I did read a lot of stuff, but I 53 00:03:11,560 --> 00:03:15,840 never really kind of engaged outside of what I was, what I 54 00:03:15,840 --> 00:03:21,880 was working on till I discovered Nojs and the Nojs community and 55 00:03:22,160 --> 00:03:26,000 kind of got out of my shell. I got into startups and the 56 00:03:26,000 --> 00:03:29,600 first successful startup that I was involved in that did exit 57 00:03:30,200 --> 00:03:33,360 after I left, unfortunately built the core tech as the CTO. 58 00:03:33,440 --> 00:03:37,520 We built something like a Roku for mobile apps, but if you use 59 00:03:37,520 --> 00:03:41,920 JavaScript on the back end, use the Rhino engine for JavaScript 60 00:03:42,280 --> 00:03:44,800 because we wanted it to be easy and quick to, you know, kind of 61 00:03:44,800 --> 00:03:49,080 like almost like no code, nearly quick to build a back end for 62 00:03:49,080 --> 00:03:54,040 mobile apps and developed a love for JavaScript, which is a weird 63 00:03:54,040 --> 00:03:58,720 language, but I don't know, once you kind of get over all the 64 00:03:58,720 --> 00:04:01,560 strange stuff, yeah, I don't know, it just kind of clicked in 65 00:04:01,560 --> 00:04:04,360 my brain. You know, I like the object 66 00:04:04,360 --> 00:04:08,280 prototype approach rather than the sort of hard classes. 67 00:04:08,800 --> 00:04:11,640 When I was doing Java, I read the Gang of Four design patterns 68 00:04:11,640 --> 00:04:13,320 book. I could tell you off by heart 69 00:04:13,360 --> 00:04:15,080 all the patterns, right? Visitor everything. 70 00:04:15,880 --> 00:04:17,519 And then when I discovered JavaScript, I realized you 71 00:04:17,519 --> 00:04:19,760 didn't have to actually use any of the patterns. 72 00:04:21,839 --> 00:04:23,600 You can just go pretty much functional. 73 00:04:24,120 --> 00:04:28,920 So myself and three other guys set up a consultancy based 74 00:04:28,920 --> 00:04:32,480 around Node JS and you know, sometimes you can get lucky. 75 00:04:32,640 --> 00:04:35,280 People talk about product market fit and if you have to ask the 76 00:04:35,280 --> 00:04:37,840 question, do you have product market fit, you don't. 77 00:04:38,320 --> 00:04:41,800 No, we were a product company. We tried, but we were just a 78 00:04:41,800 --> 00:04:44,440 consultancy. But Node was taking oath around 79 00:04:44,440 --> 00:04:49,000 that era since of 2012 and we were pretty much the biggest 80 00:04:49,000 --> 00:04:52,720 node consultancy in Europe. We started a few conferences, I 81 00:04:52,760 --> 00:04:55,560 started speaking at various conferences, that type of stuff 82 00:04:55,560 --> 00:04:58,160 and nothing took off. And within the space of two or 83 00:04:58,160 --> 00:05:00,440 three years, we had a big business, which is kind of 84 00:05:00,440 --> 00:05:02,920 crazy. So that was super fun, super 85 00:05:02,920 --> 00:05:05,400 stressful. And then we discovered that 86 00:05:06,040 --> 00:05:09,600 JavaScript is not a great language for writing large 87 00:05:09,600 --> 00:05:15,120 enterprise systems, but our clients wanted us because it was 88 00:05:15,120 --> 00:05:19,520 the hype of the thing. So that's how we ended up using 89 00:05:19,520 --> 00:05:23,600 micro services or the idea of micro services, but also ended 90 00:05:23,600 --> 00:05:26,360 up with a kind of a weird take, which we can get to in a little 91 00:05:26,360 --> 00:05:28,920 bit. But basically the limitations, I 92 00:05:28,920 --> 00:05:29,840 mean, it's weird, isn't it, right. 93 00:05:30,080 --> 00:05:32,400 I love the language JavaScript, but the limitations of 94 00:05:32,400 --> 00:05:34,320 JavaScript. And that's, I mean, I coded 95 00:05:34,320 --> 00:05:37,520 TypeScript now, but you got to remember JavaScript back then, 96 00:05:37,800 --> 00:05:41,120 ten years ago was pretty bad, right? 97 00:05:41,560 --> 00:05:44,920 It was kind of a sucky language. Once you've got any sort of code 98 00:05:44,920 --> 00:05:47,000 volume, you can't even refactor it. 99 00:05:47,000 --> 00:05:50,360 I mean, there's no type safety. Hopefully you wrote good unit 100 00:05:50,360 --> 00:05:53,360 tests, but they're probably tied to the implementation, so 101 00:05:53,360 --> 00:05:54,720 refactoring is almost impossible. 102 00:05:55,200 --> 00:05:58,920 So out of the vadnais of JavaScript, we ended up using 103 00:05:58,920 --> 00:06:03,320 micro services to compensate. It's funny how things like that 104 00:06:03,320 --> 00:06:06,000 go with softer, isn't it? You have this idea that there's 105 00:06:06,000 --> 00:06:09,240 some sort of perfection or ideal way to build systems, but it's 106 00:06:09,240 --> 00:06:12,200 very, as the physicists say, it's very path dependent. 107 00:06:12,760 --> 00:06:15,360 So where do I get to? I, I, I have to get to today 108 00:06:15,560 --> 00:06:17,040 because you asked about the career history. 109 00:06:17,120 --> 00:06:19,480 So yeah, yeah, consulting is great. 110 00:06:19,480 --> 00:06:21,480 But if anybody's working in consultancy, they know it's 111 00:06:21,480 --> 00:06:23,640 really hard work, tons of travel. 112 00:06:23,960 --> 00:06:29,240 And I'd still wanted to do a proper SAS, a proper traditional 113 00:06:29,400 --> 00:06:32,120 VC funded SAS. So because I've been doing a lot 114 00:06:32,120 --> 00:06:34,760 of conference speaking, I thought I'd spotted an 115 00:06:34,760 --> 00:06:38,960 opportunity in the event tech market, specifically a SAS 116 00:06:38,960 --> 00:06:43,920 solution to help people run booths and do sales league 117 00:06:43,920 --> 00:06:47,160 capture and recruiting. And because I mean, I was 118 00:06:47,160 --> 00:06:49,760 speaking at like a couple of conferences a month, but 119 00:06:49,760 --> 00:06:52,080 organizing it all using a spreadsheet, which kind of 120 00:06:52,080 --> 00:06:55,320 sucked. So I sold out of the consultancy 121 00:06:55,440 --> 00:06:59,280 and sold out to the other partners and set up a SAS 122 00:06:59,280 --> 00:07:04,240 business, did the Angel round, took in a good sized round, 123 00:07:04,640 --> 00:07:09,680 built the product, everything was fantastic until March 2020. 124 00:07:10,320 --> 00:07:14,600 So we lost all our customers to go in the space of a month and 125 00:07:14,600 --> 00:07:17,440 we had to pivot. Eventually, though, it took us 126 00:07:17,440 --> 00:07:20,400 about a year to figure out what to pivot into, but we realized 127 00:07:20,400 --> 00:07:25,800 that a key part of the market that we've been looking at was 128 00:07:25,840 --> 00:07:28,560 developer relations. And luckily, developer relations 129 00:07:28,560 --> 00:07:30,880 still has to happen even if there are no conferences. 130 00:07:31,640 --> 00:07:35,760 So yeah, we pivoted into that as a market, which is where we are 131 00:07:35,760 --> 00:07:38,800 now. However, it's never a simple 132 00:07:38,800 --> 00:07:41,960 straight line because of COVID, we never did a Series A. 133 00:07:42,600 --> 00:07:43,880 And you know, how do you survive? 134 00:07:43,880 --> 00:07:45,840 So guess what? Consulting. 135 00:07:46,720 --> 00:07:49,480 So I tried, I tried to get away from consulting, ended up doing 136 00:07:49,480 --> 00:07:51,840 it again. Luckily we're kind of refocusing 137 00:07:51,840 --> 00:07:54,720 on the product now, but I ended up doing consulting again for a 138 00:07:54,720 --> 00:07:58,560 few years, which, yeah, really put the ideas around micro 139 00:07:58,560 --> 00:08:01,600 services to the test again. Because I guess the interesting 140 00:08:01,600 --> 00:08:05,440 thing was that although we didn't make the entire Eventech 141 00:08:05,440 --> 00:08:10,320 platform open source, about 80% of it was open source plug in 142 00:08:10,320 --> 00:08:13,600 based. We'll get into why that approach 143 00:08:13,600 --> 00:08:17,000 was taken, but you know, that means that if you've built 144 00:08:17,000 --> 00:08:21,160 something that's based on a micro services architecture with 145 00:08:21,160 --> 00:08:26,960 open source components for one vertical event technology, it 146 00:08:26,960 --> 00:08:32,200 was a good litmus test for the adaptability of micro services. 147 00:08:32,200 --> 00:08:35,600 Can they be used in other consulting projects, in other 148 00:08:35,600 --> 00:08:37,520 domains? And I think we found that the 149 00:08:37,520 --> 00:08:40,520 answer was yes, but for a very particular reason. 150 00:08:40,520 --> 00:08:42,400 Now, I'll just tease it. We'll get into that later. 151 00:08:44,760 --> 00:08:48,240 And that brings us up to today. So yeah, the one regret I have 152 00:08:48,240 --> 00:08:51,680 and if anyone here is if any of your listeners are a junior 153 00:08:51,680 --> 00:08:57,200 engineer, I would say that a couple of years in a much larger 154 00:08:57,240 --> 00:09:00,560 big tech company is probably worth doing at some point in 155 00:09:00,560 --> 00:09:03,600 your career. I nearly nearly worked for SAP 156 00:09:03,960 --> 00:09:06,720 when I lived in Germany, but decided to chose a start up 157 00:09:06,720 --> 00:09:12,200 instead. But I probably should have taken 158 00:09:12,200 --> 00:09:14,040 the job in SAP for a couple of years. 159 00:09:14,440 --> 00:09:16,720 I mean, I, I've ended up having clients that are big companies, 160 00:09:16,720 --> 00:09:18,800 so I suppose I ended up understanding in that way. 161 00:09:18,800 --> 00:09:21,360 But even if you do intend to do a startup, I think it's 162 00:09:21,360 --> 00:09:23,560 important to work at a really big company to understand how 163 00:09:23,560 --> 00:09:25,360 they work so that you could sell to them. 164 00:09:25,840 --> 00:09:28,760 So that's I guess one, right? But apart from that, I've had 165 00:09:28,760 --> 00:09:32,240 lots of fun. I'm still coding, coding for 27 166 00:09:32,240 --> 00:09:33,840 years. Not going to stop. 167 00:09:34,920 --> 00:09:36,840 Wow. Do not intend to stop. 168 00:09:37,360 --> 00:09:41,280 Oh, that's the other thing. Yeah, you've got 20 good years 169 00:09:41,560 --> 00:09:45,040 from about 18 to 38. After that you've got to 170 00:09:45,040 --> 00:09:50,080 compensate with good design, because the old nighters don't 171 00:09:50,080 --> 00:09:53,480 work anymore and you can't code yourself out of complexity just 172 00:09:53,480 --> 00:09:57,720 with brute force because yeah, you lose IQ points, the brain 173 00:09:57,840 --> 00:10:01,440 starts degrading, unfortunately. So yeah, enjoy. 174 00:10:01,560 --> 00:10:06,000 Enjoy it while you can. Thank you for sharing your 175 00:10:06,000 --> 00:10:07,760 story, I think it's really interesting. 176 00:10:07,760 --> 00:10:09,640 Sounds like a roller coaster as well, right? 177 00:10:09,640 --> 00:10:12,280 So you've been into so many different journeys. 178 00:10:12,560 --> 00:10:14,680 So definitely there are a lot of learnings. 179 00:10:14,680 --> 00:10:17,760 But today we'll focus more on the micro services, right? 180 00:10:18,080 --> 00:10:21,200 In which you have written this book called The Tao of Micro 181 00:10:21,400 --> 00:10:23,600 Micro Services. But first of all, I'm quite 182 00:10:23,600 --> 00:10:25,960 interested, like why do you choose this title? 183 00:10:25,960 --> 00:10:28,240 You know the Tao. Is there any specific meaning 184 00:10:28,240 --> 00:10:32,760 behind it? Yeah, yeah, it's interesting. 185 00:10:32,760 --> 00:10:36,600 When you write stuff, sometimes you you can sort of forget to 186 00:10:37,360 --> 00:10:40,760 fully use a metaphor. And I'm currently doing the 2nd 187 00:10:40,760 --> 00:10:43,920 edition of the book, so hopefully I'll get to actually 188 00:10:43,920 --> 00:10:46,240 use the metaphor fully this time around. 189 00:10:46,680 --> 00:10:51,000 What it refers to is the fact that what I saw a lot of people 190 00:10:51,000 --> 00:10:55,080 doing was just assuming that micro services were mini web 191 00:10:55,080 --> 00:10:59,520 servers. And yes, OK, micro services is a 192 00:10:59,520 --> 00:11:01,280 very broad term, like everything in tech. 193 00:11:01,440 --> 00:11:06,480 And sure, a mini web server with a small API and some database is 194 00:11:06,480 --> 00:11:09,160 a micro service, but it's horrible architecture. 195 00:11:09,800 --> 00:11:13,200 It's you know, all those articles that you read 196 00:11:13,360 --> 00:11:16,760 criticizing microservices for people saying, oh, we're going 197 00:11:16,760 --> 00:11:19,960 back to a monolith because we had a really bad experience. 198 00:11:20,560 --> 00:11:22,840 They are all legitimate criticisms. 199 00:11:23,520 --> 00:11:25,760 I came at microservices from a totally different place. 200 00:11:25,760 --> 00:11:28,920 I felt there was a different way how it's kind of the way I felt 201 00:11:28,920 --> 00:11:31,760 there was a different more philosophical way to approach 202 00:11:31,760 --> 00:11:33,800 it. Let's talk about that because I 203 00:11:33,800 --> 00:11:39,000 think that's where a lot of the potential has been missed. 204 00:11:39,720 --> 00:11:42,240 It doesn't mean it it can't still be taken advantage of 205 00:11:42,720 --> 00:11:46,400 because the way we develop software is continuously 206 00:11:46,400 --> 00:11:50,600 evolving. So I worked as a researcher for 207 00:11:50,600 --> 00:11:52,600 a while. I had my very first startup 208 00:11:52,760 --> 00:11:54,280 failed. It's very important to have a 209 00:11:54,280 --> 00:11:57,240 failed first startup. I was completely broke. 210 00:11:57,560 --> 00:12:00,960 So I ended up working as a researcher at a local university 211 00:12:01,600 --> 00:12:06,240 and ended up working in the telecom space on IP telephony, 212 00:12:06,680 --> 00:12:09,600 which involves something called the session initiation protocol 213 00:12:09,880 --> 00:12:14,480 SIP, which is kind of like HTTP except state based and has loads 214 00:12:14,480 --> 00:12:18,080 more verbs. And if you imagine 2 phone, one 215 00:12:18,080 --> 00:12:21,000 phone ringing another, then it's you're sending like ringing 216 00:12:21,000 --> 00:12:22,720 state messages that I don't know. 217 00:12:22,920 --> 00:12:24,720 Henry, have you ever played around with any IP? 218 00:12:24,720 --> 00:12:27,640 So yeah, it's horribly complex. No, I wouldn't recommend it. 219 00:12:27,640 --> 00:12:30,640 In the startup that failed, I'd really gotten into, if you go 220 00:12:30,640 --> 00:12:32,600 back to the game, four design patterns, really got into the 221 00:12:32,600 --> 00:12:36,000 command pattern where you kind of encapsulate commands in the 222 00:12:36,000 --> 00:12:37,600 system. You can try to express all your 223 00:12:37,600 --> 00:12:39,760 business logic as commands right now. 224 00:12:39,760 --> 00:12:42,240 I mean, this is a very, very early version of something like 225 00:12:42,400 --> 00:12:47,440 CQRS, event based approaches, event sourcing perhaps, but very 226 00:12:47,440 --> 00:12:49,760 locked into the code, very hard coded. 227 00:12:50,400 --> 00:12:54,000 My experience working with IV telephony led me to think about 228 00:12:54,000 --> 00:12:58,640 the power of pattern matching. So the problem with receiving 229 00:12:59,160 --> 00:13:02,560 different stateful messages for IV telephony is that you have to 230 00:13:02,560 --> 00:13:04,640 decide what to do with them. So you're trying to write a 231 00:13:04,640 --> 00:13:07,680 little state machine, but first you have to match what's going 232 00:13:07,680 --> 00:13:09,400 on. And the application we were 233 00:13:09,400 --> 00:13:12,560 building, you have to provide customization. 234 00:13:12,600 --> 00:13:16,200 So we just ended up writing a really, really simple pattern 235 00:13:16,200 --> 00:13:18,680 matching algorithm. And so I mean, if you've written 236 00:13:18,680 --> 00:13:20,280 something, if you've used Haskell or something like that, 237 00:13:20,280 --> 00:13:22,880 you understand this idea of pattern matching. 238 00:13:22,880 --> 00:13:25,000 In fact, I think it's being introduced in a whole bunch of 239 00:13:25,000 --> 00:13:26,600 languages now. I think there's even something 240 00:13:26,600 --> 00:13:28,880 for JavaScript. It's literally the most brain 241 00:13:28,880 --> 00:13:32,200 dead simple approach thing you can think of where you're just 242 00:13:32,200 --> 00:13:35,280 look at a bag of properties and you're just matching against 243 00:13:35,280 --> 00:13:37,720 some of them. I mean, you can get more complex 244 00:13:38,120 --> 00:13:41,680 regular expressions or matching interior properties or whatever, 245 00:13:41,680 --> 00:13:43,720 but it doesn't really matter. All that matters is that you 246 00:13:43,720 --> 00:13:46,000 have this bag of properties, which might be adjacent document 247 00:13:46,000 --> 00:13:48,920 or HTTP request, and you're just picking a few that you care 248 00:13:48,920 --> 00:13:52,000 about and then using that to do more business logic. 249 00:13:52,400 --> 00:13:56,480 So when we got around to building Node JS applications, I 250 00:13:56,480 --> 00:13:58,560 kind of put these two ideas together and said, how do we 251 00:13:59,080 --> 00:14:04,960 turn the command pattern into a component model that uses 252 00:14:04,960 --> 00:14:07,000 pattern matching? So here's the thing about 253 00:14:07,000 --> 00:14:09,600 consulting, right? And have you ever worked worked 254 00:14:09,600 --> 00:14:12,080 as a consultant? Have you ever built websites for 255 00:14:12,080 --> 00:14:12,600 people? Yeah. 256 00:14:12,600 --> 00:14:16,040 OK, so here's the problem. It's the same job every time, 257 00:14:16,040 --> 00:14:17,000 really. OK. 258 00:14:17,480 --> 00:14:20,520 Because what we do is consultancy is we turn Excel 259 00:14:20,520 --> 00:14:23,720 into administration interfaces, right? 260 00:14:24,120 --> 00:14:27,080 And there's always user management and permissions and 261 00:14:27,080 --> 00:14:29,920 projects and groups and there's always data ingestion, there's 262 00:14:29,920 --> 00:14:32,200 always report generation. Maybe some of them have a 263 00:14:32,200 --> 00:14:33,920 mapping application or something like that. 264 00:14:34,000 --> 00:14:35,960 But business applications are always the same. 265 00:14:36,560 --> 00:14:39,240 So if you're building a consultancy, you want to be able 266 00:14:39,240 --> 00:14:42,880 to reuse stuff because that makes you more efficient, better 267 00:14:42,960 --> 00:14:46,000 job. And Node was very open source, 268 00:14:46,000 --> 00:14:51,000 so a lot of the MPM registry was growing exponentially. 269 00:14:51,120 --> 00:14:52,560 I know that has its own problems, right? 270 00:14:53,480 --> 00:14:56,720 The problem is a lot of those components were technical 271 00:14:56,720 --> 00:15:00,120 libraries. So stuff for like sending e-mail 272 00:15:00,360 --> 00:15:05,240 or reading an Excel file or database drivers or Orms, right? 273 00:15:05,240 --> 00:15:07,760 That type of thing. Yeah, they're components, but 274 00:15:07,760 --> 00:15:10,520 the problem is every one of them has like an API that you have to 275 00:15:10,520 --> 00:15:12,280 learn. And they're infrastructure. 276 00:15:12,760 --> 00:15:15,960 They're not business logic. So let's say you're building a 277 00:15:16,280 --> 00:15:19,520 referral system. Your users can invite each other 278 00:15:19,520 --> 00:15:22,200 into the application. The logic is pretty much the 279 00:15:22,200 --> 00:15:24,880 same every time. So how do you build a referral 280 00:15:24,880 --> 00:15:28,680 component that you can reuse? That was the problem that we 281 00:15:28,680 --> 00:15:31,680 were facing. So we built the system where it 282 00:15:31,680 --> 00:15:34,600 was event based. The only interface between 283 00:15:34,600 --> 00:15:39,960 components was a Jason document, and the routing was based on 284 00:15:39,960 --> 00:15:42,360 pattern matching. Your system consists of. 285 00:15:42,720 --> 00:15:44,040 This is before micro services, right? 286 00:15:44,040 --> 00:15:46,600 It's a single process application, just a single node 287 00:15:46,600 --> 00:15:49,320 process running on a bare metal server. 288 00:15:49,480 --> 00:15:51,160 This is the way we built things back in the day. 289 00:15:51,520 --> 00:15:55,040 I built an entire newspaper system using this description 290 00:15:55,040 --> 00:15:58,240 bottle, Apple Pay, everything. But the whole architecture of 291 00:15:58,240 --> 00:16:01,840 the system consisted of very isolated components. 292 00:16:02,080 --> 00:16:05,400 The only interface input and output was effectively Jason 293 00:16:05,400 --> 00:16:08,360 documents. The routing to decide where a 294 00:16:08,360 --> 00:16:10,440 message went was based on pattern matching. 295 00:16:11,040 --> 00:16:14,520 And that meant that you could define a referral service, let's 296 00:16:14,520 --> 00:16:18,480 say by a set of messages, so an invitation that's happened, or 297 00:16:18,480 --> 00:16:23,120 generate an invitation code, or give this user a reward based on 298 00:16:23,120 --> 00:16:26,040 the fact that the invitation code has been redeemed by 299 00:16:26,040 --> 00:16:29,280 defining Jason documents. And you could have schemas if 300 00:16:29,280 --> 00:16:32,080 you wanted, right? But essentially you didn't have 301 00:16:32,080 --> 00:16:34,000 to. So when a message comes into the 302 00:16:34,000 --> 00:16:37,080 system, you might have some tags that say this is a referral 303 00:16:37,080 --> 00:16:38,880 message and it goes to the referral component. 304 00:16:39,400 --> 00:16:44,280 So that was fun until about 2014 until like I said, things get 305 00:16:44,280 --> 00:16:46,880 too big, right? It's very hard to manage a 306 00:16:46,880 --> 00:16:48,960 system like that. It's hard to scale it. 307 00:16:49,400 --> 00:16:52,040 I mean, you can for sure, you can deploy multiple monoliths 308 00:16:52,040 --> 00:16:54,520 and put them behind load balancers and all that sort of 309 00:16:54,520 --> 00:16:56,880 stuff. But then we started noticing 310 00:16:56,880 --> 00:17:01,960 things like serverless and Docker and micro services idea 311 00:17:01,960 --> 00:17:05,079 was kind of in the air and it was just an obvious next step to 312 00:17:05,079 --> 00:17:08,480 say, OK, well, why don't we take the referral component and turn 313 00:17:08,480 --> 00:17:12,160 it into a micro service and then we can deploy it independently 314 00:17:12,160 --> 00:17:13,960 and we could scale it independently and get all those 315 00:17:13,960 --> 00:17:16,680 benefits. But the important thing is it's 316 00:17:16,680 --> 00:17:20,800 not a mini web server. It's not a mini API endpoint. 317 00:17:21,280 --> 00:17:24,800 It only knows how to receive and send Jason documents. 318 00:17:24,800 --> 00:17:27,160 That's it. So that's how we ended up with 319 00:17:27,240 --> 00:17:29,240 that. That's how we ended up in a 320 00:17:29,240 --> 00:17:31,600 place where we were using micro services. 321 00:17:31,640 --> 00:17:35,600 But with a component oriented approach. 322 00:17:35,880 --> 00:17:38,760 So I think the way to do micro services, the Tau of micro 323 00:17:38,760 --> 00:17:43,560 services is not to be obsessed with the network and Kubernetes 324 00:17:43,680 --> 00:17:46,920 and all that other stuff. To think of them first as 325 00:17:46,920 --> 00:17:52,000 software components and all and all the other stuff is is just a 326 00:17:52,000 --> 00:17:53,800 consequence. Right. 327 00:17:54,480 --> 00:17:57,080 I think that this is a quite unique perspective because I 328 00:17:57,080 --> 00:18:00,360 think from all the journeys of micro service that I have 329 00:18:00,360 --> 00:18:03,640 followed, right, I think it has gone from ups and downs, for 330 00:18:03,640 --> 00:18:06,680 example, from monolith to micro service and then it goes back 331 00:18:06,760 --> 00:18:08,880 into monolith. These days some people call it 332 00:18:08,880 --> 00:18:11,240 modular monolith or whatever that is, right? 333 00:18:11,480 --> 00:18:14,440 But I think that there are still places where micro services 334 00:18:14,440 --> 00:18:17,680 could actually work. And sometimes some people 335 00:18:17,680 --> 00:18:20,560 advocate things like domain driven design, bounded context 336 00:18:20,760 --> 00:18:22,640 to actually create a proper boundary. 337 00:18:22,920 --> 00:18:26,920 But the one that you just mentioned is actually to think 338 00:18:26,920 --> 00:18:29,720 of micro services in terms of three different things that I 339 00:18:29,720 --> 00:18:31,160 could gather from the book, right? 340 00:18:31,320 --> 00:18:34,000 The 1st is about designing the message first. 341 00:18:34,240 --> 00:18:36,240 So things like the Jason document you mentioned. 342 00:18:36,440 --> 00:18:39,720 Second is the pattern matching, which is kind of like, you know, 343 00:18:39,720 --> 00:18:42,800 associate the kind of shape of the message and then you route 344 00:18:42,800 --> 00:18:44,240 it differently to different services. 345 00:18:44,600 --> 00:18:46,960 And the last thing is about additivity. 346 00:18:46,960 --> 00:18:50,440 You know, like think of it like you can compose, for example, if 347 00:18:50,440 --> 00:18:52,160 you want to work on some workflows, right? 348 00:18:52,160 --> 00:18:54,960 You compose that kind of workflow using different 349 00:18:54,960 --> 00:18:57,880 components or micro services. So maybe, yeah, this is I think 350 00:18:57,880 --> 00:19:01,400 the true maybe the tower of the way of you defining micro 351 00:19:01,400 --> 00:19:03,520 services. So tell us about why these three 352 00:19:03,520 --> 00:19:07,560 are so important and why do you advocate this approach instead 353 00:19:07,560 --> 00:19:10,720 of, you know, some of the more popular way of designing micro 354 00:19:10,720 --> 00:19:13,680 service? Yeah, it comes back to this idea 355 00:19:13,680 --> 00:19:16,680 of components. First, you actually mentioned 356 00:19:16,680 --> 00:19:19,400 the most important one, which is composition. 357 00:19:19,960 --> 00:19:22,760 If you're designing object oriented system these days, you 358 00:19:22,760 --> 00:19:25,680 should prefer composition over inheritance, right? 359 00:19:25,680 --> 00:19:29,720 So inheritance people realize that inherent, you know, basic 360 00:19:29,720 --> 00:19:31,240 inheritance is probably a bad idea. 361 00:19:31,680 --> 00:19:34,320 You end up tying yourself in knots, whereas composing these 362 00:19:34,320 --> 00:19:37,080 together is the way to go. So I mean, what's a component 363 00:19:37,080 --> 00:19:39,040 system? It's Lego, right? 364 00:19:39,080 --> 00:19:42,040 It's meant to be like you're 10 years old and you're building a 365 00:19:42,040 --> 00:19:44,920 spaceship with Lego and the things just click together. 366 00:19:45,440 --> 00:19:47,760 So how do you get to that point? How does that work? 367 00:19:47,760 --> 00:19:50,440 Because everybody who's worked on large enterprise systems know 368 00:19:50,440 --> 00:19:53,120 that they're not Lego. The refactoring is horrible. 369 00:19:53,120 --> 00:19:56,080 I mean, everybody's had a iteration where you have to stop 370 00:19:56,080 --> 00:20:00,040 the world and refactor. So the composition element is 371 00:20:00,040 --> 00:20:03,000 really, really important. And I think the pattern matching 372 00:20:03,320 --> 00:20:06,520 gives that to you in with a really nice mental model. 373 00:20:06,520 --> 00:20:10,240 So first of all, I should say separately, the implementation 374 00:20:10,240 --> 00:20:13,240 details here don't matter. We built an open source 375 00:20:13,760 --> 00:20:16,880 framework for doing this. But it's actually pretty small. 376 00:20:17,400 --> 00:20:19,000 You could do this in any language. 377 00:20:19,720 --> 00:20:23,440 You could literally write one from scratch for a Greenfield 378 00:20:23,440 --> 00:20:26,160 project or whatever. You don't particularly need to 379 00:20:26,160 --> 00:20:28,760 use a framework. It's it's more of a philosophy 380 00:20:28,760 --> 00:20:31,520 than than a framework. Pattern matching gives you 381 00:20:31,520 --> 00:20:37,040 composition because it allows you to easily go from the 382 00:20:37,040 --> 00:20:42,560 general to the specific. So one of my go to examples is 383 00:20:42,760 --> 00:20:46,320 let's say user management. When you start building the 384 00:20:46,320 --> 00:20:49,040 system you might already have, you might already decide there's 385 00:20:49,040 --> 00:20:51,520 one type of user in the system and there's a little bit of 386 00:20:51,520 --> 00:20:53,520 logic to deal with that. So I don't know. 387 00:20:53,520 --> 00:20:58,000 Assigning a user to a project is 1 Jason document with a few tags 388 00:20:58,000 --> 00:20:58,960 that you could have and match up. 389 00:20:59,560 --> 00:21:02,720 But that only gets you through maybe two or three iterations 390 00:21:02,720 --> 00:21:05,120 because of course, systems don't have one type of user. 391 00:21:05,120 --> 00:21:07,800 They have admin users and they have project managers and they 392 00:21:07,800 --> 00:21:10,720 have group permissions and all sorts of crazy stuff. 393 00:21:10,720 --> 00:21:16,160 So if you have an assigned user to project message, that is 394 00:21:16,160 --> 00:21:19,720 general, very simple, right? It's just adding an entry to a 395 00:21:19,720 --> 00:21:22,920 database table and setting up very basic permissions. 396 00:21:23,240 --> 00:21:25,480 That's your first implementation, but you might 397 00:21:25,480 --> 00:21:27,280 have additional business logic that has to happen. 398 00:21:27,280 --> 00:21:31,480 If it's an admin user, there's a special value that has to go in 399 00:21:31,480 --> 00:21:34,680 or something into the database or they have to be put into a 400 00:21:34,680 --> 00:21:37,680 central registry. There's some sort of extra thing 401 00:21:37,680 --> 00:21:40,000 that has to happen. So in most systems, what you'd 402 00:21:40,000 --> 00:21:43,000 end up doing is adding a whole bunch of if statements in that 403 00:21:43,000 --> 00:21:46,240 logic, say, oh, if it's an admin user, do this extra stuff, but 404 00:21:46,240 --> 00:21:48,560 that's not composable. What you want to do is you want 405 00:21:48,560 --> 00:21:51,360 to leave the old code alone. Pretty much that just handles 406 00:21:51,360 --> 00:21:55,360 normal users. Run that code and then also run 407 00:21:55,520 --> 00:21:58,160 extra code that handles the admin case. 408 00:21:58,680 --> 00:22:02,960 So what you can do is either before or after. 409 00:22:03,360 --> 00:22:06,720 And again, this is pretty simple to implement because all you're 410 00:22:06,720 --> 00:22:09,560 doing is you're saying, take a look at Jason documents and if a 411 00:22:09,560 --> 00:22:11,440 few of the properties match, do something. 412 00:22:11,800 --> 00:22:15,120 So I can say, OK, my properties match for adding a user to a 413 00:22:15,120 --> 00:22:17,080 project, add the user to the project. 414 00:22:17,640 --> 00:22:22,920 Oh, there's also A tag that says this user is admin, so I'm also 415 00:22:22,920 --> 00:22:25,240 going to trigger the admin user message. 416 00:22:25,880 --> 00:22:27,880 You mentioned additivity, right? So that's additive. 417 00:22:28,480 --> 00:22:31,880 The old code stays the same and then here's the new code and you 418 00:22:31,880 --> 00:22:33,400 click it into the system like a Lego brick. 419 00:22:33,960 --> 00:22:35,200 And you can do that for all sorts of things. 420 00:22:35,200 --> 00:22:37,800 It's particularly cool for cross cutting concerns. 421 00:22:37,800 --> 00:22:41,320 So one of my other favorite examples there is, let's say you 422 00:22:41,320 --> 00:22:45,320 want to have like creation time and an updated time in your 423 00:22:45,480 --> 00:22:49,400 database rows across the board for all of your data entities. 424 00:22:49,840 --> 00:22:53,360 Well, if you encode the data entity operations, you know, 425 00:22:53,400 --> 00:22:57,720 saving and loading as messages, then the pattern matching can 426 00:22:57,720 --> 00:23:02,040 intercept those messages and add in creation time and save time, 427 00:23:02,360 --> 00:23:05,440 auditing permissions checks, whatever, all sorts of fun stuff 428 00:23:06,080 --> 00:23:09,800 without that being visible in the business logic code. 429 00:23:10,320 --> 00:23:13,280 The point is, you want to keep your business logic as business 430 00:23:13,280 --> 00:23:14,880 logic, right? Business logic shouldn't be 431 00:23:14,880 --> 00:23:18,560 setting creation times or worrying about permissions or 432 00:23:18,560 --> 00:23:21,120 any of that sort of stuff. So if you have these additive 433 00:23:21,120 --> 00:23:24,720 components, you can see how it's pretty easy to start saying, 434 00:23:24,720 --> 00:23:27,320 well, maybe they actually live on separate parts of the network 435 00:23:27,680 --> 00:23:30,880 and maybe the messages can flow over the network to make these 436 00:23:30,880 --> 00:23:36,120 things happen because it's all just pattern matched routing. 437 00:23:36,680 --> 00:23:39,960 The business object code has no knowledge of whether something 438 00:23:39,960 --> 00:23:42,400 is on the network or not. So you can run the whole thing 439 00:23:42,400 --> 00:23:44,680 as a monolith. And this is how we develop, 440 00:23:44,680 --> 00:23:46,560 correct? We run the whole thing as a 441 00:23:46,560 --> 00:23:49,520 monolith locally. I mean, local development with 442 00:23:49,520 --> 00:23:51,760 real microservices. And I have done this and I have, 443 00:23:52,080 --> 00:23:54,880 you know, killed my machines like 30 Docker services and 444 00:23:54,880 --> 00:23:57,360 crazy stuff like that. These are not lessons that 445 00:23:57,360 --> 00:23:59,080 weren't learned without a lot of blood. 446 00:23:59,480 --> 00:24:04,320 But you can run locally as a modular monolith because you've 447 00:24:04,320 --> 00:24:08,000 got your modules. And then our favorite deployment 448 00:24:08,000 --> 00:24:12,960 these days is split up the messages by domain and deploy 449 00:24:12,960 --> 00:24:16,080 them as Lambdas. And that's really cool because 450 00:24:16,080 --> 00:24:18,400 you don't have to worry about running things in separate 451 00:24:18,400 --> 00:24:21,400 service locally. You can use Terraforms, 452 00:24:21,400 --> 00:24:24,160 something like that to automate the deployment of the lambdas. 453 00:24:24,160 --> 00:24:27,960 So you you don't you're not worrying about working with 454 00:24:27,960 --> 00:24:30,560 lambdas and deploying stuff to debug and all that Lambda 455 00:24:30,560 --> 00:24:34,800 development is kind of sucky. And then the other big thing 456 00:24:34,800 --> 00:24:38,800 that the component based approach gives you is really 457 00:24:38,800 --> 00:24:41,160 simple mocking. So anybody who's ever tried to 458 00:24:41,160 --> 00:24:45,800 build unit tests and build mocks is some, well, I don't know, 459 00:24:45,800 --> 00:24:48,160 have you have you heard of the banana monkey jungle problem? 460 00:24:48,520 --> 00:24:51,480 No, I haven't. So this is a, this is AI tried 461 00:24:51,480 --> 00:24:53,560 to imagine it in a very posh English accent, because I 462 00:24:53,560 --> 00:24:56,720 learned about this from a friend of mine who used to be a fusion 463 00:24:56,720 --> 00:24:58,400 scientist. He worked on the joint European 464 00:24:58,400 --> 00:24:59,800 tourist. So he's very clever chap. 465 00:25:00,320 --> 00:25:02,760 So you must be right. So the problem with a lot of, 466 00:25:02,760 --> 00:25:04,120 and I mean, this is a big problem in Java. 467 00:25:04,120 --> 00:25:06,760 The problem with writing unit tests in a lot of systems is 468 00:25:06,760 --> 00:25:09,000 that you have all this dependency and you have to do 469 00:25:09,000 --> 00:25:10,760 dependency injection, all that some crazy stuff. 470 00:25:10,760 --> 00:25:13,720 So you need a banana to unit test the banana, right? 471 00:25:13,920 --> 00:25:16,280 But unfortunately to get the banana you need a monkey. 472 00:25:17,720 --> 00:25:20,160 And if you need a monkey, you have to get the whole jungle, 473 00:25:20,160 --> 00:25:21,160 right? So you basically have to 474 00:25:21,440 --> 00:25:23,960 bootstrap your entire system to do a small unit test. 475 00:25:24,480 --> 00:25:28,960 Now, if the only way that your system is exposed is via Jason 476 00:25:28,960 --> 00:25:31,400 documents, then mocking them is really simple. 477 00:25:31,880 --> 00:25:35,000 You just hard code the response. You don't need all the rest of 478 00:25:35,000 --> 00:25:38,520 the infrastructure. You don't need to have mocking 479 00:25:38,520 --> 00:25:40,720 utilities that will build complex. 480 00:25:40,720 --> 00:25:44,280 AP is, and I think this is, it's a point I make in the book, 481 00:25:44,280 --> 00:25:48,160 actually, I just remembered. To get Legos to get components, 482 00:25:48,160 --> 00:25:50,840 you can't have complex interfaces. 483 00:25:51,280 --> 00:25:55,560 You think about modern languages, they try to present 484 00:25:55,560 --> 00:26:00,880 the class as a component, but classes have methods, they have 485 00:26:01,080 --> 00:26:04,480 interfaces, they have static methods, they have member 486 00:26:04,480 --> 00:26:07,280 variables, they have annotations. 487 00:26:07,520 --> 00:26:08,760 Are they singletons? Are they? 488 00:26:09,440 --> 00:26:12,080 And it only gets worse, right? Because in order for the 489 00:26:12,080 --> 00:26:14,520 language to have power, the class construct has to have lots 490 00:26:14,520 --> 00:26:15,880 of different ways to interface with it. 491 00:26:16,560 --> 00:26:19,400 So now you have to learn a new API each time, and someone has 492 00:26:19,400 --> 00:26:23,120 to model that whole idea of user types in a system that would 493 00:26:23,120 --> 00:26:25,720 have to be modelled. So now you've got to interface 494 00:26:25,720 --> 00:26:28,680 with it somehow, and it's very hard to compose together. 495 00:26:29,240 --> 00:26:33,160 I was very inspired by Unix pipes. 496 00:26:33,640 --> 00:26:35,400 So if you think about it, that's one of the most successful 497 00:26:35,400 --> 00:26:38,080 composer models ever built in the history of computing. 498 00:26:38,600 --> 00:26:41,600 And that's because the interface is really simple. 499 00:26:41,600 --> 00:26:45,040 It's just a stream of bytes from one process to another. 500 00:26:45,680 --> 00:26:47,800 So that has its own problems. It's a little bit too simple. 501 00:26:48,200 --> 00:26:50,080 I don't recommend building. I mean, people have, right? 502 00:26:50,080 --> 00:26:53,800 But I don't recommend building enterprise systems with streams 503 00:26:53,800 --> 00:26:56,120 of bytes. So you need to just up the 504 00:26:56,120 --> 00:26:57,840 complexity a tiny little bit more, right? 505 00:26:57,840 --> 00:27:01,520 So Jason Documents, I used to be really big into XML, by the way. 506 00:27:02,480 --> 00:27:04,760 I've written XML parse results of fun stuff. 507 00:27:05,120 --> 00:27:07,840 It's cool, but it's so painful, which is why I like Jason so 508 00:27:07,840 --> 00:27:09,440 much, right? Because it does make life a 509 00:27:09,440 --> 00:27:11,480 little bit easier, even though I could really do with having 510 00:27:11,480 --> 00:27:14,320 comments. But anyway, if you up the 511 00:27:14,320 --> 00:27:17,760 complexity just a tiny bit and you allow the messages that go 512 00:27:17,760 --> 00:27:23,280 between components to be Jason documents, and then you, you 513 00:27:23,280 --> 00:27:26,400 know, apply that leniency principle where Postal's law, I 514 00:27:26,400 --> 00:27:29,080 think it's called, where you're leaning too much, you accept and 515 00:27:29,080 --> 00:27:33,040 strict in what you omit. It's just powerful enough to 516 00:27:33,040 --> 00:27:35,680 build enterprise systems. When you use pattern machines, 517 00:27:36,280 --> 00:27:38,320 it covers about 95% of use cases. 518 00:27:38,320 --> 00:27:42,320 For the 5% it doesn't. You always have to be able to 519 00:27:42,320 --> 00:27:45,160 expose the actual underlying API, right? 520 00:27:45,160 --> 00:27:48,760 Always have a get out of jail free card, but 95% is pretty 521 00:27:48,760 --> 00:27:50,480 good. I've kind of covered a lot of 522 00:27:50,480 --> 00:27:54,400 ground, but I'm trying to get the philosophy Yeah, in one 523 00:27:54,400 --> 00:27:56,680 body. So I have some follow up 524 00:27:56,680 --> 00:27:59,160 questions actually. So when we think about these 525 00:27:59,160 --> 00:28:02,120 messages, right, you keep mentioning about Jason documents 526 00:28:02,120 --> 00:28:04,200 and things like that. Some people also these days have 527 00:28:04,280 --> 00:28:08,080 even driven architecture, right, even like modelling software as 528 00:28:08,080 --> 00:28:10,120 events. Is this message you are talking 529 00:28:10,120 --> 00:28:12,280 about the same as kind of like an event? 530 00:28:12,520 --> 00:28:14,320 From my understanding, it seems not. 531 00:28:14,440 --> 00:28:17,800 I mean like it's not fully 100%. And then how does this pattern 532 00:28:17,800 --> 00:28:19,600 matching work against the message? 533 00:28:19,600 --> 00:28:22,520 Because when you talk about composability, I think it's kind 534 00:28:22,520 --> 00:28:26,200 of like easy to, how should I say easy to think about when you 535 00:28:26,200 --> 00:28:28,880 talk about function calls or maybe like Unix pipe. 536 00:28:29,080 --> 00:28:31,400 But when you have different micro services and you have 537 00:28:31,400 --> 00:28:34,160 different network calls and databases, how does this 538 00:28:34,160 --> 00:28:35,920 composability work? And not to mention the 539 00:28:35,920 --> 00:28:38,760 transaction as well. So maybe if you can maybe 540 00:28:38,760 --> 00:28:40,800 elaborate a little bit more on these two parts. 541 00:28:41,120 --> 00:28:45,320 Yeah, so my concept of messages is a bit more general and I'll 542 00:28:45,320 --> 00:28:47,360 actually refer to the book because I did spend a bit of 543 00:28:47,360 --> 00:28:50,400 time in the book creating an architectural structure for 544 00:28:50,400 --> 00:28:54,280 thinking about it. So event sourcing is very much 545 00:28:55,560 --> 00:28:58,160 unidirectional flow and that's a great idea. 546 00:28:58,160 --> 00:29:01,280 And it's a core benefit is that writes go in One Direction and 547 00:29:01,280 --> 00:29:02,520 reads come from a different place. 548 00:29:03,000 --> 00:29:06,400 It's a kind of a one way system. The real world is a little bit 549 00:29:06,400 --> 00:29:09,400 messier, especially since you might be dealing with legacy 550 00:29:09,400 --> 00:29:10,880 systems and all that sort of stuff. 551 00:29:11,000 --> 00:29:14,440 And a great many AP is are designed to be request response. 552 00:29:14,840 --> 00:29:19,920 So I identify kind of two axes that messages could operate on. 553 00:29:20,480 --> 00:29:24,360 So this is one of them is whether they're synchronous or 554 00:29:24,360 --> 00:29:27,080 asynchronous. So synchronous messages expect a 555 00:29:27,080 --> 00:29:29,320 response. You send a message and you you 556 00:29:29,360 --> 00:29:31,000 expect a response, you're waiting for a response. 557 00:29:31,000 --> 00:29:35,240 So if I save something to the database, I expect a response 558 00:29:35,280 --> 00:29:38,040 confirming that it's saved. It gives me a new ID, something 559 00:29:38,040 --> 00:29:42,480 like that. Asynchronous messages are ones 560 00:29:42,480 --> 00:29:45,360 where you just emit them and you don't know, right? 561 00:29:45,760 --> 00:29:47,240 Somebody might act on them, you just don't know. 562 00:29:47,880 --> 00:29:51,600 And then the other one is whether they're consumed or not. 563 00:29:51,960 --> 00:29:56,600 So you can think of a classic message queue where you're 564 00:29:56,600 --> 00:29:58,640 sitting there as a listener and the message comes from the queue 565 00:29:58,640 --> 00:30:01,280 and you take it and process it and then the message is deleted. 566 00:30:01,800 --> 00:30:04,000 Amazon simple queue service, something like that, right? 567 00:30:04,600 --> 00:30:08,840 Or you can think of something like Kafka where there might be 568 00:30:08,840 --> 00:30:11,720 multiple readers. So one of the people that I 569 00:30:11,720 --> 00:30:14,360 found really inspiring in the early days, microservices, and 570 00:30:14,520 --> 00:30:16,680 if you go onto YouTube and look for his talks, they're 571 00:30:16,680 --> 00:30:20,160 absolutely fantastic, is a guy called Fred George who built a 572 00:30:20,160 --> 00:30:22,320 lot of the early micro services systems. 573 00:30:22,760 --> 00:30:25,200 One of the examples he gives is insurance quotes. 574 00:30:25,280 --> 00:30:28,320 So you're trying to do dynamic insurance quoting. 575 00:30:28,800 --> 00:30:31,520 So somebody types in their details and they give me quotes 576 00:30:31,520 --> 00:30:34,200 and the system could process for about 30 seconds. 577 00:30:34,680 --> 00:30:37,480 So the way he implemented that system was that messages would 578 00:30:37,480 --> 00:30:41,200 go out to lots of different micro services that could handle 579 00:30:41,200 --> 00:30:44,600 different types of quotes and then they would all provide 580 00:30:44,600 --> 00:30:47,320 quotes and then there would be some business logic to rank them 581 00:30:47,320 --> 00:30:51,240 or something like that. And that's an example of a 582 00:30:51,880 --> 00:30:55,120 system where the messages are not, they're not consumed by 583 00:30:55,120 --> 00:30:57,160 single service, they're broadcast. 584 00:30:57,600 --> 00:31:00,280 So when you're building a system, you can think of it in 585 00:31:00,280 --> 00:31:03,560 terms of whether the messages request response or whether it's 586 00:31:03,560 --> 00:31:07,680 more like event sourcing. So whatever way you get messages 587 00:31:07,680 --> 00:31:10,680 from micro service A to micro service B, whatever way the 588 00:31:10,680 --> 00:31:13,840 routing works, whatever the pattern matching works, give 589 00:31:13,840 --> 00:31:15,720 yourself that freedom because you will need it. 590 00:31:16,200 --> 00:31:19,800 But I mean, sometimes the criticism that I get and 591 00:31:19,800 --> 00:31:22,080 something that sometimes I've heard people struggle with is 592 00:31:22,080 --> 00:31:24,520 that they think I'm hand waving when I'm saying our message 593 00:31:24,520 --> 00:31:27,400 routing is do whatever you like. So let me give you a very 594 00:31:27,400 --> 00:31:31,440 concrete example. So recently we built an AI chat 595 00:31:31,440 --> 00:31:34,360 bot for podcasts, right? It lets you kind of interrogate 596 00:31:34,360 --> 00:31:36,640 guests. It's kind of fun, just as a kind 597 00:31:36,640 --> 00:31:40,880 of fun side project. And that runs in Amazon, uses 598 00:31:40,880 --> 00:31:42,800 Simple Q service. And if you think about it, 599 00:31:42,800 --> 00:31:45,360 there's all sorts of stuff. You have to download the RSS 600 00:31:45,360 --> 00:31:46,760 feed and then you have to download the audio. 601 00:31:46,760 --> 00:31:48,520 And then if you have transcripts, and then you have 602 00:31:48,520 --> 00:31:51,120 to chunk the transcript and then you have to put it in the vector 603 00:31:51,120 --> 00:31:55,040 database and do all the fun stuff, talk to the models to get 604 00:31:55,040 --> 00:31:58,360 the vectors. So it's very much batch 605 00:31:58,360 --> 00:32:01,720 processing flow. It's very much messages go from 606 00:32:01,920 --> 00:32:03,440 A to B through different lambdas. 607 00:32:03,880 --> 00:32:06,680 And if you built lambdas and use SQS, the way that works is you 608 00:32:06,680 --> 00:32:12,000 have named topics and one Lambda will submit a message to a named 609 00:32:12,000 --> 00:32:15,560 topic and then another Lambda is listening to the named topic. 610 00:32:15,960 --> 00:32:18,600 So that doesn't fit my model because if you think about it, 611 00:32:19,000 --> 00:32:20,920 those named topics are hard coded. 612 00:32:21,320 --> 00:32:24,480 But I won't have a situation where I'm free and easy and I 613 00:32:24,640 --> 00:32:27,480 I'm not stuck with topics. I just want to send my message 614 00:32:27,480 --> 00:32:29,080 and it magically gets to the right place. 615 00:32:30,280 --> 00:32:34,720 So in my my modular monolith that I'm building locally when 616 00:32:34,720 --> 00:32:38,320 I'm developing the system, I just say that my, let's say my 617 00:32:38,320 --> 00:32:41,640 audio downloader microservice will listen for messages that 618 00:32:41,640 --> 00:32:46,080 say here's the RSS. And then it gets the RSS and it 619 00:32:46,080 --> 00:32:47,960 can look for the audio file download. 620 00:32:48,400 --> 00:32:51,720 Which means that my component that downloads the RSS can emit 621 00:32:51,720 --> 00:32:53,880 that message. Everything happens in one 622 00:32:53,880 --> 00:32:56,480 process. I have a tiny little algorithm 623 00:32:56,480 --> 00:33:01,040 that looks at the keys of a Jason object in memory and then 624 00:33:01,040 --> 00:33:02,480 makes a method call to the right place. 625 00:33:02,480 --> 00:33:08,080 So somehow I have to translate that to Lambda SQS architecture. 626 00:33:08,640 --> 00:33:12,680 Initially when we started doing it, stuff like that was moved 627 00:33:12,680 --> 00:33:17,880 into configuration. So you would say, OK, these 628 00:33:17,880 --> 00:33:20,720 patterns of messages, yeah, it's like when you have a hammer, 629 00:33:20,720 --> 00:33:23,880 everything is a male, right? These patterns of messages all 630 00:33:23,880 --> 00:33:27,520 mapped to this topic queue. So I have an extra bit of code 631 00:33:27,520 --> 00:33:30,280 that or an extra plug in, let's say that I deploy, when I'm 632 00:33:30,280 --> 00:33:33,320 deploying to Amazon, that intercepts the messages. 633 00:33:33,320 --> 00:33:35,000 This is a common pattern, right? Intercepting. 634 00:33:35,000 --> 00:33:37,840 It's just pattern matching like anything else, except this time 635 00:33:37,840 --> 00:33:39,080 it doesn't do any business logic. 636 00:33:39,600 --> 00:33:42,960 This time it does transport. It'll transport the messages for 637 00:33:42,960 --> 00:33:45,080 you. And for a long time that 638 00:33:45,080 --> 00:33:49,720 configuration was done like any configuration system, right? 639 00:33:49,720 --> 00:33:53,920 It was in the code you configure that and there are option 640 00:33:53,920 --> 00:33:55,640 configurations for these plug insurance. 641 00:33:56,120 --> 00:33:58,320 But one of the reasons that I decided to do a second edition 642 00:33:58,320 --> 00:34:01,680 of the book is model driven architecture. 643 00:34:01,760 --> 00:34:06,400 So this is giving anybody who's my age nightmares at this stage. 644 00:34:06,960 --> 00:34:10,639 So about 20 years ago, it was really, there was this a lot of 645 00:34:10,639 --> 00:34:16,440 hype around UML diagrams and you would literally architect the 646 00:34:16,440 --> 00:34:20,000 system as a blueprint and then all of the junior coders would 647 00:34:20,000 --> 00:34:21,600 just type it out basically, right? 648 00:34:22,120 --> 00:34:24,560 Total failure because that's how my software actually works. 649 00:34:25,520 --> 00:34:28,400 But I think there was a kernel of an idea there that was really 650 00:34:28,400 --> 00:34:31,639 good, which is that. And sorry, then you can combine 651 00:34:31,639 --> 00:34:33,679 that with like domain driven design and things like that to 652 00:34:33,679 --> 00:34:37,600 say there has to be a higher level abstract description of 653 00:34:37,600 --> 00:34:40,320 the system that's above the code in some way. 654 00:34:40,760 --> 00:34:43,000 And I mean, we use that all the time these days, right? 655 00:34:43,000 --> 00:34:46,239 So YAML definitions for serverless deployments, 656 00:34:46,360 --> 00:34:48,480 Kubernetes infrastructure as code, right? 657 00:34:49,159 --> 00:34:54,040 But you can have architecture as code as well, not diagrams, 658 00:34:54,040 --> 00:34:55,320 right? Not visual programming, because 659 00:34:55,320 --> 00:34:58,800 that never works. But you can essentially use all 660 00:34:58,800 --> 00:35:03,000 of the very robust configuration tools that we have these days. 661 00:35:03,120 --> 00:35:06,640 There's a lot of them, right? So take the ideas in Terraform 662 00:35:06,640 --> 00:35:11,040 or Palumi or things like that and create a type safe model of 663 00:35:11,040 --> 00:35:14,800 the system where you are listing your database tables and you're 664 00:35:14,800 --> 00:35:17,000 listing your services and you're listing your messages. 665 00:35:17,640 --> 00:35:21,040 And then you can do things like say, oh, here's the Lambda 666 00:35:21,040 --> 00:35:23,920 deployment context. And in that context, these 667 00:35:23,920 --> 00:35:29,240 messages go to this topic in SQS and Bats. 668 00:35:29,240 --> 00:35:32,760 Now, deployment configuration completely separate from 669 00:35:32,760 --> 00:35:34,880 business logic. So I never have to, when I'm 670 00:35:34,880 --> 00:35:39,440 writing my podcast subscription code, my audio download code, I 671 00:35:39,440 --> 00:35:42,920 never have to care. I just don't care how they talk 672 00:35:42,920 --> 00:35:45,160 to each other. I just know I can take for 673 00:35:45,160 --> 00:35:46,600 granted that the message will get delivered. 674 00:35:47,080 --> 00:35:50,000 And then you add in lots of the modern observability, like open 675 00:35:50,000 --> 00:35:51,960 telemetry for actually debugging that. 676 00:35:52,240 --> 00:35:55,240 And yeah, it's kind of fun. We've a lot of fun these days. 677 00:35:56,040 --> 00:35:58,720 Right, I can also see a few alternatives to pattern 678 00:35:58,720 --> 00:36:00,440 matching. I mean tell me if this is not 679 00:36:00,440 --> 00:36:02,720 correct, right? So you can use something like a 680 00:36:02,720 --> 00:36:07,240 server path routing, right? So where you have HTTP/A goes to 681 00:36:07,440 --> 00:36:11,800 a service slash B to B service. Or you can also take the message 682 00:36:11,840 --> 00:36:15,840 bus approach right where you have some business rules so to 683 00:36:15,840 --> 00:36:18,480 speak, right in the message bus to actually route to different 684 00:36:18,480 --> 00:36:20,720 topics. Or maybe in like Rabbit MQ you 685 00:36:20,720 --> 00:36:23,600 have different channel and exchanges and things like that. 686 00:36:23,920 --> 00:36:26,920 Is that also the same kind of thing when you mention about 687 00:36:26,920 --> 00:36:30,440 pattern matching? Yeah, I have a very big hammer. 688 00:36:32,080 --> 00:36:36,920 They're all nails. So the issue is the power that 689 00:36:36,920 --> 00:36:40,080 you get from keeping everything to pattern matching is that 690 00:36:40,160 --> 00:36:42,720 things like unit testing and mocking get much easier. 691 00:36:43,160 --> 00:36:46,680 Or especially if you have junior developers on the team, the only 692 00:36:46,680 --> 00:36:50,200 API that they interact with is essentially you can send 693 00:36:50,200 --> 00:36:55,280 messages or receive them. Now we do add a little ORM 694 00:36:55,280 --> 00:36:57,280 layer, right? Not Object Relational Mapper. 695 00:36:57,520 --> 00:37:00,640 That actually becomes messages. Anyway, we'll talk about that in 696 00:37:00,640 --> 00:37:01,720 a minute because that is quite powerful. 697 00:37:01,720 --> 00:37:06,480 But when the junior developer is writing business logic code, all 698 00:37:06,480 --> 00:37:10,240 they should ever be doing is sending and receiving messages, 699 00:37:10,800 --> 00:37:12,440 loading and saving stuff to the database. 700 00:37:12,920 --> 00:37:15,000 That's it. So if those messages are coming 701 00:37:15,000 --> 00:37:19,360 in from Rabbit and Q or they're coming in from HTTP request or 702 00:37:19,360 --> 00:37:22,880 whatever, the routing should translate that first. 703 00:37:23,400 --> 00:37:26,040 So for example, on the HTTP side of things, what we've written 704 00:37:26,040 --> 00:37:28,960 for ourselves is little gateway plug insurance that will 705 00:37:28,960 --> 00:37:31,760 translate. So locally, I'm old school, we 706 00:37:31,760 --> 00:37:34,520 still use the Node library Express for local development. 707 00:37:34,520 --> 00:37:38,640 So we have a little gateway that can translate Express inbound 708 00:37:38,640 --> 00:37:41,720 Http://requests into a Jason document. 709 00:37:42,400 --> 00:37:45,000 Yeah, there are, you know, a subset of requests where you 710 00:37:45,000 --> 00:37:47,160 need to be able to access the headers and all that sort of 711 00:37:47,160 --> 00:37:49,800 stuff to do both. But again, you can use the 712 00:37:49,800 --> 00:37:52,400 pattern routing because that's a cross cutting concern. 713 00:37:52,400 --> 00:37:55,480 You can put it elsewhere and you can just restrict business logic 714 00:37:55,480 --> 00:37:56,920 to saying here's a Jason document. 715 00:37:57,400 --> 00:38:00,760 It happened to come in this case from HTTP. 716 00:38:01,360 --> 00:38:03,680 But you don't know, maybe it's a unit test, right? 717 00:38:03,680 --> 00:38:06,560 So you know, the way unit testing APIs is really painful 718 00:38:06,560 --> 00:38:09,400 because you have to simulate AP Http://requests. 719 00:38:09,760 --> 00:38:11,280 You know, there's a few people that do it really well, like 720 00:38:11,280 --> 00:38:14,280 Fastify. Yeah, I'm obviously using no JS 721 00:38:14,280 --> 00:38:16,440 examples here. Fastify is really good system 722 00:38:16,440 --> 00:38:19,040 for simulating inbound HTV requests. 723 00:38:19,560 --> 00:38:22,040 But the issue there is to use that you have to commit to 724 00:38:22,040 --> 00:38:23,560 Fastify. The problem is if you're 725 00:38:23,560 --> 00:38:26,800 deploying to Lambdas, well there you're not really using Fastify. 726 00:38:26,800 --> 00:38:30,400 I mean, you could, but generally you just want to use the events 727 00:38:30,400 --> 00:38:32,480 that Amazon sends. So now you have a whole 728 00:38:32,480 --> 00:38:35,120 different system. So you have another little plug 729 00:38:35,120 --> 00:38:37,480 in that can translate Amazon events. 730 00:38:37,920 --> 00:38:42,680 We recently had a scenario where we built a system on AWS, spent 731 00:38:42,680 --> 00:38:47,840 six months building the system, enterprise system to be told one 732 00:38:47,840 --> 00:38:51,080 month before deployment that corporate policy was that 733 00:38:51,080 --> 00:38:55,080 everything had to run on Azure. So you can imagine that in most 734 00:38:55,080 --> 00:38:57,400 scenarios that that's a total disaster. 735 00:38:57,880 --> 00:39:02,160 If you have used any Amazon AP is directly you're in trouble. 736 00:39:02,480 --> 00:39:05,920 But because we've modeled the whole system as messages, all we 737 00:39:05,920 --> 00:39:08,640 had to write and we already had some because we obviously built 738 00:39:08,640 --> 00:39:11,320 other Azure systems. All we have to do was write 739 00:39:11,320 --> 00:39:15,360 things like a little gateway plug in for Azure Functions 740 00:39:15,800 --> 00:39:18,560 which have a slightly different inbound message for which by the 741 00:39:18,560 --> 00:39:20,280 way is adjacent document anyway, right? 742 00:39:20,920 --> 00:39:25,400 There's another good analogy for this approach which is AWS 743 00:39:25,400 --> 00:39:28,080 Eventbridge. So if you've used Eventbridge at 744 00:39:28,080 --> 00:39:33,640 all, it's actually very similar or Erlang OTP, similar style. 745 00:39:33,800 --> 00:39:37,800 These are all either influences or same basic idea. 746 00:39:38,320 --> 00:39:44,160 So yeah, it is a very, very big hammer and I doubt advocating 747 00:39:44,160 --> 00:39:47,800 for a very specific approach to building large scale enterprise 748 00:39:47,800 --> 00:39:50,760 systems. But at the same time, it's all 749 00:39:50,760 --> 00:39:53,240 driven by this idea that you really want a composable 750 00:39:53,240 --> 00:39:55,880 component model and the only way to get there is to have a 751 00:39:55,880 --> 00:39:59,400 simplified API. So you always want to hide 752 00:39:59,400 --> 00:40:02,640 things like Rabbit in Q or the fact that it's actually be 753 00:40:02,640 --> 00:40:04,960 requested at the end of the day. One final thing I'll say on that 754 00:40:04,960 --> 00:40:07,680 is I'm very much aware of the seven fallacies. 755 00:40:09,160 --> 00:40:12,160 Network architecture. And I know very well that what 756 00:40:12,160 --> 00:40:14,760 I'm advocating for is to pretend the network doesn't exist, but 757 00:40:15,040 --> 00:40:17,880 that's a different discussion. Yeah, I think the one that you 758 00:40:17,880 --> 00:40:20,640 mentioned like it's called transport independence in your 759 00:40:20,640 --> 00:40:22,760 book, right. So yeah, even though you use web 760 00:40:22,760 --> 00:40:25,440 server, HDP web server or you use message queue or you use 761 00:40:25,440 --> 00:40:27,880 some other mechanism, I think it doesn't matter as long as you. 762 00:40:28,000 --> 00:40:31,240 So I'll translate that into messages and you use some kind 763 00:40:31,240 --> 00:40:34,320 of pattern matching to be able to route to different services. 764 00:40:34,720 --> 00:40:37,200 And I think this key about composability is something that 765 00:40:37,280 --> 00:40:40,200 maybe not many developers naturally think that way, 766 00:40:40,200 --> 00:40:42,920 because if you think about adding user types, most of the 767 00:40:42,920 --> 00:40:46,480 people will just refactor the code and tweak the portion and 768 00:40:46,480 --> 00:40:48,080 do if else and that kind of thing. 769 00:40:48,440 --> 00:40:50,800 But I think doing pattern matching maybe is like the 770 00:40:50,800 --> 00:40:52,360 functional paradigm as well, right? 771 00:40:52,400 --> 00:40:56,440 The functional programming paradigm. 100% I mean, I stole 772 00:40:56,440 --> 00:40:58,440 the idea from Erlang totally, yeah. 773 00:40:59,360 --> 00:41:02,640 So I think these are definitely the heuristics that you advocate 774 00:41:02,640 --> 00:41:04,720 whenever you design micro services. 775 00:41:04,720 --> 00:41:07,640 And obviously in your book you also covered about model driven, 776 00:41:07,720 --> 00:41:10,000 you know, like modeling code. Yeah, yeah. 777 00:41:10,280 --> 00:41:13,200 Which, yeah, some people like it, some don't, but we probably 778 00:41:13,360 --> 00:41:14,000 won't. Diagrams. 779 00:41:14,120 --> 00:41:17,200 That's that's the secret. It's all code. 780 00:41:17,200 --> 00:41:18,760 It's all code. Yeah. 781 00:41:19,240 --> 00:41:23,080 So maybe as part of this everlasting debate about micro 782 00:41:23,080 --> 00:41:26,040 service versus monolith, what's your take about monolith, by the 783 00:41:26,040 --> 00:41:28,240 way? So do you actually ban monolith 784 00:41:28,240 --> 00:41:31,280 at all in your software design, or do you actually find that 785 00:41:31,280 --> 00:41:34,120 monoliths still have a case? No. 786 00:41:34,120 --> 00:41:37,600 So, you know, because we use a modular monolith effectively for 787 00:41:37,600 --> 00:41:41,040 local developments, it's a wonderful get out of jail card 788 00:41:41,040 --> 00:41:43,640 because that project that we're selling that where we had to 789 00:41:43,640 --> 00:41:47,080 move to Azure, we converted everything from Lambdas to Azure 790 00:41:47,080 --> 00:41:52,560 functions, set everything up. And in the last week, I turned 791 00:41:52,560 --> 00:41:57,920 out that the admin who could give us appropriate permissions 792 00:41:57,920 --> 00:42:00,800 was on holiday. So there was no way for us to 793 00:42:00,800 --> 00:42:04,560 get enough permissions to make the system work and go live by 794 00:42:04,560 --> 00:42:07,280 the deadline. So our solution ended up being 795 00:42:07,480 --> 00:42:13,280 to run AVM and run the system as a monolith in production. 796 00:42:13,760 --> 00:42:16,160 And now there were some performance issues, right? 797 00:42:16,160 --> 00:42:19,360 Because this is where micro services are great for scaling 798 00:42:19,360 --> 00:42:21,840 because parts of the system can scale independently. 799 00:42:21,840 --> 00:42:25,080 So we did have to deal with some performance issues, but we had 800 00:42:25,080 --> 00:42:27,520 to get out of jail card and that we could, It was nothing to do 801 00:42:27,520 --> 00:42:30,040 with the software architecture, but the dynamics of the 802 00:42:30,040 --> 00:42:31,800 politics. The project meant that the only 803 00:42:31,800 --> 00:42:34,040 way we could go live was to deploy monolith. 804 00:42:34,400 --> 00:42:36,880 So we still had that option. And I would not have had that 805 00:42:36,880 --> 00:42:40,680 option five years ago. I mean, this is when people say 806 00:42:40,680 --> 00:42:43,520 micro services are crazy and monoliths are easy. 807 00:42:43,520 --> 00:42:45,720 They're right. And when people say, you know, 808 00:42:45,720 --> 00:42:49,600 if you're building an NVP, maybe you should just build a monolith 809 00:42:49,600 --> 00:42:51,880 to begin with. And I actually agree, right? 810 00:42:51,880 --> 00:42:55,080 Just deploy it on a bare metal hexer server or something for 811 00:42:55,080 --> 00:42:58,480 $10 a month. But wouldn't it be nice if it 812 00:42:58,480 --> 00:43:03,000 was a component based model that you could turn into lambdas or a 813 00:43:03,000 --> 00:43:05,480 big Kubernetes deployments without having to rewrite the 814 00:43:05,480 --> 00:43:08,520 whole thing? It doesn't have to be my 815 00:43:08,520 --> 00:43:10,920 specific approach to pattern matching. 816 00:43:10,920 --> 00:43:14,400 It doesn't have to be node JS. You just have to start from a 817 00:43:14,400 --> 00:43:17,320 place of saying that my system should be composed of 818 00:43:17,720 --> 00:43:20,800 components, and all the components should have the same, 819 00:43:21,200 --> 00:43:23,760 just like Legos, they should have the same interface. 820 00:43:24,240 --> 00:43:25,960 And that's really where all the power comes from. 821 00:43:26,200 --> 00:43:29,680 Yeah, it's one of those silly debates that isn't real, but it 822 00:43:29,680 --> 00:43:33,080 comes from places like, I mean, I'll tell you, we were brought 823 00:43:33,080 --> 00:43:39,000 into a large enterprise client. This would be maybe 2016. 824 00:43:39,560 --> 00:43:42,360 Micro services are getting really popular and they built a 825 00:43:42,360 --> 00:43:45,400 whole load of mini web servers and they were running about 60 826 00:43:45,400 --> 00:43:48,240 micro services. And the problem is that even 827 00:43:48,240 --> 00:43:50,320 though they've given all the developers really powerful 828 00:43:50,320 --> 00:43:53,520 laptops, as a developer you couldn't run the system locally. 829 00:43:53,960 --> 00:43:59,280 So every developer was also given a large Amazon instance to 830 00:43:59,280 --> 00:44:01,960 run the system so they could develop against it. 831 00:44:02,400 --> 00:44:04,960 And I mean, of course, if you come into a set up like that 832 00:44:04,960 --> 00:44:07,760 where you have a team of 50 developers that can't even run 833 00:44:07,760 --> 00:44:10,400 the system locally, of course you're going to cope with micro 834 00:44:10,400 --> 00:44:13,520 services are utter nonsense. Why on earth would you do this 835 00:44:13,520 --> 00:44:16,640 to yourself? The only people that I've ever 836 00:44:16,640 --> 00:44:19,720 seen that have actually managed to make the mini web service 837 00:44:19,720 --> 00:44:23,800 thing work is Netflix. I mean, they had the resources 838 00:44:23,800 --> 00:44:25,280 and the brain power to make it work. 839 00:44:25,760 --> 00:44:28,120 If you look at their open source and all their tooling and all 840 00:44:28,120 --> 00:44:30,400 that sort of stuff, wow. I mean, it's amazing. 841 00:44:30,400 --> 00:44:33,440 I mean, yeah, there's a fantastic way to control 842 00:44:33,440 --> 00:44:36,440 everything, but it kind of tells the story, doesn't it in, in 843 00:44:36,440 --> 00:44:40,240 that they needed all that brainpower and resources to make 844 00:44:40,240 --> 00:44:43,160 it work, you know, And I, as an advocate of micro services, you 845 00:44:43,160 --> 00:44:45,600 know, surely the easy Rd. is to use Netflix stuff. 846 00:44:45,600 --> 00:44:50,360 But I don't have a team of 20 Stanford graduates to make it 847 00:44:50,400 --> 00:44:54,000 all work. Not to mention running all those 848 00:44:54,120 --> 00:44:56,880 Netflix tools right? I think that might be quite a 849 00:44:56,880 --> 00:44:58,120 set of people. Right. 850 00:44:58,120 --> 00:44:59,680 Exactly. I mean, I'm sure there are other 851 00:44:59,680 --> 00:45:01,280 people who've who've done a really good job of it. 852 00:45:01,720 --> 00:45:06,040 Netflix open source, I kind of tell, yeah, it's what's the 853 00:45:06,040 --> 00:45:07,800 Spider Man purse. With great power comes great 854 00:45:07,800 --> 00:45:10,880 responsibility. So I guess services are really 855 00:45:10,880 --> 00:45:12,360 cool and you can do really cool stuff. 856 00:45:12,360 --> 00:45:16,160 But as the Australians say, they can be a massive foot gun as 857 00:45:16,160 --> 00:45:18,720 well, right? So, so maybe let's go into what 858 00:45:18,720 --> 00:45:21,600 you mentioned just now about the network policy and also the 859 00:45:21,600 --> 00:45:23,640 data. I think these two typically are 860 00:45:24,000 --> 00:45:25,600 the the two biggest things, right? 861 00:45:25,600 --> 00:45:29,280 So network is you can't assume network is always reliable and 862 00:45:29,280 --> 00:45:31,200 fast. And second thing is about data. 863 00:45:31,200 --> 00:45:35,040 When you have your data passing across multiple services, 864 00:45:35,040 --> 00:45:36,680 there's no atomicity anymore, right? 865 00:45:36,800 --> 00:45:39,640 Everything is like an eventual consistency and how do you 866 00:45:39,640 --> 00:45:42,880 reconcile if there are failures in one part of the service into 867 00:45:42,880 --> 00:45:44,320 the other? Yes, yeah. 868 00:45:44,440 --> 00:45:48,480 OK, so here's the thing. Just because the network is 869 00:45:48,480 --> 00:45:51,120 unreliable doesn't mean a monolith is unreliable either. 870 00:45:51,680 --> 00:45:56,120 You know, when I used to deploy monoliths in C and Java, stuff 871 00:45:56,120 --> 00:45:59,200 like that, VMS would run out of disk space because the logs have 872 00:45:59,440 --> 00:46:01,280 used up everything, right? Or memory leaks, right? 873 00:46:01,280 --> 00:46:04,840 I mean, when I used to run Java servers, but we used to just 874 00:46:04,840 --> 00:46:07,440 restart them every 24 hours because of memory leaks. 875 00:46:07,960 --> 00:46:11,280 But the problem is if you just randomly restart a server at 876 00:46:11,280 --> 00:46:13,320 4:00 AM in the morning, well, that's not 4:00 AM for 877 00:46:13,320 --> 00:46:14,880 everybody. You could be in the middle of 878 00:46:14,880 --> 00:46:16,120 transaction and they can just die. 879 00:46:16,800 --> 00:46:19,920 So if you walk into a supermarket, do you think that 880 00:46:20,000 --> 00:46:24,240 the prices are 100% accurate across every single label of 881 00:46:24,240 --> 00:46:28,400 every single product? No, there's actually in the USI 882 00:46:28,400 --> 00:46:33,080 think the law is the federal regulation is that they allow 2% 883 00:46:33,080 --> 00:46:35,040 error rate. So the price that you see on the 884 00:46:35,040 --> 00:46:38,240 shelf is incorrect up to 2% of the time. 885 00:46:38,960 --> 00:46:42,640 I think, and again, this is inspired by Erlang, you have to 886 00:46:42,640 --> 00:46:46,960 design your systems to accept and a baseline error rate of 887 00:46:46,960 --> 00:46:50,120 some kind because weird stuff is always going to happen. 888 00:46:50,480 --> 00:46:52,600 Yes, the network is going to make that a bit higher. 889 00:46:52,600 --> 00:46:55,480 Of course the trade off is always the trade off is that you 890 00:46:55,480 --> 00:46:58,000 get scale. So you have to look at your 891 00:46:58,000 --> 00:47:00,240 business case and think about what the mitigations are going 892 00:47:00,240 --> 00:47:03,000 to be. If you're building a, a consumer 893 00:47:03,000 --> 00:47:05,680 app, you know that's to do with user generated content. 894 00:47:05,680 --> 00:47:08,480 I mean, how many times have you used Reddit and it doesn't load? 895 00:47:08,480 --> 00:47:10,200 It's like we try load again, right? 896 00:47:10,240 --> 00:47:12,320 So I mean, who cares? There was a network failure, 897 00:47:12,320 --> 00:47:14,720 just reload. I've built banking apps and I 898 00:47:14,720 --> 00:47:17,400 can tell you that they're very careful with their mainframe 899 00:47:17,400 --> 00:47:19,800 COBOL systems that do the actual transactions. 900 00:47:19,800 --> 00:47:22,720 But I can also tell you that there are backroom staff that 901 00:47:22,760 --> 00:47:26,280 reconcile problems. I mean, have has your bank been 902 00:47:26,280 --> 00:47:29,200 100% correct over your entire lifetime? 903 00:47:29,400 --> 00:47:31,680 You hear these stories of people who are like magically have 904 00:47:31,680 --> 00:47:34,040 $10,000 appear in their account, this type of stuff. 905 00:47:34,720 --> 00:47:39,080 So it's a fallacy or telcos and they're five nines up time. 906 00:47:39,640 --> 00:47:42,680 I mean, have you ever had a cell phone call fail? 907 00:47:43,120 --> 00:47:45,080 It's a fallacy to assume that you can build an error free 908 00:47:45,080 --> 00:47:46,520 system. So then you have to look at the 909 00:47:46,520 --> 00:47:49,120 business case around what the mitigation is going to be and is 910 00:47:49,120 --> 00:47:51,600 that is it serious enough that you have to have a backroom 911 00:47:51,600 --> 00:47:54,440 staff overnight like banks fixing things? 912 00:47:54,720 --> 00:47:58,800 Do you solve it economically by compensating your users in some 913 00:47:58,800 --> 00:48:00,800 way? Are you Google where your profit 914 00:48:00,800 --> 00:48:03,560 margins are so great that you know, what if your search 915 00:48:03,560 --> 00:48:05,360 results aren't that good anymore, it doesn't really 916 00:48:05,360 --> 00:48:09,120 matter, right? So yes, the never, I mean that, 917 00:48:09,320 --> 00:48:12,720 you know, the seven network fallacies are 100% true, but you 918 00:48:12,720 --> 00:48:16,680 don't deal with them by trying to make the network infallible. 919 00:48:17,080 --> 00:48:19,880 You deal with them by accepting that system overall, even if 920 00:48:19,880 --> 00:48:22,400 it's a monolith, has a baseline error rate. 921 00:48:22,400 --> 00:48:25,080 And that's a business requirements issue. 922 00:48:25,600 --> 00:48:27,960 And sometimes it's just, I mean, for a lot of systems, it just 923 00:48:27,960 --> 00:48:29,920 doesn't matter. It's just hit reload in the 924 00:48:29,920 --> 00:48:32,920 browser and keep going. Especially a lot of back office 925 00:48:32,920 --> 00:48:34,800 enterprise systems, that's just the way they work. 926 00:48:34,800 --> 00:48:37,680 It's a little bit different for some types of consumer apps 927 00:48:37,680 --> 00:48:41,040 where a baseline error rate might mean that you get hundreds 928 00:48:41,040 --> 00:48:43,120 of support requests a day, right? 929 00:48:43,520 --> 00:48:46,040 So that's going to suck. So here's, I mean, here's the 930 00:48:46,040 --> 00:48:48,600 interesting thing that the modular component based approach 931 00:48:48,600 --> 00:48:51,360 can do for you. If you're finding that this a 932 00:48:51,360 --> 00:48:53,960 micro service A and micro service B that are really 933 00:48:53,960 --> 00:48:57,600 codependent and you're getting an error rate due to network 934 00:48:57,600 --> 00:49:01,640 issues that's too high. Well, combine them into one 935 00:49:01,640 --> 00:49:04,000 deployment artifact, right? Turn those network polls into 936 00:49:04,120 --> 00:49:06,360 back into function polls. Now you're, they're still 937 00:49:06,360 --> 00:49:08,760 modular because the the interface is still just the 938 00:49:08,760 --> 00:49:12,360 messages, but you may find that you're beautifully designed, 939 00:49:13,000 --> 00:49:17,720 partitioned, are domain driven architecture has 10% of cases 940 00:49:17,720 --> 00:49:20,800 that need to be optimized. And when you have to optimize 941 00:49:20,920 --> 00:49:23,160 code, the code just looks bad, right? 942 00:49:25,680 --> 00:49:28,600 So you stick them together and deploy them as one artifact. 943 00:49:28,840 --> 00:49:30,480 So that's the networking side of things. 944 00:49:31,040 --> 00:49:34,400 The data side of things is interesting. 945 00:49:35,080 --> 00:49:39,080 So first of all, it's kind of similar in that if you actually 946 00:49:39,080 --> 00:49:43,240 look at the details of transactions in traditional 947 00:49:43,240 --> 00:49:46,160 database systems, if you actually look at what they 948 00:49:46,160 --> 00:49:49,320 guarantees they offer, they're not actually that good. 949 00:49:50,560 --> 00:49:53,080 If you look at the specific details, like if you look at 950 00:49:53,080 --> 00:49:55,880 Oracle, right, there's actually, I think 4, there's four 951 00:49:55,880 --> 00:49:59,800 different transaction levels. You might see old data and you 952 00:49:59,800 --> 00:50:01,960 might end up having to use them because you need the throughput 953 00:50:01,960 --> 00:50:03,680 of your system or it might not matter. 954 00:50:03,880 --> 00:50:07,360 So designing a system where you need to do distributed 955 00:50:07,360 --> 00:50:10,200 transactions, yeah, that kind of sucks. 956 00:50:10,200 --> 00:50:13,080 It's a void if possible. Unfortunately, it may not be 957 00:50:13,080 --> 00:50:15,400 possible, especially if it's a large enterprise system, 958 00:50:15,400 --> 00:50:18,320 multiple teams. But hey, you know what, even in 959 00:50:18,320 --> 00:50:20,440 those scenarios, there's usually like a lot of different models. 960 00:50:20,440 --> 00:50:22,160 So you still have the same problem, right? 961 00:50:22,600 --> 00:50:26,640 So then you're in enterprise service buses and reversing 962 00:50:26,640 --> 00:50:28,040 things and all that sort of stuff. 963 00:50:28,720 --> 00:50:31,720 You just use SAPSAP Solved this in the 1980s. 964 00:50:32,800 --> 00:50:35,600 No seriously. Like if you look at R3, if you 965 00:50:35,600 --> 00:50:39,080 look at the SAP system, it's like the perfect micro service 966 00:50:39,080 --> 00:50:42,600 deployment system. They have solved all this stuff. 967 00:50:42,840 --> 00:50:45,840 It's just you need like $2000 a day consultants to actually make 968 00:50:45,840 --> 00:50:49,080 it work. So especially if you're not 969 00:50:49,320 --> 00:50:53,640 building mega scale systems, try very hard to keep transactions 970 00:50:53,640 --> 00:50:57,000 contained inside one service, one unit of deployment. 971 00:50:57,520 --> 00:51:00,440 And if you've got this modular architecture, then again, you 972 00:51:00,440 --> 00:51:03,640 can stick things together. The other thing which I advocate 973 00:51:03,640 --> 00:51:07,480 in the book is don't just go to transactions automatically. 974 00:51:07,960 --> 00:51:09,680 There's loads of other approaches you can use. 975 00:51:10,280 --> 00:51:14,080 I mean, even sort of brute force things like having a batch 976 00:51:14,080 --> 00:51:17,040 process that will correct data that's gone slightly wrong. 977 00:51:17,640 --> 00:51:20,440 Reservations. So reservations are really cool. 978 00:51:20,520 --> 00:51:22,880 That's kind of a standard algorithm to prevent like double 979 00:51:22,880 --> 00:51:24,800 spending. I mean, I won't go into the 980 00:51:24,800 --> 00:51:26,760 specifics of it, but you're basically creating database 981 00:51:26,760 --> 00:51:29,800 entries that basically block other things from happening. 982 00:51:30,280 --> 00:51:32,920 But it doesn't need, it just needs atomic rights. 983 00:51:32,960 --> 00:51:36,560 You don't need transactions. I'm a little bit naughty when it 984 00:51:36,560 --> 00:51:39,440 comes to the database. I have to say I don't mind micro 985 00:51:39,440 --> 00:51:41,520 services sharing databases or tables. 986 00:51:42,200 --> 00:51:45,520 I don't know where that idea came from, this kind of 987 00:51:45,520 --> 00:51:49,760 obsession with purity of the database per micro service. 988 00:51:50,560 --> 00:51:53,280 I guess if I may provide my understanding, right, it's 989 00:51:53,280 --> 00:51:57,600 because of the leaky internal data model that if you use two 990 00:51:57,600 --> 00:52:00,480 different services sharing the same database, right, the other 991 00:52:00,480 --> 00:52:02,920 service could just say, oh, I see this table, I see this data, 992 00:52:02,920 --> 00:52:06,080 I'll just query it and, you know, think of it as if like, 993 00:52:06,080 --> 00:52:08,920 it's my data, right? But actually, yeah, yeah, yeah, 994 00:52:09,120 --> 00:52:10,600 yes. Yes, yeah. 995 00:52:10,600 --> 00:52:13,680 So the data becomes a secondary interface which is now needs to 996 00:52:13,680 --> 00:52:15,520 be managed. I mean, I don't see how 997 00:52:15,520 --> 00:52:17,480 monoliths are immune to that problem either, right? 998 00:52:18,760 --> 00:52:23,320 OK, so that kind of leads me on to the way that we use this idea 999 00:52:23,320 --> 00:52:25,320 to represent data. So I don't know if you were 1000 00:52:25,320 --> 00:52:28,000 aware of another argument going on in parallel between people 1001 00:52:28,000 --> 00:52:32,080 who dislike ORMS and people who speak ORMS. 1002 00:52:32,080 --> 00:52:34,200 You should have ORMS, and I've used both. 1003 00:52:34,200 --> 00:52:38,680 Obviously my original C code was directly talking to my SQL and 1004 00:52:39,120 --> 00:52:42,640 I've used Hibernate, sharded Hibernate for Java, which is 1005 00:52:42,640 --> 00:52:46,520 wow, wow, how are we going? OK, so here's the thing. 1006 00:52:46,520 --> 00:52:50,640 I think one of the big learnings from the no SQL movement was 1007 00:52:50,640 --> 00:52:56,880 that joins are overused. And almost always 90% of cases 1008 00:52:56,880 --> 00:52:58,640 you really don't need to join tables. 1009 00:52:59,000 --> 00:53:02,120 Now that does introduce certain inefficiencies for sure. 1010 00:53:02,120 --> 00:53:04,960 But the nice thing about that is it keeps your business logic 1011 00:53:04,960 --> 00:53:08,640 relatively simple because you have very strong ideas of 1012 00:53:09,040 --> 00:53:12,520 specific entities, like there's a user and there's a shopping 1013 00:53:12,520 --> 00:53:17,240 cart and there's a line item. And if you denormalize, again, 1014 00:53:17,240 --> 00:53:20,240 you have to add in maybe batch processes to correct things and 1015 00:53:20,240 --> 00:53:21,840 reservations to keep everything consistent. 1016 00:53:21,840 --> 00:53:28,120 But mostly if you denormalize and you don't use joins, mostly 1017 00:53:28,120 --> 00:53:32,400 you're OK for most enterprise. And certainly if you're doing a 1018 00:53:32,400 --> 00:53:34,840 consumer application for scale, you're going to need to 1019 00:53:34,840 --> 00:53:38,480 denormalize anyway, leave the joins to the reporting engines 1020 00:53:38,520 --> 00:53:41,320 and things like that, right? So I mean we preferentially use 1021 00:53:41,320 --> 00:53:42,920 things like Dynamo DB these days. 1022 00:53:43,600 --> 00:53:45,280 You can't really to join some of that, right? 1023 00:53:46,240 --> 00:53:48,800 Yeah. So one of the underlying things 1024 00:53:48,800 --> 00:53:52,640 I find that where people are not enthusiastic about microservices 1025 00:53:52,640 --> 00:53:55,880 is because they also tend to have to give up the idea that 1026 00:53:55,880 --> 00:53:59,120 you can join tables and write custom SQL inside your 1027 00:53:59,120 --> 00:54:02,000 application. Microservice component based 1028 00:54:02,000 --> 00:54:04,400 approaches tend to push you in that direction. 1029 00:54:04,880 --> 00:54:07,920 That's a big thing to give up. But I think it also goes back to 1030 00:54:07,920 --> 00:54:13,800 the idea of being inspired by Unix pipes, because simpler that 1031 00:54:13,800 --> 00:54:16,560 you can make the shared interfaces, the less trouble 1032 00:54:16,560 --> 00:54:18,480 they give you. So even if you have shared 1033 00:54:18,480 --> 00:54:23,440 tables, shared schemas, if people aren't doing joins mostly 1034 00:54:23,440 --> 00:54:27,040 OK. And then if you only expose the 1035 00:54:27,760 --> 00:54:32,000 data via messages anyway, if the schema drift or something like 1036 00:54:32,000 --> 00:54:34,880 that, then you can add interception messages that will 1037 00:54:35,120 --> 00:54:38,040 temporarily adjust until you can figured things out, right. 1038 00:54:38,040 --> 00:54:41,760 So in the book, I give some examples of migration strategies 1039 00:54:41,760 --> 00:54:44,400 where you deploy multiple services or translator services 1040 00:54:44,400 --> 00:54:45,960 to handle those types of scenarios. 1041 00:54:46,800 --> 00:54:49,240 You know, they pay us good money because this stuff ain't easy. 1042 00:54:51,720 --> 00:54:53,640 So I don't think there's any easy answers to that. 1043 00:54:53,640 --> 00:54:56,880 I, I just think it's not as it's all about trade-offs, right. 1044 00:54:56,880 --> 00:55:00,560 So my personal trade off is I don't really use joins apart 1045 00:55:00,560 --> 00:55:01,920 from reporting. I'm still here. 1046 00:55:02,720 --> 00:55:06,080 I live, I'm alive. I think the point where you make 1047 00:55:06,080 --> 00:55:08,080 you use less joints. So I think in your book you 1048 00:55:08,080 --> 00:55:09,720 mentioned about data duplication, right? 1049 00:55:09,720 --> 00:55:13,480 So maybe think of like instead of normalizing and doing joints, 1050 00:55:13,480 --> 00:55:14,960 right, you can also duplicate data. 1051 00:55:14,960 --> 00:55:18,040 Yes, it may still a little bit, but also like thinking in terms 1052 00:55:18,040 --> 00:55:20,600 of eventual consistency, you won't get like a strong 1053 00:55:20,920 --> 00:55:24,040 consistency anyway, right? So I think that's really, really 1054 00:55:24,160 --> 00:55:27,880 interesting view as well. So I think we can't cover any. 1055 00:55:28,040 --> 00:55:29,360 Everything interesting in your book? 1056 00:55:29,880 --> 00:55:33,120 You can tell I could keep going another three hours. 1057 00:55:34,640 --> 00:55:37,880 So definitely for people who are interested in this new way of 1058 00:55:37,880 --> 00:55:40,720 thinking, you know, the tower of micro services, I do recommend 1059 00:55:40,720 --> 00:55:43,640 checking out Richard's book. I think it really provides you 1060 00:55:43,640 --> 00:55:46,880 with a unique different views of how to tackle micro service 1061 00:55:46,880 --> 00:55:49,480 problem. So Richard, as part of my last 1062 00:55:49,480 --> 00:55:52,640 question, I would love to ask you this question I called the 1063 00:55:52,680 --> 00:55:54,080 three technical leadership wisdom. 1064 00:55:54,440 --> 00:55:56,920 So if you can think of it just like an advice that you want to 1065 00:55:56,920 --> 00:55:59,600 leave to ask the listeners here to learn from you, what would 1066 00:55:59,600 --> 00:56:03,080 that be? You have to let the developers 1067 00:56:03,080 --> 00:56:06,560 that work for you make their own mistakes and you have to create 1068 00:56:06,560 --> 00:56:10,200 a culture of making mistakes blame free. 1069 00:56:10,840 --> 00:56:15,520 So that means sometimes as a senior or the architect allowing 1070 00:56:15,520 --> 00:56:20,680 code in the system that is maybe not the quality that you would 1071 00:56:20,680 --> 00:56:23,320 write yourself. And I think a great deal of 1072 00:56:23,520 --> 00:56:28,280 stress, especially for new team leaders and new architects, 1073 00:56:28,280 --> 00:56:32,760 comes from this tension where it's literally impossible to get 1074 00:56:32,760 --> 00:56:36,000 everybody to write code to the I mean, maybe you think you're 1075 00:56:36,000 --> 00:56:38,320 good, I don't know, right? But it's whatever your 1076 00:56:38,320 --> 00:56:40,680 perception is. You're never going to get other 1077 00:56:40,680 --> 00:56:42,600 developers to write code the way you want. 1078 00:56:42,600 --> 00:56:45,080 And I mean, that's why components are so important, 1079 00:56:45,080 --> 00:56:47,800 because if if something is written one way inside a 1080 00:56:47,800 --> 00:56:51,120 component is less, the blast radius is smaller. 1081 00:56:51,920 --> 00:56:54,600 People talk a lot about empathy and they use the word empathy a 1082 00:56:54,600 --> 00:56:58,480 lot, But I think in technical leadership, a lot of that 1083 00:56:58,640 --> 00:57:04,200 empathy is showing leadership by accepting a diversity of 1084 00:57:04,200 --> 00:57:09,920 technical perspectives and allowing people to maybe make a 1085 00:57:09,920 --> 00:57:12,640 mess. I'd much rather if the developer 1086 00:57:12,640 --> 00:57:16,160 came to me and you hear stories of people who've like destroyed, 1087 00:57:16,160 --> 00:57:19,760 deleted the production database, you've told like, I would hire 1088 00:57:19,760 --> 00:57:22,880 that person without thinking. I wouldn't even look, I wouldn't 1089 00:57:22,880 --> 00:57:25,360 even think about it. You know, I don't even want to 1090 00:57:25,360 --> 00:57:27,440 see your code, right? You deleted production database. 1091 00:57:27,640 --> 00:57:32,800 I'm going to give you a job. That experience is something 1092 00:57:32,800 --> 00:57:35,520 that you can't Rep. I mean, I've deleted live 1093 00:57:35,520 --> 00:57:39,200 websites. You can't replicate that level 1094 00:57:39,200 --> 00:57:41,280 of experience. But for an organization to 1095 00:57:41,280 --> 00:57:43,760 appreciate it, you've got to have empathy, right, Instead of 1096 00:57:43,760 --> 00:57:45,240 looking for that kind of blame culture. 1097 00:57:45,560 --> 00:57:49,280 So yeah, go easy on the PRS. That would sum it up. 1098 00:57:49,560 --> 00:57:52,520 Doesn't really matter. Anything else or that's all. 1099 00:57:52,520 --> 00:57:54,760 I think we can also wrap up with that. 1100 00:57:55,560 --> 00:57:57,640 I think that's the most important thing, right? 1101 00:57:58,160 --> 00:58:00,200 So thank you so much for the wisdom. 1102 00:58:00,200 --> 00:58:02,280 I think it's really powerful and beautiful, right? 1103 00:58:02,280 --> 00:58:05,760 I like the empathy side. Obviously, as many architect or 1104 00:58:05,760 --> 00:58:08,800 tech lead, sometimes we are very strongly opinionated about 1105 00:58:08,800 --> 00:58:11,080 certain stuff, be it architecture, design or even 1106 00:58:11,080 --> 00:58:14,080 coding style, right? So sometimes it all doesn't 1107 00:58:14,080 --> 00:58:16,960 really matter as long as you know the right outcome that you 1108 00:58:16,960 --> 00:58:19,520 want to achieve. So Richard, if people want to 1109 00:58:19,520 --> 00:58:22,240 follow you or they want to chat with you about all these 1110 00:58:22,240 --> 00:58:25,320 different perspectives about microservices, is there a place 1111 00:58:25,320 --> 00:58:31,320 where they can find you online? I am RJRODGER, still on X 1112 00:58:31,320 --> 00:58:33,840 Twitter. I'm started using Mastodon, 1113 00:58:33,840 --> 00:58:35,320 things like that. Same username. 1114 00:58:35,440 --> 00:58:37,880 But yeah, Twitter's still where it's at by the looks of it, for 1115 00:58:37,880 --> 00:58:41,960 the moment for tech. And yeah, the microservice is 1116 00:58:41,960 --> 00:58:44,120 British places like that. Right. 1117 00:58:44,480 --> 00:58:46,120 Henry, thank you so much. It's been super fun. 1118 00:58:46,920 --> 00:58:48,760 Yep, thank you so much for this time as well. 1119 00:58:48,760 --> 00:58:52,280 So I hope people enjoy our discussion about Microsoft today 1120 00:58:52,280 --> 00:58:53,200 all. Righty. 1121 00:58:53,200 --> 00:58:53,920 Thank you. Take care. 1122 00:58:53,920 --> 00:58:54,360 Bye bye.