1 00:00:00,000 --> 00:00:02,600 Today's episode of the technology on our podcast is 2 00:00:02,600 --> 00:00:06,600 proudly sponsored by emergence. The Journal of business agility. 3 00:00:07,200 --> 00:00:10,200 This quarterly publication brings you inspiring stories 4 00:00:10,200 --> 00:00:12,800 from the most Innovative companies and explores the 5 00:00:12,800 --> 00:00:15,900 themes of the new ways of working reclaiming management 6 00:00:15,900 --> 00:00:19,100 and humanizing business. It brings together a curated 7 00:00:19,100 --> 00:00:22,200 selection of exclusive stories by great, thinkers and 8 00:00:22,200 --> 00:00:25,200 practitioners from around the globe that can broaden your 9 00:00:25,200 --> 00:00:27,400 horizons and Spark. Your creativity. 10 00:00:28,000 --> 00:00:32,600 Each issue is hen Illustrated. And contains 100% pure content, 11 00:00:33,000 --> 00:00:38,000 use the promo code tekhelet eech, Ali-A D to get a 10% 12 00:00:38,000 --> 00:00:40,200 discount on your annual subscription. 13 00:00:40,600 --> 00:00:43,800 Visit business agility, dot institute's less emergence to 14 00:00:43,800 --> 00:00:46,900 get your addition and support the publication supporting your 15 00:00:46,900 --> 00:00:49,300 podcast. Here's the link One More Time. 16 00:00:49,400 --> 00:00:52,400 Business agility, dot Institute, / emergence. 17 00:00:52,800 --> 00:00:55,300 So throughout this. I've been talking about rapid 18 00:00:55,300 --> 00:00:57,500 frequent Reliable Software delivery. 19 00:00:57,700 --> 00:01:01,000 What is that? So there's actually The four 20 00:01:01,000 --> 00:01:06,400 metrics which come from devops. The research has shown to be a 21 00:01:06,400 --> 00:01:09,300 good indicator of high performance. 22 00:01:09,300 --> 00:01:12,800 So the whole point of microservices adopting 23 00:01:12,800 --> 00:01:16,200 microservices is not to have microservices. 24 00:01:16,500 --> 00:01:20,600 The goal is to improve those metrics and that's what people 25 00:01:20,600 --> 00:01:25,400 should be incented to improve because sometimes changing your 26 00:01:25,400 --> 00:01:28,600 development process around, your monolith will improve those 27 00:01:28,600 --> 00:01:31,400 metrics. But there In other situations 28 00:01:31,400 --> 00:01:35,100 where you really have outgrown your architecture, your 29 00:01:35,100 --> 00:01:39,200 monolithic architecture. Then adopting microservices is 30 00:01:39,200 --> 00:01:41,600 the only way to improve those metrics. 31 00:01:46,700 --> 00:01:49,600 Hey everyone. My name is Henry Surya, we 32 00:01:49,600 --> 00:01:53,000 Robin. And you're listening to the 33 00:01:53,000 --> 00:01:55,900 tekhelet journal. The show will be bringing you 34 00:01:55,900 --> 00:01:59,400 the greatest technical leaders practitioners and thought 35 00:01:59,400 --> 00:02:02,800 leaders in the industry to discuss about their Journey 36 00:02:03,100 --> 00:02:07,400 ideas and practices that we all can learn and apply to build a 37 00:02:07,400 --> 00:02:11,000 highly performing technical team and to make an impact in your 38 00:02:11,000 --> 00:02:14,700 personal work. So let's dive into our Journal. 39 00:02:19,900 --> 00:02:23,500 Hello again, to all my - it's great to be back here again with 40 00:02:23,500 --> 00:02:26,100 another episode of the tekhelet journal podcast. 41 00:02:26,400 --> 00:02:29,100 Thank you for spending your time with me today, listening to this 42 00:02:29,100 --> 00:02:31,700 episode. If you haven't, please follow 43 00:02:31,700 --> 00:02:34,500 technology, you know on your favorite podcast app and our 44 00:02:34,500 --> 00:02:37,800 social media channels on LinkedIn, Twitter and Instagram, 45 00:02:38,300 --> 00:02:40,600 you can also make some contribution and support this 46 00:02:40,600 --> 00:02:43,800 podcast by subscribing as a patron at technology. 47 00:02:43,800 --> 00:02:47,800 No, dot f / Patron, and help me to continue producing. 48 00:02:47,800 --> 00:02:51,200 Great content every week. For today's episode. 49 00:02:51,300 --> 00:02:54,700 I'm extremely happy to share my conversation with Chris 50 00:02:54,800 --> 00:02:57,400 Richardson. Chris is, a renowned thought 51 00:02:57,400 --> 00:03:00,300 leader in micro services and the author of the book, 52 00:03:00,300 --> 00:03:04,200 microservices patterns and the popular microservices dot IO 53 00:03:04,200 --> 00:03:07,300 website. He also regularly speaks at 54 00:03:07,300 --> 00:03:10,900 International conferences, and delivers Consulting and training 55 00:03:10,900 --> 00:03:14,600 that helps organizations to successfully adopt and use micro 56 00:03:14,600 --> 00:03:18,100 service architecture. Microservice architecture has 57 00:03:18,100 --> 00:03:22,100 been around for a decade now. And it has been widely coveted 58 00:03:22,100 --> 00:03:25,400 as the modern architecture to solve any kind of distributed, 59 00:03:25,400 --> 00:03:29,700 scalable system and much debate has also been discussed on how 60 00:03:29,700 --> 00:03:32,400 to adopt and Implement microservices properly, 61 00:03:32,700 --> 00:03:36,100 including how to migrate from a monolith architecture to 62 00:03:36,100 --> 00:03:38,600 microservices in this episode Kris. 63 00:03:38,600 --> 00:03:42,100 And I opened our conversation. Talking about the current state 64 00:03:42,100 --> 00:03:44,900 of micro Services versus monolith architecture. 65 00:03:45,500 --> 00:03:49,200 And Chris explained why he thinks monolith is not actually 66 00:03:49,200 --> 00:03:50,300 an end. A pattern. 67 00:03:50,500 --> 00:03:53,000 And when is a good time for us to consider adopting 68 00:03:53,000 --> 00:03:56,000 microservice architecture? He then shared about the 69 00:03:56,000 --> 00:03:57,700 success. Triangle for implementing 70 00:03:57,700 --> 00:04:02,300 microservices important Concepts such as design time coupling and 71 00:04:02,300 --> 00:04:05,200 some important microservices patterns such as eventual, 72 00:04:05,200 --> 00:04:09,100 consistency The Saga pattern and how his current work on 73 00:04:09,100 --> 00:04:13,300 eventuate can help developers to implement these patterns easier 74 00:04:13,900 --> 00:04:17,100 towards the end. Chris briefly explained some of 75 00:04:17,100 --> 00:04:19,700 his important principles that we should consider. 76 00:04:19,700 --> 00:04:22,600 Party composing. A monolith successfully. 77 00:04:22,600 --> 00:04:27,000 I highly enjoyed my conversation with Chris learning about micro 78 00:04:27,000 --> 00:04:30,600 services and how to adopt and implement it correctly, and I 79 00:04:30,600 --> 00:04:32,600 believe that you will enjoy this episode as well. 80 00:04:32,600 --> 00:04:37,200 Consider helping the show, by living the rating, a review on 81 00:04:37,200 --> 00:04:40,100 your podcast app and you can also leave some comments on our 82 00:04:40,100 --> 00:04:43,600 social media channels, though. It may seem trivial, but those 83 00:04:43,600 --> 00:04:46,400 reviews and comments are one of the best ways to help me get 84 00:04:46,400 --> 00:04:50,500 this podcast to reach more listeners and Lee, they can also 85 00:04:50,500 --> 00:04:54,600 benefit from all the contents in this podcast, without further 86 00:04:54,600 --> 00:04:56,200 Ado. So let's get this episode 87 00:04:56,200 --> 00:04:59,800 started. Hi, everyone. 88 00:05:00,100 --> 00:05:02,300 Welcome back to another new episode of the technique 89 00:05:02,300 --> 00:05:03,400 Journal. Today. 90 00:05:03,400 --> 00:05:05,400 I will be someone that I really admire. 91 00:05:05,600 --> 00:05:08,600 He is one of the thought leaders of microservices. 92 00:05:08,900 --> 00:05:11,200 He's actually the original founder of cloud. 93 00:05:11,200 --> 00:05:15,600 Foundry.com is also a recognized thought leaders and speakers in 94 00:05:15,600 --> 00:05:19,400 many different conferences. He is the author of the website 95 00:05:19,400 --> 00:05:21,100 called. Cross services, the I/O. 96 00:05:21,200 --> 00:05:24,400 So if you are into micro services and have research 97 00:05:24,400 --> 00:05:27,500 microservices before, maybe you have bumped into one of his 98 00:05:27,500 --> 00:05:30,200 articles or blog or patterns from that website. 99 00:05:30,500 --> 00:05:33,900 He's also the author of the book microservices patterns and is 100 00:05:33,900 --> 00:05:37,000 currently working on his startup called eventuate. 101 00:05:37,100 --> 00:05:40,400 So maybe we'll also ask a little bit more about what eventuate 102 00:05:40,500 --> 00:05:42,700 is. His name is Chris Richardson. 103 00:05:43,000 --> 00:05:44,800 I'm really looking forward for this conversation. 104 00:05:44,800 --> 00:05:46,700 In fact to learn more about microservices. 105 00:05:46,800 --> 00:05:49,100 So welcome Chris to the show. Great. 106 00:05:49,100 --> 00:05:50,900 Thanks. I'm excited to be here. 107 00:05:50,900 --> 00:05:54,300 Thank you for inviting me. So Chris maybe for people who 108 00:05:54,300 --> 00:05:56,700 are not familiar with you yet. Could you maybe introduce 109 00:05:56,700 --> 00:05:59,100 yourself telling us more about your career Journey? 110 00:05:59,100 --> 00:06:00,600 Any highlights or turning points? 111 00:06:01,300 --> 00:06:03,500 Yeah. Maybe I'll just start with the 112 00:06:03,500 --> 00:06:06,700 end. So for the past gosh as study 113 00:06:06,700 --> 00:06:08,900 would be forever. Now, I guess for the past seven 114 00:06:08,900 --> 00:06:11,800 plus years actually, even maybe even eight years. 115 00:06:11,800 --> 00:06:14,700 I've been somewhat focused on the mic for service 116 00:06:14,700 --> 00:06:17,800 architecture. I used to say, I like to travel 117 00:06:17,800 --> 00:06:20,900 all around the world helping They shouldn't sits up, 118 00:06:20,900 --> 00:06:24,000 microservices to mixture of Consulting. 119 00:06:24,000 --> 00:06:27,800 And training though, with covid. I just do Zoom from my home 120 00:06:27,800 --> 00:06:30,200 office. Fortunately business is 121 00:06:30,200 --> 00:06:33,800 transitioned online, but I really am looking forward to 122 00:06:33,800 --> 00:06:35,900 working with clients face-to-face. 123 00:06:35,900 --> 00:06:38,100 So that's what I do. These days. 124 00:06:38,600 --> 00:06:41,500 How did I end up here? It was a long journey, right? 125 00:06:41,500 --> 00:06:45,200 We might first paid job actually was the summer before College 126 00:06:45,200 --> 00:06:49,400 back in 1982 as funny. When I was a teenager. 127 00:06:49,700 --> 00:06:53,000 I was actually interested in programming languages and 128 00:06:53,000 --> 00:06:58,100 compilers and so that's my focus area and after college, I got a 129 00:06:58,100 --> 00:07:01,100 job with a company, building lisp systems. 130 00:07:01,200 --> 00:07:04,100 So if anyone can remember list that language with all of the 131 00:07:04,100 --> 00:07:10,100 parentheses, which at the time was used, very extensively for 132 00:07:10,100 --> 00:07:12,500 AI. People were building quite 133 00:07:12,500 --> 00:07:16,600 complex system where on the one client along customer. 134 00:07:16,700 --> 00:07:19,600 They're actually using a list based system. 135 00:07:19,800 --> 00:07:23,000 To schedule time on the Hubble Space Telescope. 136 00:07:23,500 --> 00:07:27,100 And then another client was actually using lists to do, 137 00:07:27,100 --> 00:07:29,300 payload planning for the space shuttle. 138 00:07:29,300 --> 00:07:32,800 So they actually use for some super interesting applications 139 00:07:32,800 --> 00:07:34,700 there. I'm so I spent seven years 140 00:07:34,700 --> 00:07:37,300 implementing lisp systems, building everything from like 141 00:07:37,300 --> 00:07:41,600 compilers garbage collectors all the way up the stack to Rich 142 00:07:41,600 --> 00:07:45,300 sophisticated ID. He's this was actually all on 143 00:07:45,300 --> 00:07:48,100 machines that had eight megabytes of memory. 144 00:07:48,300 --> 00:07:52,100 I feel like you could run it on. On your smartphone today, right? 145 00:07:54,300 --> 00:07:56,400 Yeah. So anyway, that's sort of gave 146 00:07:56,400 --> 00:07:59,500 me an appreciation for sophisticated. 147 00:07:59,500 --> 00:08:03,100 Modern languages could certainly at the time late 80s, early 90s 148 00:08:03,200 --> 00:08:05,800 mainstream was C. Programming here. 149 00:08:05,800 --> 00:08:11,400 I was building software in this sophisticated object-oriented 150 00:08:11,400 --> 00:08:14,800 functional language with garbage collection. 151 00:08:14,900 --> 00:08:16,900 Then of course Java came along. Right? 152 00:08:16,900 --> 00:08:19,600 There was a 1996 and initially I looked at it. 153 00:08:19,700 --> 00:08:24,100 I thought what A Primitive language but ended up embracing 154 00:08:24,100 --> 00:08:27,100 it and so I've been in the Java Community ever since. 155 00:08:27,100 --> 00:08:31,200 Basically, I was in the Consulting Group helping clients 156 00:08:31,200 --> 00:08:35,200 build applications on top of weblogic platform and then 157 00:08:35,200 --> 00:08:38,799 discovered the spring framework. I went to the service side 158 00:08:38,799 --> 00:08:41,900 conference that he was less Vegas. 2004 discovered the 159 00:08:41,900 --> 00:08:46,100 spring framework and hibernate and those Technologies and just 160 00:08:46,100 --> 00:08:49,600 immediately switch to that. Literally came. 161 00:08:49,700 --> 00:08:52,600 I'm back to work the following Monday and just said okay. 162 00:08:52,600 --> 00:08:54,800 We're going to switch to Spring and hibernate. 163 00:08:54,800 --> 00:08:57,600 I was this architect on his mobile device management 164 00:08:57,600 --> 00:09:00,700 platform who were just like, okay, we're going to migrate 165 00:09:00,700 --> 00:09:04,800 away from EJ bees and that technology to this more modern 166 00:09:04,800 --> 00:09:09,900 technology, which remarkably 17 years later is still dominant in 167 00:09:09,900 --> 00:09:12,200 the Java space. And that actually would led me 168 00:09:12,208 --> 00:09:15,900 to write my first book, which was pojos an action that was all 169 00:09:15,900 --> 00:09:19,400 about building applications with spring and hibernate sort of 170 00:09:19,700 --> 00:09:25,000 Formative Enterprise, Java Technologies, and I was 2006. 171 00:09:25,500 --> 00:09:28,700 And I did ended up doing consulting and training around 172 00:09:28,700 --> 00:09:32,900 that for a while. And then I discovered the cloud 173 00:09:32,900 --> 00:09:38,200 actually was 2006, an evangelist from Amazon, gave a talk at the 174 00:09:38,200 --> 00:09:40,400 local. Jug we'd boy was going to give a 175 00:09:40,408 --> 00:09:42,900 talk about apis for buying books. 176 00:09:43,300 --> 00:09:47,700 Instead. He talks about S 3 SQ S and E C 177 00:09:47,700 --> 00:09:52,200 2, which just blows my My mind, it's like, wait, with an API 178 00:09:52,200 --> 00:09:54,800 call. You can provision 20 servers and 179 00:09:54,800 --> 00:09:58,600 pay ten cents an hour. So I just got super excited 180 00:09:58,600 --> 00:10:00,600 about that. And ended up getting my guess. 181 00:10:00,600 --> 00:10:06,200 It was beta access, maybe even a few months later, 2007 and that 182 00:10:06,200 --> 00:10:09,200 led me on the path to creating Cloud. 183 00:10:09,200 --> 00:10:13,500 The original cloud Foundry. That was a Java pass few clicks 184 00:10:13,500 --> 00:10:15,700 of the mouse. You could upload your War file 185 00:10:15,700 --> 00:10:19,500 and it provision the bunch of ec2 instances running Tomcat. 186 00:10:19,700 --> 00:10:22,400 Hachi. My Sequel and monitored manage 187 00:10:22,400 --> 00:10:25,300 order of scale. Remember, none of that existed 188 00:10:25,300 --> 00:10:29,100 in the AWS functionality at the time and this fact, she was 189 00:10:29,100 --> 00:10:33,700 helped by the financial crash, in 2008, which made my 190 00:10:33,700 --> 00:10:37,000 Consulting business evaporate and it was like, well, I got 191 00:10:37,000 --> 00:10:41,200 this time on my hands instead of a zero Revenue consulting 192 00:10:41,200 --> 00:10:43,700 company. It can be a zero Revenue early 193 00:10:43,700 --> 00:10:48,000 stage startup much better sounding and that led to the 194 00:10:48,000 --> 00:10:51,200 creation of the original cloud. Foundry, which was then acquired 195 00:10:51,200 --> 00:10:55,100 by Spring Source, I reconnected with the spring folks, which was 196 00:10:55,100 --> 00:10:57,100 pretty awesome. And then we got acquired by 197 00:10:57,100 --> 00:11:00,400 VMware and then spun out into pivotal. 198 00:11:00,800 --> 00:11:04,500 And I should say for clarity. Today's Cloud Foundry was 199 00:11:04,500 --> 00:11:08,000 developed by an entirely separate group, but they took 200 00:11:08,000 --> 00:11:10,500 the name from the cloud Foundry that I develop. 201 00:11:10,500 --> 00:11:13,800 So I have no claims on the technology, but it's nice. 202 00:11:13,800 --> 00:11:17,500 That least the name lives are during my time at VMware. 203 00:11:17,800 --> 00:11:19,500 I had got interested in this concept. 204 00:11:19,700 --> 00:11:23,500 Set to basically functional decomposition into a set of 205 00:11:23,500 --> 00:11:27,400 services and now holds the their architectural style, which 206 00:11:27,400 --> 00:11:30,600 actually is very old. One ultimately got the label of 207 00:11:30,600 --> 00:11:34,300 microservices. I got interested in that sort of 208 00:11:34,300 --> 00:11:39,100 20 2010 and then just got more and more interested in it and 209 00:11:39,100 --> 00:11:43,400 started talking about it and 2012 and it generated a lot of 210 00:11:43,400 --> 00:11:45,000 interest. Got here. 211 00:11:45,000 --> 00:11:49,300 I am 20 21 still talking about the same old stuff. 212 00:11:49,900 --> 00:11:52,200 Perfect. Wow, thanks for sharing your 213 00:11:52,200 --> 00:11:55,200 story, the history where you got to where you are at this point 214 00:11:55,200 --> 00:11:56,700 in time. So thanks for sharing that. 215 00:11:56,800 --> 00:11:59,400 So obviously you have been doing this for quite some time. 216 00:11:59,500 --> 00:12:02,100 You mentioned and D12, maybe he was your first talk about 217 00:12:02,100 --> 00:12:04,300 microservice now is almost 10 years. 218 00:12:04,700 --> 00:12:07,400 So what do you think is the current state of all these micro 219 00:12:07,400 --> 00:12:09,400 service which is monolith debate? 220 00:12:09,600 --> 00:12:11,700 Or what kind of, you know, the cool things about? 221 00:12:11,700 --> 00:12:13,800 Microservices this day if it's still cool. 222 00:12:14,600 --> 00:12:17,100 Yeah. Well, I think we almost every 223 00:12:17,100 --> 00:12:19,500 technology goes through the Gartner hype cycle. 224 00:12:20,000 --> 00:12:24,000 Well, first, it's amazing and it can do no wrong. 225 00:12:24,000 --> 00:12:27,900 Everybody should be using it. And then people realize that no 226 00:12:27,900 --> 00:12:29,800 technology is perfect. Right? 227 00:12:29,800 --> 00:12:33,400 Nothing is the silver bullet. And then there's the backlash 228 00:12:33,400 --> 00:12:36,200 and it's like that technology sucks. 229 00:12:36,500 --> 00:12:40,600 And then ultimately people figure out the trade-offs with 230 00:12:40,600 --> 00:12:45,000 in and the areas when it's best to use microservices or a 231 00:12:45,008 --> 00:12:48,700 technology in general. I think very much microservices 232 00:12:48,700 --> 00:12:52,300 is going through Ooh that hype cycle right now and there's sort 233 00:12:52,300 --> 00:12:54,900 of numerous anti patterns of adoption. 234 00:12:54,900 --> 00:12:57,000 People are using it when they shouldn't. 235 00:12:57,000 --> 00:13:01,400 It's like I'm going to upgrade to a modern technology stack and 236 00:13:01,400 --> 00:13:05,000 automatically assume that includes using microservices. 237 00:13:05,200 --> 00:13:09,200 Usually there's a whole bunch of criteria for when you should use 238 00:13:09,200 --> 00:13:14,100 any particular technology versus another and that's exactly true 239 00:13:14,100 --> 00:13:18,000 with microservices as well. The monolithic architectures 240 00:13:18,000 --> 00:13:22,500 rate for many Scenarios. And then the microservice 241 00:13:22,500 --> 00:13:26,500 architecture is great for other scenarios, like with everything. 242 00:13:26,500 --> 00:13:29,100 It's a giant, it depends you could. 243 00:13:29,100 --> 00:13:32,300 Certainly say, if you have a large project with the large 244 00:13:32,300 --> 00:13:35,700 number of teams, given that one of the primary goals of 245 00:13:35,700 --> 00:13:39,800 microservices, is a rapid reliable frequent delivery of 246 00:13:39,800 --> 00:13:42,200 software. And the idea is so it in order 247 00:13:42,200 --> 00:13:45,800 for an organization to compete successfully in the modern 248 00:13:45,800 --> 00:13:49,400 world, where new competitors can emerge out of nowhere. 249 00:13:49,600 --> 00:13:52,200 I actually think it was Hong Kong government, decides to 250 00:13:52,200 --> 00:13:56,000 license 6, digital Banks. Suddenly, the brick-and-mortar 251 00:13:56,000 --> 00:14:00,100 banks have six new editors. Presumably, they need to be able 252 00:14:00,100 --> 00:14:03,200 to react quickly to that. And then, of course, covid you 253 00:14:03,200 --> 00:14:05,700 could say that's like the ultimate disruptor. 254 00:14:05,700 --> 00:14:09,400 Certainly in the u.s. Online grocery delivery jump 255 00:14:09,400 --> 00:14:13,000 forward five years actually within about three weeks. 256 00:14:13,000 --> 00:14:16,300 I think it blocks. The world is very Dynamic and 257 00:14:16,300 --> 00:14:18,900 unpredictable, and businesses need to be nimble. 258 00:14:19,800 --> 00:14:24,000 Which means that it needs to be nimble, which then translates 259 00:14:24,000 --> 00:14:28,100 into certain architectural requirements, testability 260 00:14:28,100 --> 00:14:32,800 deployability, modularity is important, so that you can 261 00:14:32,800 --> 00:14:36,100 rapidly deliver changes to your software. 262 00:14:36,500 --> 00:14:39,700 And sometimes some situations, you can have a modular and 263 00:14:39,708 --> 00:14:42,800 monolithic architecture with those characteristics. 264 00:14:43,200 --> 00:14:47,200 But once you get to a certain size, certain level of 265 00:14:47,200 --> 00:14:51,300 complexity, quite often the Microservice architecture is 266 00:14:51,300 --> 00:14:55,200 about of fit. It will very much depends, but 267 00:14:55,200 --> 00:14:58,100 you could save that. Yeah, if you look at the world's 268 00:14:58,100 --> 00:15:02,300 leading technology companies, I would think the majority of them 269 00:15:02,300 --> 00:15:06,900 are using microservices Amazon basically adopted I'm going to 270 00:15:06,900 --> 00:15:10,700 say a distributed architecture back in 2002. 271 00:15:11,000 --> 00:15:13,600 Google have a distributed architecture. 272 00:15:13,700 --> 00:15:16,800 Well, those are companies are operating at massive scale with 273 00:15:16,800 --> 00:15:21,500 a gazillion users, but certainly Many cases, they didn't adopt 274 00:15:21,500 --> 00:15:24,800 Services because of scaling. A say, certainly. 275 00:15:24,800 --> 00:15:27,800 This is the case with Amazon, the adopted them because they 276 00:15:27,800 --> 00:15:31,800 were operating in a highly competitive environment and they 277 00:15:31,800 --> 00:15:35,800 needed to move quickly because you can scale a monolith more or 278 00:15:35,800 --> 00:15:38,800 less to have, you know, support a large number of users. 279 00:15:39,200 --> 00:15:42,500 The microservices is all about tackling complexity. 280 00:15:43,200 --> 00:15:46,500 I saw one of your articles about monolith, which I think is 281 00:15:46,500 --> 00:15:49,400 pretty interesting too, maybe educate or clarified. 282 00:15:49,500 --> 00:15:52,100 A lot of people. So in that article you basically 283 00:15:52,100 --> 00:15:54,400 title it. The monolithic architecture is 284 00:15:54,400 --> 00:15:57,100 not an anti-pattern. So while so many people these 285 00:15:57,100 --> 00:16:00,300 days think okay monolith is a bad architecture. 286 00:16:00,300 --> 00:16:02,900 We should move away from it. Should adopt microservices. 287 00:16:03,200 --> 00:16:04,900 Why would this article saying that? 288 00:16:04,900 --> 00:16:07,900 It's not an anti-pattern. Maybe you can Enlighten us on 289 00:16:07,900 --> 00:16:10,700 this front. Well, I mean if you think about 290 00:16:10,800 --> 00:16:15,300 what a model is this at such traditional architecture where 291 00:16:15,300 --> 00:16:18,900 everything gets packaged to say in the Java world is a single 292 00:16:18,900 --> 00:16:21,600 War file. So your architect it from a 293 00:16:21,600 --> 00:16:26,300 logical perspective, you've got modules packages and they're 294 00:16:26,300 --> 00:16:30,600 collaborating to handle requests and you've got a single database 295 00:16:31,000 --> 00:16:31,900 by me. It could be a bit more 296 00:16:31,900 --> 00:16:34,800 complicated than that, but it's best think of it as a single 297 00:16:34,800 --> 00:16:37,200 database. That's really simple. 298 00:16:37,600 --> 00:16:41,400 All communication with in between the modules of your 299 00:16:41,400 --> 00:16:44,900 application of Simply method, or function calls. 300 00:16:45,200 --> 00:16:49,100 All of your data is in a single database, which means that you 301 00:16:49,100 --> 00:16:53,000 can Just use regular acid transactions, and is just the 302 00:16:53,000 --> 00:16:56,500 application. So it's just simple and 303 00:16:56,500 --> 00:16:59,600 familiar. Whereas, mediately switch to the 304 00:16:59,600 --> 00:17:03,400 microservice architecture. You're building a distributed 305 00:17:03,400 --> 00:17:06,200 system. So communication between the 306 00:17:06,200 --> 00:17:08,900 different parts of your application. 307 00:17:09,300 --> 00:17:13,599 And now some kind of inter process communication, whether 308 00:17:13,599 --> 00:17:17,599 it's rest or gr, PC, or messaging, and so on, which is 309 00:17:17,599 --> 00:17:21,599 just much more complicated. Didn't simply calling a method 310 00:17:21,900 --> 00:17:25,599 and then your database and a microservice architecture. 311 00:17:25,599 --> 00:17:29,700 One of the key essential characteristics of a service is 312 00:17:29,700 --> 00:17:33,200 that it's Loosely coupled as a couple of different meanings 313 00:17:33,200 --> 00:17:35,000 there. But one of them is designed time 314 00:17:35,000 --> 00:17:38,100 coupling, which is where you want to be out of change your 315 00:17:38,100 --> 00:17:41,500 service without other two services having to change in 316 00:17:41,500 --> 00:17:47,200 lock step one key way to achieve that is to treat each Services 317 00:17:47,200 --> 00:17:52,000 databases private, so Oh Kyle, a private fields of a class. 318 00:17:52,000 --> 00:17:54,100 Right? No one can access that. 319 00:17:54,300 --> 00:17:57,100 So, what does that mean? Well, it means that each service 320 00:17:57,100 --> 00:18:00,800 has its own database. So that makes transaction 321 00:18:00,800 --> 00:18:04,900 management, much more complex. You can't simply begin. 322 00:18:04,900 --> 00:18:09,700 A transaction update arbitrary data in multiple services and 323 00:18:09,700 --> 00:18:13,000 commit that transaction where you could try, you could use two 324 00:18:13,000 --> 00:18:15,800 phase commit, but that's quite complex. 325 00:18:16,000 --> 00:18:19,400 And it also introduces another type of coupling run. 326 00:18:19,500 --> 00:18:24,600 Time coupling, which is where Services have to be up together 327 00:18:24,700 --> 00:18:28,700 in order to handle a request and that actually impacts your 328 00:18:28,700 --> 00:18:32,000 availability. So you end up, you can't use 329 00:18:32,000 --> 00:18:35,700 classic distributed transactions and you have to use eventual 330 00:18:35,700 --> 00:18:39,000 consistency, which is much more complex. 331 00:18:39,500 --> 00:18:42,300 So it's likely monolithic World. Simple. 332 00:18:42,600 --> 00:18:45,700 The microservice wall can be more complex. 333 00:18:46,500 --> 00:18:49,400 So hearing what you say about microservices from all these 334 00:18:49,400 --> 00:18:53,400 complexity, probably, it's an exponential difficulty in terms 335 00:18:53,400 --> 00:18:56,700 of difficulty, right, where you have to handle transactions, for 336 00:18:56,700 --> 00:18:59,200 example, eventual, consistency. How about failures? 337 00:18:59,500 --> 00:19:02,200 If you need to coordinate multiple services, so why 338 00:19:02,200 --> 00:19:04,500 suddenly all these crazy about microservices? 339 00:19:04,700 --> 00:19:08,300 What do you think will be the right time for any company or 340 00:19:08,300 --> 00:19:10,200 any product to actually embrace this? 341 00:19:11,100 --> 00:19:14,300 Well, it's sort of assume that you're operating in a context 342 00:19:14,300 --> 00:19:16,200 where we need to deliver software. 343 00:19:16,300 --> 00:19:20,600 Rapidly frequently and reliably view, the state-of-the-art for 344 00:19:20,600 --> 00:19:25,900 software development practices. This might sound extreme but the 345 00:19:25,900 --> 00:19:29,000 ideal world is where I'm a developer. 346 00:19:29,000 --> 00:19:32,200 I commit my change. That change is just 347 00:19:32,200 --> 00:19:37,400 automatically built tested and deployed into production and as 348 00:19:37,400 --> 00:19:40,600 a developer, I'm committing changes at least once a day. 349 00:19:41,100 --> 00:19:46,100 So you've just got this constant stream of small changes. 350 00:19:46,300 --> 00:19:50,200 Automatic being built tested on automatically deployed into 351 00:19:50,200 --> 00:19:52,500 production one of the challenges. 352 00:19:52,600 --> 00:19:55,900 So if you've got a small monolith, you can do that. 353 00:19:56,100 --> 00:19:58,300 There's many different factors to consider. 354 00:19:58,700 --> 00:20:01,500 But if you think about what, how long does it take to run the 355 00:20:01,500 --> 00:20:04,600 test? That's one key factor, you know. 356 00:20:04,600 --> 00:20:09,300 If your monolith is small, the test will execute very quickly. 357 00:20:09,300 --> 00:20:14,900 So your deployment pipeline can keep up with the rate of commits 358 00:20:14,900 --> 00:20:16,200 that are coming from your development. 359 00:20:16,300 --> 00:20:20,500 Put as your application, grows in size, it gets bigger, and 360 00:20:20,500 --> 00:20:23,000 bigger. And then the test take longer 361 00:20:23,000 --> 00:20:25,000 and longer. If you think about even just 362 00:20:25,000 --> 00:20:27,800 something as simple as the startup time for your 363 00:20:27,800 --> 00:20:32,200 application, massive monolith can take many minutes to start 364 00:20:32,200 --> 00:20:34,500 up and then you can run some tests. 365 00:20:34,700 --> 00:20:38,800 So ultimately there are these issues around the site, just the 366 00:20:38,800 --> 00:20:42,700 pure size of your application, slows down your deployment 367 00:20:42,700 --> 00:20:44,500 Pipeline. And then also from the 368 00:20:44,508 --> 00:20:47,900 perspective of a developer. But if I'm working with its 369 00:20:47,900 --> 00:20:52,100 complex code base, that's can be overwhelming as well. 370 00:20:52,400 --> 00:20:55,800 And there are ways to modularize it so that you can break things 371 00:20:55,800 --> 00:20:57,600 up. You have a modular monolith 372 00:20:57,600 --> 00:21:01,100 where you can break things up into vertical slices and which 373 00:21:01,100 --> 00:21:04,500 can be worked on independently, But ultimately, they have to be 374 00:21:04,500 --> 00:21:08,200 assembled together and tested at some point. 375 00:21:08,200 --> 00:21:12,800 It becomes problematic class. When you deploy the application, 376 00:21:12,800 --> 00:21:16,100 you're deploying it in its entirety, which I think is just 377 00:21:16,300 --> 00:21:19,400 Apparently complex. And then you contrast that with 378 00:21:19,400 --> 00:21:22,400 the make for service architecture where you have a 379 00:21:22,400 --> 00:21:26,200 bunch of Team sized services. So I'm working on the order 380 00:21:26,200 --> 00:21:29,100 management team. I'm responsible for the order of 381 00:21:29,100 --> 00:21:32,800 service. That's a much smaller more 382 00:21:32,800 --> 00:21:35,000 easily. Understood codebase. 383 00:21:35,500 --> 00:21:40,100 I can build it test it quite quickly, push it into production 384 00:21:40,400 --> 00:21:44,800 and I can change the order service without having to update 385 00:21:44,800 --> 00:21:48,500 customer management. Or account management and so on. 386 00:21:48,700 --> 00:21:52,700 So you have that independent employability and so it can be, 387 00:21:52,800 --> 00:21:55,100 if you've got a rapid rate of change. 388 00:21:55,100 --> 00:21:59,600 The microservice architecture is much faster, much more fluid. 389 00:21:59,900 --> 00:22:02,500 And then the last point I would make is, you know, you think 390 00:22:02,500 --> 00:22:07,100 about modern application or successful applications that run 391 00:22:07,100 --> 00:22:10,200 a business, they tend to last for decades. 392 00:22:10,500 --> 00:22:13,700 So you imagine that you've got some fifteen-year-old 393 00:22:13,700 --> 00:22:18,900 application and its massive. Upgrading that application to a 394 00:22:18,900 --> 00:22:22,200 new technology stack, even basic stuff. 395 00:22:22,200 --> 00:22:24,800 Like I want to apply security patches. 396 00:22:24,800 --> 00:22:28,900 So which means that you have to remain reasonably current, you 397 00:22:28,900 --> 00:22:31,400 want to hire people. They don't want to work on 398 00:22:31,400 --> 00:22:34,800 Ancient technology. So it's important to keep your 399 00:22:34,800 --> 00:22:39,100 code base current, in terms of what technology Stacks it's 400 00:22:39,100 --> 00:22:43,500 using, that's really difficult. If you have a massive monolithic 401 00:22:43,500 --> 00:22:46,700 application, whereas, if you contrast that, That with the 402 00:22:46,700 --> 00:22:50,600 microservice architecture. Each service is relatively 403 00:22:50,600 --> 00:22:53,200 small. It can have a different its own 404 00:22:53,200 --> 00:22:57,900 specific technology stack and you can upgrade one service at a 405 00:22:57,900 --> 00:23:02,400 time and that helps you build these applications that are 406 00:23:02,400 --> 00:23:06,800 sustainable over the long run. And I think you also mentioned 407 00:23:06,800 --> 00:23:11,000 that these triangle for Success implementation of microservices. 408 00:23:11,000 --> 00:23:12,500 Right? Could you maybe share? 409 00:23:12,500 --> 00:23:15,400 What is this model about? What is this success of 410 00:23:15,600 --> 00:23:18,800 triangle? Oh, yeah, so the argument goes 411 00:23:18,800 --> 00:23:21,800 this way, right? Because the world is volatile 412 00:23:21,800 --> 00:23:25,800 and uncertain businesses and hence it need to be nimble and 413 00:23:25,800 --> 00:23:29,400 agile and they need to deliver software rapidly frequently and 414 00:23:29,400 --> 00:23:32,700 reliably and sustainably over the long run. 415 00:23:33,000 --> 00:23:35,400 And so the question is, how do you do that? 416 00:23:35,600 --> 00:23:38,000 And so that's the success. Triangle. 417 00:23:38,200 --> 00:23:42,500 It says, in order to accomplish those software delivery goals. 418 00:23:42,500 --> 00:23:45,900 You need to do three things. One is, you need to embrace 419 00:23:45,900 --> 00:23:48,600 death. The bolts as defined by the 420 00:23:48,600 --> 00:23:51,900 devops handbook. It's a set of principles and 421 00:23:51,900 --> 00:23:54,800 practices for delivering software rapidly. 422 00:23:54,800 --> 00:23:59,000 Part of that is stream of small changes flowing into production. 423 00:23:59,000 --> 00:24:02,900 The second part of the success, triangle is the organization. 424 00:24:02,900 --> 00:24:07,700 The idea there is that you struck to your organization as a 425 00:24:07,700 --> 00:24:12,400 set, as a network of loosely coupled, autonomous 426 00:24:12,400 --> 00:24:16,700 cross-functional team because you really want to have Wait, 427 00:24:16,700 --> 00:24:21,600 with siloed, developers, develop QA tests and production 428 00:24:21,600 --> 00:24:24,100 managers. Where are you have to hand off 429 00:24:24,100 --> 00:24:28,100 software from one to the other and then the people are incented 430 00:24:28,100 --> 00:24:31,700 for very different things. Developers are paid to change 431 00:24:31,700 --> 00:24:35,000 things. And up, Sileo basically paid to 432 00:24:35,000 --> 00:24:38,000 keep things stable. In other words, not change 433 00:24:38,000 --> 00:24:41,200 things. And so teams are just have all 434 00:24:41,200 --> 00:24:45,500 of those responsibilities within the same team, but then I 435 00:24:45,500 --> 00:24:48,600 actually Operations. They provide platform to enable 436 00:24:48,600 --> 00:24:51,200 the teams to do self service deployment. 437 00:24:51,200 --> 00:24:54,900 Excellent book on that called team topologies, which is sort 438 00:24:54,900 --> 00:24:59,200 of like a blueprint for modern organization design. 439 00:24:59,700 --> 00:25:02,900 So we've got process, you got organization. 440 00:25:02,900 --> 00:25:05,700 And then the third part is architecture. 441 00:25:05,900 --> 00:25:09,100 You need an architecture that supports devops and that's 442 00:25:09,100 --> 00:25:12,100 getting into deployability and testability. 443 00:25:12,400 --> 00:25:16,100 You need an architecture that supports the organizational. 444 00:25:16,200 --> 00:25:18,800 Structure. And that's what Conway's law 445 00:25:18,800 --> 00:25:22,700 replies. Basically Conway's law says that 446 00:25:22,700 --> 00:25:25,300 the structure of the architecture and the structure 447 00:25:25,300 --> 00:25:29,100 of the organization that created the architecture of basically 448 00:25:29,100 --> 00:25:33,400 mirrors of one another. So if you want a Loosely coupled 449 00:25:33,400 --> 00:25:37,800 organization, you need a Loosely coupled architecture modular. 450 00:25:38,000 --> 00:25:42,000 Your architecture is comprised of modules modules have apis, 451 00:25:42,000 --> 00:25:44,800 there's minimal coupling between those modules. 452 00:25:45,100 --> 00:25:49,500 So that the Teams are not constantly in meetings to 453 00:25:49,500 --> 00:25:53,100 discuss an aligned and all of the other things, people seem to 454 00:25:53,100 --> 00:25:56,700 spend their time doing and tightly coupled organizations. 455 00:25:56,800 --> 00:25:59,000 We've got an architectural requirements. 456 00:25:59,000 --> 00:26:03,000 I think I said testability deployability Loosely coupled 457 00:26:03,000 --> 00:26:06,100 modular architecture. And then if you throw in the 458 00:26:06,100 --> 00:26:09,400 sustainable peace, that means you need an architecture. 459 00:26:09,400 --> 00:26:13,200 That lets you upgrade your technology stack easily over 460 00:26:13,200 --> 00:26:15,100 time. Which in a sense you could say, 461 00:26:15,100 --> 00:26:17,400 as a modular. Concepts are related to 462 00:26:17,400 --> 00:26:20,200 modularity or it's evolvability. Right? 463 00:26:20,400 --> 00:26:22,800 So you've got a set of requirements that you 464 00:26:22,800 --> 00:26:27,800 architecture must satisfy, which then goes back to sometimes, you 465 00:26:27,800 --> 00:26:31,200 can satisfy those requirements with the monolithic 466 00:26:31,200 --> 00:26:34,000 architecture. But once you get to a certain 467 00:26:34,000 --> 00:26:37,600 level of scale, you're probably better off using the 468 00:26:37,600 --> 00:26:41,300 microservice architecture. So, you mentioned a couple of 469 00:26:41,300 --> 00:26:44,800 times already a regarding independent deployability, right 470 00:26:44,800 --> 00:26:46,900 modularity. And also, Loosely coupled 471 00:26:46,900 --> 00:26:50,900 services and you refer to this as design time coupling also a 472 00:26:50,900 --> 00:26:54,200 few times, what do you think is a design time? 473 00:26:54,200 --> 00:26:56,000 Coupling. What is that actually? 474 00:26:56,000 --> 00:27:01,300 And why we should avoid that. Well the degree of design time 475 00:27:01,300 --> 00:27:06,700 coupling between two modules, not say A, and B is the 476 00:27:06,700 --> 00:27:11,900 likelihood that A and B have to change in lockstep and you want 477 00:27:11,900 --> 00:27:15,200 to minimize that, right. So let's imagine for instance, 478 00:27:15,200 --> 00:27:17,500 those two. Well, let's just say 479 00:27:17,500 --> 00:27:19,800 automatically customer management. 480 00:27:19,800 --> 00:27:21,700 There are owned by different teams. 481 00:27:22,000 --> 00:27:27,000 So requirement comes in some new requirement comes in the ideal 482 00:27:27,000 --> 00:27:30,700 scenario. Is that requirement just impacts 483 00:27:30,700 --> 00:27:34,200 one of those modules. So it just gets assigned to the 484 00:27:34,200 --> 00:27:37,300 relevant team. Now, if there's designed time, 485 00:27:37,300 --> 00:27:42,300 coupling between those services or between those modules team, a 486 00:27:42,300 --> 00:27:46,000 changes their service that actually forces a changed. 487 00:27:46,100 --> 00:27:51,400 To service B which requires having meetings in coordination 488 00:27:51,400 --> 00:27:55,000 with the other team suddenly, the whole process of 489 00:27:55,000 --> 00:27:59,700 implementing that change takes a lot longer ranging from you 490 00:27:59,700 --> 00:28:02,400 actually have to find a time when you can both meet. 491 00:28:02,400 --> 00:28:05,300 You have to find a meeting room. Most companies. 492 00:28:05,300 --> 00:28:07,900 I visited they never had enough meeting rooms. 493 00:28:09,700 --> 00:28:13,500 It was like finding a meeting room, was a major challenge in 494 00:28:13,500 --> 00:28:16,000 the work environment, which is sort of a sign that 495 00:28:16,100 --> 00:28:19,400 Organizations with too tightly coupled also. 496 00:28:19,400 --> 00:28:22,700 Different teams can have different priorities and so to 497 00:28:22,700 --> 00:28:25,200 get something done that spans teams. 498 00:28:25,200 --> 00:28:28,000 They both have to make it a priority which can be 499 00:28:28,000 --> 00:28:31,400 challenging as well. Whereas if work is happening 500 00:28:31,400 --> 00:28:35,200 inside a single team. He does have a discussion at 501 00:28:35,200 --> 00:28:37,900 your daily stand-up. People have done studies. 502 00:28:37,900 --> 00:28:41,400 Go Works through the study of this and it was like decision 503 00:28:41,400 --> 00:28:46,000 making across teams took 10 times longer than decision. 504 00:28:46,100 --> 00:28:49,500 King within a t so it all largely ties back to the 505 00:28:49,500 --> 00:28:53,900 concepts of design time cup like so it's sort of like how do you 506 00:28:53,900 --> 00:28:56,200 achieve that? And part of it is having 507 00:28:56,200 --> 00:29:01,800 well-defined stable, apis that encapsulate, the design 508 00:29:01,800 --> 00:29:06,700 decisions of the implementation so that they can be changed 509 00:29:06,700 --> 00:29:11,700 without impacting the API. This very kind of cool concept 510 00:29:11,700 --> 00:29:15,800 of software development that dates back to like the 70s. 511 00:29:16,100 --> 00:29:19,600 That's why I designed time coupling is really important to 512 00:29:19,600 --> 00:29:23,800 just minimize coordination and communication between the tips, 513 00:29:24,100 --> 00:29:27,700 but I'll give you an example. This is from back in 2002. 514 00:29:27,700 --> 00:29:30,600 Nothing to do with microservices, but I was working 515 00:29:30,600 --> 00:29:33,600 on this device management platform, you know, I was 516 00:29:33,600 --> 00:29:36,800 leading the server team and then there was a client. 517 00:29:36,800 --> 00:29:40,800 He they wrote low-level code. That one in mobile devices. 518 00:29:41,000 --> 00:29:43,600 We were in the US and they were in the UK. 519 00:29:44,000 --> 00:29:49,100 Well, we met we agreed on the Kpi simple API that we were 520 00:29:49,100 --> 00:29:52,300 going to use to communicate. They just went off and did their 521 00:29:52,300 --> 00:29:56,000 development and we went off and did our development and then, 522 00:29:56,000 --> 00:29:57,900 let's just say, six months later. 523 00:29:58,100 --> 00:30:02,600 We met and integrated the two pieces together followed by 524 00:30:02,600 --> 00:30:06,200 remember, it'll just kind of work and I think that was a good 525 00:30:06,200 --> 00:30:10,700 example of having Loosely coupled software that could be 526 00:30:10,700 --> 00:30:14,300 developed independently. Otherwise, the opposite would 527 00:30:14,300 --> 00:30:18,200 have been some tight. Coupled software where we can 528 00:30:18,200 --> 00:30:21,700 constantly, having transatlantic phone calls. 529 00:30:21,800 --> 00:30:25,200 It would have just been a lot slower and a lot more unpleasant 530 00:30:25,200 --> 00:30:29,600 to actually develop product. So, also I see a lot of people 531 00:30:29,600 --> 00:30:32,200 who started from one of the, if because, they are so used to 532 00:30:32,200 --> 00:30:35,900 have dysfunctions all available to across different teams, and 533 00:30:35,900 --> 00:30:39,100 they just call each other. One of the common interpreters. 534 00:30:39,100 --> 00:30:42,000 ICS was, they break into different Services, right? 535 00:30:42,000 --> 00:30:43,900 Not necessarily a lot of bike or Services. 536 00:30:44,100 --> 00:30:45,900 They will tend to have this shit. 537 00:30:46,000 --> 00:30:47,800 At library, maybe call it a core. 538 00:30:47,800 --> 00:30:51,600 Common modules that is shared across different services. 539 00:30:51,700 --> 00:30:54,600 So what do you think about that? Is that also a design time 540 00:30:54,600 --> 00:30:58,400 coupling? Well, it depends, you could view 541 00:30:58,400 --> 00:31:01,200 it as there's two types of shared libraries. 542 00:31:01,300 --> 00:31:05,800 So one libraries where different Services can use different 543 00:31:05,800 --> 00:31:09,500 versions than the library and still function correctly and 544 00:31:09,500 --> 00:31:12,800 that's good. It just saves duplicated code, 545 00:31:12,800 --> 00:31:17,100 duplicated development and that's primarily It's to 546 00:31:17,200 --> 00:31:20,700 utilities, then there's the other type of library and that 547 00:31:20,700 --> 00:31:23,300 would be a library that has business logic. 548 00:31:23,600 --> 00:31:28,200 Everything is great until the requirements change, and that 549 00:31:28,200 --> 00:31:33,200 library has to be updated and all of the services that use it, 550 00:31:33,200 --> 00:31:35,900 have to be running on the same version. 551 00:31:36,200 --> 00:31:38,500 Now once in a while, that's okay. 552 00:31:38,700 --> 00:31:42,900 It might be worthwhile trade-off because if a library is embedded 553 00:31:42,900 --> 00:31:47,300 within a service, it's invoked by Via local method. 554 00:31:47,300 --> 00:31:49,500 Cool. That's super efficient. 555 00:31:49,700 --> 00:31:53,600 There's actually a benefit to embedding to having a shared 556 00:31:53,600 --> 00:31:58,300 library, but then the downside is having to upgrade multiple 557 00:31:58,300 --> 00:32:03,600 services in lockstep. So it's generally a bad idea 558 00:32:03,800 --> 00:32:08,500 except when it's dull, you know, there was a company segment. 559 00:32:08,700 --> 00:32:12,200 I think they gave a talk about Hugh con about how we adopted 560 00:32:12,200 --> 00:32:15,100 microservices. It went badly and we went back 561 00:32:15,100 --> 00:32:18,400 to a monolith. And I suspect that for remember 562 00:32:18,400 --> 00:32:21,900 correctly, the actual problem. There was, they had a shared 563 00:32:21,900 --> 00:32:25,200 library that implemented business logic, that kept 564 00:32:25,200 --> 00:32:30,500 changing the force that services to be updated in lockstep. 565 00:32:30,500 --> 00:32:34,300 Constantly, that scenario is known as the distributed 566 00:32:34,300 --> 00:32:37,400 monolith anti pattern, which is basically where you have a 567 00:32:37,408 --> 00:32:42,100 distributed system, but you have to change all of it in one go. 568 00:32:42,400 --> 00:32:45,900 So you've got a monolith. It really is like the worst. 569 00:32:46,000 --> 00:32:49,900 Of Both Worlds, but in that keyword, here is the lockstep. 570 00:32:50,000 --> 00:32:53,500 If you notice that you always have to do this kind of lockstep 571 00:32:53,700 --> 00:32:56,800 where you'll require, once it is to change before you can change. 572 00:32:56,800 --> 00:32:59,200 I think that's anti pattern that we should avoid, right? 573 00:32:59,900 --> 00:33:03,000 Yeah, that's very much. An architectural smell. 574 00:33:03,000 --> 00:33:06,300 So you should design up front to eliminate it. 575 00:33:06,600 --> 00:33:09,700 But then it down the line, you see that, it's constantly 576 00:33:09,700 --> 00:33:14,800 occurring where Services A and B of regularly changing for the 577 00:33:14,800 --> 00:33:18,300 same underlying. He's a, that's an indication 578 00:33:18,300 --> 00:33:22,700 that a refactoring is needed. So another thing that is 579 00:33:22,700 --> 00:33:26,000 complicated in all these micro Services architecture, is what 580 00:33:26,000 --> 00:33:29,500 we deem for distributed transaction kind of thing where 581 00:33:29,500 --> 00:33:33,200 you actually have to maintain consistency by committing in 582 00:33:33,200 --> 00:33:36,000 multiple databases across services, and actually our 583 00:33:36,000 --> 00:33:39,800 company eventuate is doing a solution around that, but before 584 00:33:39,800 --> 00:33:41,500 that could you maybe share with us? 585 00:33:41,500 --> 00:33:44,400 How do we commonly tackle or solve this problem? 586 00:33:45,100 --> 00:33:47,500 Oh, yeah. So the example I use all the 587 00:33:47,500 --> 00:33:51,800 time is customers and Waters. There's a requirement where the 588 00:33:51,800 --> 00:33:56,400 customer has a credit limit, which means the in order to 589 00:33:56,400 --> 00:34:00,500 create an order, you have to reserve some of that credit. 590 00:34:00,500 --> 00:34:03,700 So you can imagine the customer and to the has an available 591 00:34:03,700 --> 00:34:07,700 credit attribute that gets reduced by the order total when 592 00:34:07,700 --> 00:34:11,000 an order is created and but it can never go below 0. 593 00:34:11,400 --> 00:34:14,800 So a monolithic application. No, big deal right in. 594 00:34:14,900 --> 00:34:18,300 My cursor is architecture where you've got customers and orders 595 00:34:18,300 --> 00:34:22,900 and different Services. The order service has to Reserve 596 00:34:22,900 --> 00:34:25,500 credit. Inside the customer service, 597 00:34:25,800 --> 00:34:31,199 that request spans Services. The approach that you would use, 598 00:34:31,199 --> 00:34:34,600 as The Saga pattern. They would go basically like 599 00:34:34,600 --> 00:34:36,199 this. So, step number one. 600 00:34:36,199 --> 00:34:40,199 The order service would create an order in the pending State. 601 00:34:40,400 --> 00:34:44,400 A message would be sent to the customer service, asking it to. 602 00:34:44,800 --> 00:34:47,699 Have credit where tries to do that. 603 00:34:48,100 --> 00:34:51,199 Two possible outcomes, of course where she three. 604 00:34:51,300 --> 00:34:55,500 Customer doesn't exist. Credit was successfully reserved 605 00:34:55,600 --> 00:34:57,900 or the credit limit was exceeded. 606 00:34:58,300 --> 00:35:01,900 So the customer service will send a message back to the order 607 00:35:01,900 --> 00:35:04,900 service. And the order service, it will 608 00:35:04,900 --> 00:35:07,600 change the status of the order to approved. 609 00:35:07,600 --> 00:35:11,600 If the credit reservation was successful, otherwise change the 610 00:35:11,600 --> 00:35:15,700 status of the order to reject it, if it was not So it's a bit 611 00:35:15,700 --> 00:35:18,900 more complicated and then there's a whole bunch of 612 00:35:18,900 --> 00:35:21,500 subtleties, right? We're no longer using acid 613 00:35:21,500 --> 00:35:24,500 transactions. It's eventually consistent. 614 00:35:24,600 --> 00:35:28,200 But if you think about the context, imagine that the order 615 00:35:28,200 --> 00:35:30,800 service had. A lot of complexity, the 616 00:35:30,800 --> 00:35:34,800 customer service had a lot of complexity by splitting them 617 00:35:34,800 --> 00:35:38,700 into two, which would enable each one to be built tested and 618 00:35:38,700 --> 00:35:42,000 deployed independently. We've got tremendous benefit. 619 00:35:42,300 --> 00:35:46,300 Just that the downside is we have to use Is the Saga pattern 620 00:35:46,500 --> 00:35:50,600 depending on the situation that can be a very worthwhile 621 00:35:50,600 --> 00:35:53,300 trade-off. Let me once again, this is all a 622 00:35:53,300 --> 00:35:56,500 giant. It depends, you know, sagas have 623 00:35:56,500 --> 00:36:00,600 the potential for them to be extremely complex, and it could 624 00:36:00,600 --> 00:36:04,400 be a sign that the two Services should be merged. 625 00:36:04,700 --> 00:36:08,400 But in other situations, they can be worth what you think. 626 00:36:08,400 --> 00:36:10,400 About. A really simple Saga, right? 627 00:36:10,400 --> 00:36:14,300 You have an order taking system that takes an order and then it 628 00:36:14,300 --> 00:36:18,000 just Fives that fulfillment system ship disorder. 629 00:36:18,200 --> 00:36:22,600 That's actually an example of a really simple Saga and no one 630 00:36:22,600 --> 00:36:24,800 would argue with that. It just worked. 631 00:36:25,200 --> 00:36:28,300 One of the key thing is, sometimes it's very much, a 632 00:36:28,300 --> 00:36:31,500 worthwhile trade-off. Where is another situation? 633 00:36:31,500 --> 00:36:34,900 Deserves too complicated? We can't do this, and we have to 634 00:36:34,900 --> 00:36:38,500 merge together. Yeah, and then how does your 635 00:36:38,500 --> 00:36:41,200 product eventuate actually help with all this? 636 00:36:41,900 --> 00:36:45,500 Oh, yeah. So basically, it's a Framework, 637 00:36:45,500 --> 00:36:48,400 where it's platform because there's this sort of code that 638 00:36:48,400 --> 00:36:52,200 runs inside the service itself. And then there's a sporting 639 00:36:52,200 --> 00:36:56,700 service, the implements, both The Saga pattern, and then some 640 00:36:56,700 --> 00:37:01,600 of the key underlying patterns that make all of this work 641 00:37:01,600 --> 00:37:04,800 reliably. So you can build sagas. 642 00:37:05,000 --> 00:37:06,800 That's definitely one part of it. 643 00:37:07,100 --> 00:37:10,700 Some of the underlying patterns are actually super interesting. 644 00:37:11,000 --> 00:37:15,000 So I want problem, you have is I said with the order service And 645 00:37:15,000 --> 00:37:18,100 water and sends a message via the message broker. 646 00:37:18,400 --> 00:37:22,700 Those two things have to be done atomically, the you're doing two 647 00:37:22,700 --> 00:37:26,600 things, updating a database, talkin to a message broker. 648 00:37:26,800 --> 00:37:28,800 So, how do you do that atomically? 649 00:37:28,800 --> 00:37:31,800 Because if you do one and not the other, your system is in a 650 00:37:31,800 --> 00:37:35,600 permanently inconsistent state, so the pattern for that is 651 00:37:35,600 --> 00:37:38,600 actually known as the transaction out books, pass it 652 00:37:38,900 --> 00:37:42,500 and that's where instead of sending a message directly to 653 00:37:42,500 --> 00:37:46,400 the message, broker the service. It's actually inserts the 654 00:37:46,400 --> 00:37:51,100 message into an out books table in the database as part of the 655 00:37:51,100 --> 00:37:53,200 transaction that creates the order. 656 00:37:53,400 --> 00:37:58,000 And that gives you atomicity, those two things because of the 657 00:37:58,000 --> 00:38:01,900 database transaction will both happen or neither of them will 658 00:38:01,900 --> 00:38:03,900 happen. And then there's a separate 659 00:38:03,900 --> 00:38:07,300 process, that's pulling the messages out of the database and 660 00:38:07,300 --> 00:38:09,200 sending them to the message broker. 661 00:38:09,400 --> 00:38:13,300 And that's sort of one of the key Foundation patterns that 662 00:38:13,300 --> 00:38:16,800 eventuate sport. This is actually quite complex. 663 00:38:17,100 --> 00:38:21,800 Can the ideal case rather than querying the database table? 664 00:38:21,800 --> 00:38:24,700 It's actually reading the database transaction. 665 00:38:24,700 --> 00:38:27,700 Look sort of Highly database specific. 666 00:38:28,200 --> 00:38:31,700 So eventually it does that and then on the receiving end the 667 00:38:31,700 --> 00:38:35,000 message, broker can deliver messages multiple times. 668 00:38:35,300 --> 00:38:40,100 So the message Handler has to detect and discard duplicate 669 00:38:40,100 --> 00:38:43,200 messages and eventuate implements that patterns. 670 00:38:43,200 --> 00:38:47,800 Well, so you the item Impotent consumer Captain, so that's just 671 00:38:47,800 --> 00:38:51,400 a sampling of some of the key pad instead eventuate supports. 672 00:38:51,400 --> 00:38:54,800 But the actual original motivation for eventuate was it 673 00:38:54,800 --> 00:38:58,500 was an implementation of the transactional out books pattern, 674 00:38:58,500 --> 00:39:02,500 and it grew out of that. So, based on the few things that 675 00:39:02,500 --> 00:39:05,100 you have mentioned thread section of box, pattern item, 676 00:39:05,100 --> 00:39:08,100 put them receiver pattern. Is there any other thing, or 677 00:39:08,100 --> 00:39:11,300 maybe tips for people to implement these Saga pattern 678 00:39:11,300 --> 00:39:15,000 correctly? 12 is actually a quiet deep 679 00:39:15,000 --> 00:39:17,800 topic. So, for instance, if you think 680 00:39:17,800 --> 00:39:21,100 about one of the interesting things about the Saga pattern, 681 00:39:21,100 --> 00:39:24,800 right, so it's a series of local transactions in multiple 682 00:39:24,800 --> 00:39:30,500 services. So if step 5 over Saga fails, 683 00:39:30,700 --> 00:39:34,300 you actually have to undo the changes that were done by the 684 00:39:34,300 --> 00:39:37,600 first four steps. And usually it's the semantics 685 00:39:37,600 --> 00:39:40,400 can be a semantic undo. For instance. 686 00:39:40,600 --> 00:39:42,100 Do you actually have to execute what? 687 00:39:42,200 --> 00:39:46,400 The note is compensating transactions to undo what was 688 00:39:46,400 --> 00:39:49,400 done. Previously, in the case of the 689 00:39:49,400 --> 00:39:53,500 customer and Order example, changing the status of the order 690 00:39:53,500 --> 00:39:56,100 to reject. It is actually a compensating 691 00:39:56,100 --> 00:39:59,000 transaction. So there's a lot of careful 692 00:39:59,000 --> 00:40:02,300 design required. Once again, you contrast that 693 00:40:02,300 --> 00:40:05,700 with a regular asset transaction where the service can simply 694 00:40:05,700 --> 00:40:09,300 execute a rollback statement to abort the transaction. 695 00:40:09,300 --> 00:40:14,000 Really simple happens automatically, but With sagas, 696 00:40:14,000 --> 00:40:16,900 you have to design it. That's another level of 697 00:40:16,900 --> 00:40:20,300 complexity. The last thing that you have to 698 00:40:20,300 --> 00:40:25,200 actually think about when designing sagas, is what 699 00:40:25,200 --> 00:40:29,200 happens, when two sagas execute concurrently. 700 00:40:29,600 --> 00:40:33,300 Now, if you go back to like database Theory, but goes back 701 00:40:33,300 --> 00:40:37,700 to the definition of acid, Atomic consistent isolated and 702 00:40:37,700 --> 00:40:42,000 durable, turns out the sagas, lack, the isolation. 703 00:40:42,200 --> 00:40:44,900 Property then you go. What's isolation? 704 00:40:45,300 --> 00:40:49,300 So isolation is a property. That means that the concurrent 705 00:40:49,300 --> 00:40:53,600 execution of to database transactions is equivalent to 706 00:40:53,600 --> 00:40:57,800 some sequential watering. So if a and b are executing 707 00:40:57,800 --> 00:41:02,800 concurrently the outcome is either a followed by b or B 708 00:41:02,800 --> 00:41:06,500 followed by a primitive databases, they do locking and 709 00:41:06,500 --> 00:41:10,400 stuff to make that happen. But anyway sagas don't have the 710 00:41:10,400 --> 00:41:14,400 isolation property. That gives rise to what is known 711 00:41:14,400 --> 00:41:17,700 as a data. Anomaly in classic database 712 00:41:17,700 --> 00:41:20,300 literature. There's dirty reads for one. 713 00:41:20,300 --> 00:41:23,400 Transaction can read the uncommitted changes of another 714 00:41:23,400 --> 00:41:26,400 one lost updates and fuzzy reads. 715 00:41:26,900 --> 00:41:30,800 So if you look at the customer and Order example, the order is 716 00:41:30,800 --> 00:41:35,800 created in a pending State. That's actually an intermediate 717 00:41:35,800 --> 00:41:40,000 State because the Saga has not completed. 718 00:41:40,200 --> 00:41:44,000 The ultimate outcome is still All being determined and that's 719 00:41:44,000 --> 00:41:47,200 actually a dirty read. And once again, the sounds 720 00:41:47,200 --> 00:41:51,700 really scary and in theory could lead to slaughter them bugs and 721 00:41:51,700 --> 00:41:55,300 so on but it's sort of a level that you just have to be aware 722 00:41:55,300 --> 00:41:58,700 of this problem. So for example, someone queries, 723 00:41:58,700 --> 00:42:02,900 the state of waters and this order that has just been created 724 00:42:02,900 --> 00:42:06,400 and in the pending state, is that a real order yet? 725 00:42:06,700 --> 00:42:09,600 Whoa, It's still being determined but it's like from a 726 00:42:09,607 --> 00:42:12,100 reporting point of view. Maybe it is. 727 00:42:12,300 --> 00:42:16,000 And and then if someone tries in theory, someone can cancel it, 728 00:42:16,100 --> 00:42:18,100 but what does it mean to cancel in water? 729 00:42:18,100 --> 00:42:20,800 That is still in the process of being created? 730 00:42:20,800 --> 00:42:23,200 And we may or may not have reserved credit. 731 00:42:23,600 --> 00:42:27,100 So there's some sort of complex issues there to solve them. 732 00:42:27,100 --> 00:42:30,200 You have to be aware of these design techniques known as 733 00:42:30,200 --> 00:42:33,400 countermeasures. Countermeasure is a design 734 00:42:33,400 --> 00:42:37,700 technique that eliminates these data anomalies and it turns out, 735 00:42:37,700 --> 00:42:41,000 the reason you create an order in a pending state. 736 00:42:41,000 --> 00:42:45,300 Is that snake? Example of a semantic lock that 737 00:42:45,300 --> 00:42:48,900 order is locked at the application Level and it's sort 738 00:42:48,900 --> 00:42:51,900 of a softlock, the application logic. 739 00:42:51,900 --> 00:42:55,200 Any application logic should actually look at the state of 740 00:42:55,200 --> 00:42:59,100 the order and go. Oh, it's pending, therefore I 741 00:42:59,100 --> 00:43:03,500 should do something different. Perhaps, if someone tries to 742 00:43:03,500 --> 00:43:07,800 cancel it, maybe the council should fail with her status 743 00:43:07,800 --> 00:43:11,200 saying, try again later. So, it's something you have to 744 00:43:11,200 --> 00:43:16,200 be aware of. And design for explicitly rather 745 00:43:16,200 --> 00:43:19,100 than just relying on the database to make this happen 746 00:43:19,100 --> 00:43:22,000 magically for you, Shameless plug. 747 00:43:22,000 --> 00:43:25,700 I have an online course that talks about all of these issues. 748 00:43:25,900 --> 00:43:27,600 Right? So I'll make sure to mention 749 00:43:27,600 --> 00:43:30,100 that in the show notes. So as we put all these 750 00:43:30,100 --> 00:43:33,000 complexities, I think it's really good to have these kind 751 00:43:33,000 --> 00:43:35,100 of patterns. In fact, I think microservices. 752 00:43:35,100 --> 00:43:38,400 Are you try to have these patterns available for people to 753 00:43:38,400 --> 00:43:41,300 read about and understand what these the common problem that 754 00:43:41,300 --> 00:43:43,200 you see. And what are the typical 755 00:43:43,200 --> 00:43:44,900 patterns that you can use to solve this? 756 00:43:45,000 --> 00:43:48,100 So, I think that website itself is gold for people who would 757 00:43:48,100 --> 00:43:51,700 like to invite microservice. Another thing that I saw you 758 00:43:51,700 --> 00:43:55,000 Advocate is actually when people try to decompose their monolith, 759 00:43:55,000 --> 00:43:57,700 there are ten principles. So I know that we are running 760 00:43:57,700 --> 00:43:59,200 out of time. We won't be covering all of 761 00:43:59,200 --> 00:44:02,500 them, but maybe if you can do in a kind of, like rapid fire 762 00:44:02,500 --> 00:44:06,600 Manner, and I think maybe five different principles maybe that 763 00:44:06,600 --> 00:44:08,500 start with make the most of your monologue. 764 00:44:09,000 --> 00:44:14,500 Yeah, like, principle number one is, don't Except in the sense 765 00:44:14,500 --> 00:44:17,300 try and make the most of you monolith. 766 00:44:17,500 --> 00:44:21,700 So for example, yeah, I've sort of had this conversation a lot 767 00:44:21,700 --> 00:44:24,700 with people where it's like, yeah, you know how development 768 00:44:24,700 --> 00:44:27,500 process is really slow and there's bugs. 769 00:44:27,500 --> 00:44:30,700 I think we should just adopt the microservice architecture and 770 00:44:30,700 --> 00:44:34,900 that will fix our problems and it's sort of like, yeah, maybe 771 00:44:34,900 --> 00:44:39,900 microservices will solve your problem, but I would first look 772 00:44:39,900 --> 00:44:43,500 at actually optimizing your development process. 773 00:44:43,800 --> 00:44:46,600 So, for instance, could common problem with a lot of 774 00:44:46,600 --> 00:44:49,500 Enterprises. They don't do automated testing 775 00:44:49,700 --> 00:44:53,200 the relying heavily on manual testing, while, if you put in 776 00:44:53,200 --> 00:44:58,300 place, automated testing, that's likely to have dramatically 777 00:44:58,300 --> 00:45:03,000 improve your ability to deliver software quickly, right? 778 00:45:03,000 --> 00:45:07,300 Fewer bugs, higher quality software, much more rapid 779 00:45:07,300 --> 00:45:10,700 delivery. That's just one example of how 780 00:45:10,700 --> 00:45:15,000 you can improve your Process with your existing monolith, 781 00:45:15,300 --> 00:45:18,400 especially when you're a small team of people. 782 00:45:18,700 --> 00:45:22,400 If someone came to me and said that we've got 100 developers 783 00:45:22,400 --> 00:45:26,200 and we're having problems, perhaps it would be more likely, 784 00:45:26,200 --> 00:45:29,900 the part of the solution would be to use the micro service 785 00:45:29,900 --> 00:45:32,200 architecture. But if you have a team of five 786 00:45:32,200 --> 00:45:36,700 developers, probably not and it's not black and white, it 787 00:45:36,700 --> 00:45:39,900 will very much depends, but the smaller the team, the more 788 00:45:39,900 --> 00:45:42,000 likely that the monolith is, okay. 789 00:45:42,100 --> 00:45:45,100 Okay, and it's your development process. 790 00:45:45,100 --> 00:45:48,200 That's lacking the second principle that I find 791 00:45:48,200 --> 00:45:51,600 interesting is that success is improved velocity. 792 00:45:51,600 --> 00:45:54,000 And reliability. Maybe can you explain a little 793 00:45:54,000 --> 00:45:54,800 bit more? Yeah. 794 00:45:54,900 --> 00:45:57,700 This is a really good point. So, throughout this. 795 00:45:57,700 --> 00:46:00,700 I've been talking about rapid frequent Reliable Software 796 00:46:00,700 --> 00:46:02,600 delivery. What is that? 797 00:46:02,900 --> 00:46:07,300 So there's actually four metrics which come from Devils. 798 00:46:07,900 --> 00:46:12,000 The research has shown to be a good indicator of how 799 00:46:12,200 --> 00:46:15,200 Performance one metric is lead time. 800 00:46:15,700 --> 00:46:20,200 What's the time from a developer committing, pushing the changes 801 00:46:20,200 --> 00:46:24,300 checking in their changes, to that change being deployed into 802 00:46:24,300 --> 00:46:27,800 production, High performing organizations. 803 00:46:27,800 --> 00:46:31,400 That lead time is too short. State-of-the-art. 804 00:46:31,400 --> 00:46:35,600 You could say it's 15 minutes. Basically, you've got a fully 805 00:46:35,600 --> 00:46:38,800 automated deployment pipeline, the builds tabs. 806 00:46:38,800 --> 00:46:42,600 Deploys each commit. Another key metric is deployment 807 00:46:42,600 --> 00:46:45,000 frequency. How frequently are you 808 00:46:45,000 --> 00:46:47,100 deploying? And it's somewhat tied in with 809 00:46:47,100 --> 00:46:48,600 lead time. You could say. 810 00:46:48,600 --> 00:46:52,900 A goal would be at least once a day per developer, which is 811 00:46:52,900 --> 00:46:55,300 quite different from the we deploy. 812 00:46:55,300 --> 00:46:58,200 Every two weeks to every one supporter. 813 00:46:58,500 --> 00:47:01,600 So those are the two metrics that are measuring velocity, 814 00:47:02,100 --> 00:47:04,200 what I should see with deployment frequency. 815 00:47:04,200 --> 00:47:06,400 One ain't seen example is Amazon. 816 00:47:06,400 --> 00:47:10,600 We're doing it like that 130,000 changes a day to production 817 00:47:10,600 --> 00:47:12,900 which is like weak points. Second. 818 00:47:13,300 --> 00:47:16,400 And then there's reliability. And interestingly you think 819 00:47:16,400 --> 00:47:19,600 about the traditional approach to doing things? 820 00:47:19,600 --> 00:47:26,100 Reliably is to do things slowly and carefully but it turns out 821 00:47:26,100 --> 00:47:30,000 and this is key book to read is the accelerate book by Jazz 822 00:47:30,000 --> 00:47:33,700 humble and his colleagues and they found that high performing 823 00:47:33,700 --> 00:47:36,700 organizations are delivering small changes. 824 00:47:36,700 --> 00:47:41,100 Very rapidly in production, and it also leads to Greater 825 00:47:41,100 --> 00:47:44,000 reliability. T, which is completely 826 00:47:44,200 --> 00:47:48,000 counterintuitive, right? But the idea, if you do things 827 00:47:48,000 --> 00:47:51,400 slowly, that means every deployment, you're changing a 828 00:47:51,400 --> 00:47:54,900 massive amount, which is actually highly risky. 829 00:47:55,200 --> 00:47:58,100 You don't fully understand the impact of the change. 830 00:47:58,100 --> 00:48:01,900 Whereas, if I change one line of code, there's a pretty good 831 00:48:01,900 --> 00:48:04,000 chance. I know what that's gonna be 832 00:48:04,000 --> 00:48:06,100 impact of that. The other extreme. 833 00:48:06,500 --> 00:48:10,200 So there are the metrics around change, failure rate how often 834 00:48:10,200 --> 00:48:13,800 to deployments actually. Rake production and 835 00:48:13,800 --> 00:48:17,100 interestingly with Amazon, with their massive rate of change. 836 00:48:17,200 --> 00:48:20,400 They're hardly ever doubt. I mean, it's really unusual to 837 00:48:20,400 --> 00:48:25,600 go to amazon.com and Fritz and not work and then it related to 838 00:48:25,600 --> 00:48:29,500 that is mean time to recover if there is a problem. 839 00:48:29,500 --> 00:48:34,000 How quickly can you detect it? Diagnose it and fix it. 840 00:48:34,200 --> 00:48:37,400 And once again, you should rarely have production outages 841 00:48:37,700 --> 00:48:41,100 and you should be able to recover from them really quickly 842 00:48:41,400 --> 00:48:44,900 nose for Or metrics. That's the measure of how 843 00:48:44,900 --> 00:48:48,600 performin your organization it. So the whole point of 844 00:48:48,600 --> 00:48:53,100 microservices and adopting microservices is not to have 845 00:48:53,100 --> 00:48:57,200 microservices. It's really is to improve those 846 00:48:57,200 --> 00:49:02,100 metrics, you know worked with an organization's where this is one 847 00:49:02,100 --> 00:49:06,600 case, CIO says, do microservices and it was a top-down 848 00:49:06,600 --> 00:49:10,900 hierarchical organization. I'd meet with developers and our 849 00:49:10,900 --> 00:49:12,000 gasps. Why are you doing? 850 00:49:12,300 --> 00:49:15,700 For services and they go. Well, my manager told me to it 851 00:49:15,700 --> 00:49:19,300 is almost like, microservices became part of their keep the 852 00:49:19,300 --> 00:49:22,900 eyes, but that's not the goal. The goal is not to have 853 00:49:22,900 --> 00:49:26,200 microservices. The goal is to improve those 854 00:49:26,200 --> 00:49:30,600 metrics, and that's what people should be incented to improve 855 00:49:30,800 --> 00:49:34,700 because sometimes changing your development process around, your 856 00:49:34,700 --> 00:49:37,800 monolith will improve those metrics, but then in other 857 00:49:37,800 --> 00:49:42,700 situations where you really have outgrown your Teacher your 858 00:49:42,700 --> 00:49:46,800 monolithic architecture. Then adopting microservices is 859 00:49:46,800 --> 00:49:50,600 the only way to improve those metrics, but thanks for 860 00:49:50,600 --> 00:49:53,300 reminding us again. The key metrics is not how many 861 00:49:53,300 --> 00:49:56,600 microservices you have. How small is your micro service? 862 00:49:56,800 --> 00:49:58,900 So it's more about all these four key metrics. 863 00:49:59,000 --> 00:50:02,400 There are metrics some of them say so thanks for reminding that 864 00:50:02,600 --> 00:50:05,400 unfortunately, we cannot go on to cover the remaining eight, 865 00:50:05,400 --> 00:50:08,000 but for people who are interested in this principles, 866 00:50:08,000 --> 00:50:10,400 will check it out on Chris, Richardson's block. 867 00:50:10,600 --> 00:50:13,400 I think it's really insightful. So Chris, I know we are running 868 00:50:13,400 --> 00:50:15,400 out of time. But before I let you go, I 869 00:50:15,400 --> 00:50:18,100 normally ask this one question for all my guests, which is to 870 00:50:18,100 --> 00:50:21,000 share your tree. Technical leadership, wisdom as 871 00:50:21,000 --> 00:50:23,200 a tips for all of us here in our career. 872 00:50:23,200 --> 00:50:25,300 Maybe we can learn from you. Yeah. 873 00:50:25,500 --> 00:50:27,900 Well, I've had a little time to think about it. 874 00:50:28,200 --> 00:50:31,300 Perfect. I got a few things come to mind. 875 00:50:31,300 --> 00:50:34,600 I think one is just learn be curious. 876 00:50:35,100 --> 00:50:39,100 The two other ones, that sort of come to mind one is, it depends 877 00:50:39,300 --> 00:50:41,900 recognize that it depends? There are no. 878 00:50:42,000 --> 00:50:45,100 No, silver bullets. You want to look at every 879 00:50:45,100 --> 00:50:49,000 technology as having a set of trade-offs and this sort of goes 880 00:50:49,000 --> 00:50:53,200 back to patents, benefits drawbacks and issues, which is 881 00:50:53,200 --> 00:50:55,600 sub problems that you have to solve. 882 00:50:56,000 --> 00:50:59,800 And so, when you're doing any kind of design, you really want 883 00:50:59,800 --> 00:51:02,600 to just be aware of that. Lastly. 884 00:51:02,600 --> 00:51:06,700 I would just say think evaluate the trade-offs. 885 00:51:07,300 --> 00:51:08,900 So it's really a timely reminder. 886 00:51:08,900 --> 00:51:10,900 For those of you who are thinking of adopting 887 00:51:10,900 --> 00:51:12,700 microservices fall, not Good reason. 888 00:51:12,800 --> 00:51:15,300 Again, it's been a pleasure Chris for people who would like 889 00:51:15,300 --> 00:51:18,000 to learn more about this. Maybe follow you or contact you 890 00:51:18,200 --> 00:51:22,000 where they can find you. Oh, well couple of places. 891 00:51:22,300 --> 00:51:24,200 It's like microservices thought I. 892 00:51:24,200 --> 00:51:30,200 Oh so that's where the patterns reside presentations code Etc. 893 00:51:30,400 --> 00:51:32,900 There's also Chris Richardson dotnet. 894 00:51:32,900 --> 00:51:38,100 So that's my Consulting Scion training site and then obviously 895 00:51:38,100 --> 00:51:41,200 eventuate dot IO, that's my company. 896 00:51:41,800 --> 00:51:43,500 So Great. Thank you so much for spending 897 00:51:43,500 --> 00:51:44,900 your time. It's been a pleasure. 898 00:51:44,900 --> 00:51:47,900 I learned a lot from you. So good luck with all your talks 899 00:51:48,100 --> 00:51:49,800 courses and also the product itself. 900 00:51:49,800 --> 00:51:51,800 Eventuate are a great. Thanks. 901 00:51:51,800 --> 00:51:57,700 I've enjoyed it. Thank you for listening to this 902 00:51:57,700 --> 00:52:00,300 episode and for staying right till the end. 903 00:52:00,500 --> 00:52:03,400 If you highly enjoyed, please share it with your friends and 904 00:52:03,400 --> 00:52:06,800 colleagues who you think would also benefit from listening to 905 00:52:06,800 --> 00:52:09,000 this episode. And if you're new to the 906 00:52:09,000 --> 00:52:12,300 podcast, make sure to subscribe and leave me your valuable 907 00:52:12,300 --> 00:52:15,700 review and feedback. It really, really helps me a lot 908 00:52:15,800 --> 00:52:18,200 in order to grow these podcasts better. 909 00:52:18,800 --> 00:52:22,100 You can also find the full show notes of this conversation on 910 00:52:22,100 --> 00:52:24,800 the episode page at technology. No, the death. 911 00:52:25,400 --> 00:52:28,800 Including the full transcript interesting quotes and links to 912 00:52:28,800 --> 00:52:31,700 the resources and mentions from the conversation. 913 00:52:32,200 --> 00:52:35,100 And lastly make sure to subscribe to the shows mailing 914 00:52:35,100 --> 00:52:38,500 list on technology, another death to get notified for any 915 00:52:38,500 --> 00:52:41,100 future episodes. Stay tuned for the next 916 00:52:41,100 --> 00:52:43,600 technique Journal episode. And until then. 917 00:52:43,700 --> 00:52:44,300 Goodbye.