1 00:00:00,100 --> 00:00:02,200 Before we start our episode today. 2 00:00:02,400 --> 00:00:06,000 I have an exciting news to share with all of you as we are moving 3 00:00:06,000 --> 00:00:10,100 towards the end of 2020 and the upcoming Tech lead Journal. 20th 4 00:00:10,100 --> 00:00:12,500 episode. I would like to share some Joy 5 00:00:12,500 --> 00:00:15,400 by having a massive free giveaway of jetbrains. 6 00:00:15,400 --> 00:00:17,600 All products pack, personal licenses. 7 00:00:18,000 --> 00:00:21,000 Each personal license is worth two hundred forty nine US 8 00:00:21,000 --> 00:00:23,800 dollar. It's 100% completely free to 9 00:00:23,800 --> 00:00:27,600 enter and I will choose five lucky winners to win those 10 00:00:27,600 --> 00:00:31,100 licenses for more information on how How to participate. 11 00:00:31,100 --> 00:00:35,400 Please check out this URL. Aztec, Legend, o.f / giveaway, 12 00:00:35,700 --> 00:00:38,600 here's the link one more time. Technology, you know, the dev 13 00:00:38,600 --> 00:00:41,800 slash giveaway. Please make sure to participate. 14 00:00:41,900 --> 00:00:45,200 And I wish you all good luck. What I come to realize is that 15 00:00:45,200 --> 00:00:47,400 technology doesn't move that fast. 16 00:00:47,400 --> 00:00:50,100 The fundamentals are roughly the same. 17 00:00:50,200 --> 00:00:53,000 It's the fact that we don't necessarily teach fundamentals. 18 00:00:53,100 --> 00:00:55,500 When you start to focus on the fundamentals, then you don't 19 00:00:55,500 --> 00:00:58,600 mentally get attached to one particular implementation. 20 00:01:03,200 --> 00:01:06,700 Hey everyone. My name is Henry sura, one. 21 00:01:08,100 --> 00:01:10,800 And you're listening to the tekhelet journal. 22 00:01:11,400 --> 00:01:14,500 The show will be bringing you the greatest technical leaders 23 00:01:14,800 --> 00:01:18,400 practitioners and thought leaders in the industry to 24 00:01:18,400 --> 00:01:22,600 discuss about their Journey ideas and practices that we all 25 00:01:22,600 --> 00:01:26,400 can learn and apply to build a highly performing technical team 26 00:01:26,600 --> 00:01:29,200 and to make an impact in your personal work. 27 00:01:29,800 --> 00:01:36,500 So let's dive into our Journal. Hi everyone. 28 00:01:36,500 --> 00:01:38,800 My name is Alyssa from Singapore and I'm currently an 29 00:01:38,800 --> 00:01:41,400 undergraduate studying information systems at Singapore 30 00:01:41,400 --> 00:01:43,900 management University. I've had a great honor to meet 31 00:01:43,900 --> 00:01:46,100 Harry through a mentoring program at school and he 32 00:01:46,100 --> 00:01:49,100 graciously shared with me about this podcast that he's working 33 00:01:49,100 --> 00:01:50,600 on. And I'm so glad he did. 34 00:01:50,900 --> 00:01:53,800 I've definitely gained a lot of insight by listening to all the 35 00:01:53,800 --> 00:01:55,200 experts here. Techne. 36 00:01:55,200 --> 00:01:57,700 General is an eye opener and a great initiative. 37 00:01:57,800 --> 00:01:59,800 There has never been anything quite like it before. 38 00:02:00,100 --> 00:02:03,800 The content and gues brought in by Henry are specially created 39 00:02:03,800 --> 00:02:06,600 to provide a wide diversity. Understanding what tech 40 00:02:06,600 --> 00:02:09,800 leadership and good Tech practices are what I appreciate 41 00:02:09,800 --> 00:02:12,200 most about. This podcast is a mono effort 42 00:02:12,200 --> 00:02:15,500 and attention to detail in the podcast notes, which can be 43 00:02:15,500 --> 00:02:17,700 assessed on Techni journals website. 44 00:02:17,800 --> 00:02:20,400 The transfer was openly share independent films are nicely 45 00:02:20,400 --> 00:02:23,000 structured s even a breakdown on the conversation, highlights are 46 00:02:23,000 --> 00:02:25,300 easy digestible information and not to mention. 47 00:02:25,300 --> 00:02:28,600 What I was brought up during a podcast, be thank God jargon 48 00:02:28,600 --> 00:02:32,200 terminologies or references. I especially enjoyed a podcast 49 00:02:32,200 --> 00:02:35,100 that feature Neha Stephanie Crystal as well as Richard. 50 00:02:35,300 --> 00:02:38,200 And googly eye find a once with women in Tech, especially 51 00:02:38,200 --> 00:02:41,100 inspiring because it motivates me to Aspire to be just like 52 00:02:41,100 --> 00:02:44,400 them, work hard, and to consider practical and meaningful 53 00:02:44,400 --> 00:02:47,500 projects and initiatives to make a text-based about the police. 54 00:02:47,800 --> 00:02:50,300 They're sharing insights to their personal Journey 55 00:02:50,300 --> 00:02:53,700 challenges and how they overcome those obstacles to get to where 56 00:02:53,700 --> 00:02:56,700 they are and advise, the three techniques Kristen definitely 57 00:02:56,700 --> 00:02:59,700 value at the conversation. Thank you, general, practice 58 00:02:59,700 --> 00:03:02,600 self in building and growing Their audience based 59 00:03:02,600 --> 00:03:05,000 organically. So, any form of support would be 60 00:03:05,000 --> 00:03:07,200 greatly. If you like or find benefit in 61 00:03:07,200 --> 00:03:09,700 the work being done, please consider subscribing and 62 00:03:09,700 --> 00:03:12,400 becoming a patron to support writing a podcast. 63 00:03:12,400 --> 00:03:14,700 Like I did. I cannot wait to see the 64 00:03:14,700 --> 00:03:17,300 pockets, grow and flourish Henry, definitely deserves it 65 00:03:17,300 --> 00:03:19,800 all for the amount of work. He has footed. 66 00:03:19,900 --> 00:03:22,800 So yeah, that's all for me. And thank you so much for having 67 00:03:22,800 --> 00:03:24,500 me. Hello, my friend. 68 00:03:24,600 --> 00:03:27,200 Thanks for tuning in. It's really great to be back 69 00:03:27,200 --> 00:03:30,000 here with another new episode of the tech lead, you know, with 70 00:03:30,000 --> 00:03:34,300 me, Ojos Henry Surya with Robin. We just heard from Alyssa one of 71 00:03:34,300 --> 00:03:36,500 my early. Is of this podcast. 72 00:03:36,700 --> 00:03:39,300 Thank you so much for sharing your story with us a Lisa. 73 00:03:39,500 --> 00:03:43,000 I really really appreciate your support and I'm also very happy 74 00:03:43,000 --> 00:03:46,300 to hear that you have benefited so much from the episodes and 75 00:03:46,300 --> 00:03:49,100 the show notes. If a Lisa story is resonating 76 00:03:49,100 --> 00:03:52,200 with you and you would also like to make a contribution to the 77 00:03:52,200 --> 00:03:55,100 show by becoming a patron. Please check out for more 78 00:03:55,100 --> 00:03:58,200 information at technology. You know that Dev slash Patron, 79 00:03:58,600 --> 00:04:01,700 your support will tremendously help me towards achieving a goal 80 00:04:01,700 --> 00:04:03,900 that I'm currently running on the page. 81 00:04:04,300 --> 00:04:06,700 If you haven't joined Any of the technology, you know, social 82 00:04:06,700 --> 00:04:09,800 media channels, I would like to invite you to join us on 83 00:04:09,800 --> 00:04:13,400 LinkedIn Twitter or Instagram and you can find the links to 84 00:04:13,400 --> 00:04:16,300 those channels in the show notes, make sure to also, 85 00:04:16,300 --> 00:04:20,600 subscribe and follow this show on your favorite podcast app in 86 00:04:20,600 --> 00:04:23,500 today's episode. I am so excited to share with 87 00:04:23,500 --> 00:04:25,600 you. My conversation with Kelsey 88 00:04:25,600 --> 00:04:28,900 Hightower. Kelsey needs no introduction. 89 00:04:29,300 --> 00:04:32,600 As he is one of the leading figures in open source, cloud, 90 00:04:32,600 --> 00:04:36,100 computing, and kubernetes. And it's um, One that I look up 91 00:04:36,100 --> 00:04:39,300 to for his thought leadership and contributions to the 92 00:04:39,300 --> 00:04:42,000 community. We started the conversation by 93 00:04:42,000 --> 00:04:44,400 having Kelsey. Share his inspiring career 94 00:04:44,400 --> 00:04:48,100 Journey from where he started at the beginning to where he is now 95 00:04:48,100 --> 00:04:52,200 today at Google Cloud. He then shared his invaluable 96 00:04:52,200 --> 00:04:56,000 advice on how one should learn and develop knowledge in the 97 00:04:56,000 --> 00:04:58,300 current fast. Changing technology, landscape 98 00:04:58,400 --> 00:05:02,700 overcome impostor syndrome and thus be able to succeed in Tech. 99 00:05:03,300 --> 00:05:06,500 We then continue our discussion to This latest technology 100 00:05:06,500 --> 00:05:11,000 updates beat in cloud, sevilla's and communities including his 101 00:05:11,000 --> 00:05:15,300 latest observation and views on micro Services versus monolith. 102 00:05:15,800 --> 00:05:18,800 If you follow Kelsey for quite some time, you might have heard 103 00:05:18,800 --> 00:05:22,300 about his guide, kubernetes the hard way, which you can find in 104 00:05:22,300 --> 00:05:25,300 his GitHub repository, Kelsey shared with me. 105 00:05:25,300 --> 00:05:28,800 The reason why he created such the hard way guide to learn 106 00:05:28,800 --> 00:05:32,400 about a particular technology. And at the same time doing it 107 00:05:32,400 --> 00:05:35,100 publicly. This is definitely an episode. 108 00:05:35,200 --> 00:05:37,800 You don't want to miss, it's jam-packed with knowledge and 109 00:05:37,800 --> 00:05:40,200 wisdom. And I personally learned so much 110 00:05:40,200 --> 00:05:42,300 from this conversation with Kelsey. 111 00:05:42,600 --> 00:05:45,700 I hope that you will enjoy this great episode. 112 00:05:45,800 --> 00:05:47,800 Please. Consider helping the show in the 113 00:05:47,800 --> 00:05:51,600 smallest possible way by leaving me a rating and review on Apple 114 00:05:51,600 --> 00:05:54,700 podcast and other podcast apps that allow you to do. 115 00:05:54,700 --> 00:05:58,600 So, those ratings and reviews are one of the best ways to get 116 00:05:58,600 --> 00:06:02,400 these podcasts to reach more listeners and hopefully the show 117 00:06:02,400 --> 00:06:04,600 gets featured on the podcast platform. 118 00:06:05,300 --> 00:06:09,000 Also looking forward to hearing any comments and feedback on the 119 00:06:09,000 --> 00:06:12,100 social media or you can also directly send to me at 120 00:06:12,100 --> 00:06:14,600 technology. You know, that death / feedback. 121 00:06:14,800 --> 00:06:17,700 So without further Ado, let's get started. 122 00:06:21,300 --> 00:06:23,900 Welcome everyone. So today I have a very special 123 00:06:23,900 --> 00:06:26,900 guest someone that I admire a long time especially for his 124 00:06:26,900 --> 00:06:30,600 technical leadership and also experience in terms of the cloud 125 00:06:30,600 --> 00:06:33,600 and also kubernetes is none other than Kelsey Hightower. 126 00:06:33,700 --> 00:06:36,300 So Kelsey very pleased Have you in the show today? 127 00:06:36,300 --> 00:06:37,700 Welcome to the technique Journal. 128 00:06:37,900 --> 00:06:39,200 Awesome. Thanks for having me. 129 00:06:39,600 --> 00:06:41,300 Kelsey. Maybe for a start. 130 00:06:41,300 --> 00:06:44,000 What are you up to these days? These days. 131 00:06:44,100 --> 00:06:46,700 I spend a lot of my time around the serverless thing. 132 00:06:46,700 --> 00:06:49,400 So I work at Google Cloud as people may know. 133 00:06:49,500 --> 00:06:52,200 And the area that I'm most interested in is around all 134 00:06:52,200 --> 00:06:55,000 these service Technologies, primarily Cloud run. 135 00:06:55,200 --> 00:06:57,700 Most people are familiar with kubernetes and running their 136 00:06:57,700 --> 00:07:00,700 containers, but there's still a lot of friction in managing 137 00:07:00,700 --> 00:07:03,600 clusters and all the complexity that comes with that. 138 00:07:03,700 --> 00:07:07,000 So I'm very interested if we Close the gap on the server. 139 00:07:07,000 --> 00:07:09,200 The side. Can we remove the infrastructure 140 00:07:09,400 --> 00:07:12,400 that keep the majority of the flexibility for running people's 141 00:07:12,400 --> 00:07:15,300 applications at scale. So it's my primary thing that 142 00:07:15,300 --> 00:07:17,900 I'm doing internally at Google on the outside world. 143 00:07:17,900 --> 00:07:20,100 I'm very interested in the security landscape. 144 00:07:20,100 --> 00:07:23,500 So it's been a lot of time with things like spy or which means 145 00:07:23,500 --> 00:07:26,900 one of the open source projects behind spiffy giving identity to 146 00:07:26,900 --> 00:07:29,700 our applications in a way that's portable. 147 00:07:29,700 --> 00:07:32,200 So for people that are interested in Cloud, you know 148 00:07:32,200 --> 00:07:35,000 that there's I am you have an identity for Amazon. 149 00:07:35,200 --> 00:07:36,800 You have an identity for Google Cloud. 150 00:07:36,800 --> 00:07:39,300 You have an identity for Azure, and those things are not 151 00:07:39,300 --> 00:07:42,000 necessarily super easy to make portable. 152 00:07:42,200 --> 00:07:45,800 So this whole concept of spiffy is basically giving people an 153 00:07:45,800 --> 00:07:47,500 identity. You can think of a domain like 154 00:07:47,500 --> 00:07:52,400 example.org and then having your app live at calculator or Foo 155 00:07:52,500 --> 00:07:54,700 and then those things could be passed around and TLS 156 00:07:54,700 --> 00:07:58,300 certificates or drop tokens. So this is really interesting to 157 00:07:58,300 --> 00:08:02,600 have Federated identity across VMS container service and even 158 00:08:02,600 --> 00:08:05,000 other Cloud providers, so it's very interesting. 159 00:08:05,200 --> 00:08:07,700 Haven't heard about that. So is it like a portable service 160 00:08:07,700 --> 00:08:10,500 accounts in that sense in some ways? 161 00:08:10,500 --> 00:08:13,500 I am is a complete package. When you think about I am, not 162 00:08:13,500 --> 00:08:16,800 only do you get an identity. You also get the how it can be 163 00:08:16,800 --> 00:08:18,100 used. And you also get a way to 164 00:08:18,100 --> 00:08:20,300 enforce those things. This take is steel. 165 00:08:20,300 --> 00:08:23,300 For example, most people may be familiar with service mesh. 166 00:08:23,300 --> 00:08:26,100 And when you say service, mesh is steals, one of those projects 167 00:08:26,100 --> 00:08:28,500 that come to mind. And what sto does is allows you 168 00:08:28,508 --> 00:08:31,200 to have a control plane, but that control plane, you can do 169 00:08:31,200 --> 00:08:35,799 things to say at a can talk to Abby and then you need a bit of 170 00:08:35,799 --> 00:08:40,100 enforcement at the lower level. So Envoy is a modern proxy where 171 00:08:40,100 --> 00:08:42,400 all your network traffic and come in and out. 172 00:08:42,400 --> 00:08:46,100 So, what is spiffy fit in? So, we have to tell the system 173 00:08:46,100 --> 00:08:49,500 who is at a, so imagine, you're running a container inside of 174 00:08:49,508 --> 00:08:52,100 kubernetes, and kubernetes will give your container a service 175 00:08:52,100 --> 00:08:53,700 account. We could think about that as 176 00:08:53,708 --> 00:08:56,900 like the root of trust. If you are on a VM, you'll have 177 00:08:56,900 --> 00:08:59,500 a metadata service where you can go and get a token. 178 00:08:59,600 --> 00:09:02,600 Again, another way of ID in yourself, and these are two 179 00:09:02,600 --> 00:09:05,700 different things, what tends to happen, inside of a Service mesh 180 00:09:05,700 --> 00:09:09,200 is you take those trusted identities and something like 181 00:09:09,200 --> 00:09:12,500 spires and open source component, where it can trust 182 00:09:12,500 --> 00:09:15,800 kubernetes, or it can trust Google cloud and you can trade. 183 00:09:15,800 --> 00:09:18,900 Those security accounts for another artifact. 184 00:09:19,000 --> 00:09:20,900 These are called like security documents. 185 00:09:20,900 --> 00:09:23,700 It could be a TLS certificate. So you can do TLS Mutual off 186 00:09:23,700 --> 00:09:27,400 between app a and at b, or it could be a jet token that you 187 00:09:27,400 --> 00:09:30,200 can pass around in the typical HTTP header. 188 00:09:30,200 --> 00:09:33,300 So, now that you have this kind of universal identity, it can 189 00:09:33,300 --> 00:09:35,000 work as head of sto it can work on. 190 00:09:35,100 --> 00:09:38,500 Set another cloud provider or any tool that understand the 191 00:09:38,500 --> 00:09:42,000 stiffy IDs and then you can start to do things like policy. 192 00:09:42,100 --> 00:09:45,400 Now that I know who you are. Maybe you're using an SSL 193 00:09:45,400 --> 00:09:47,400 certificate to authenticate, to me. 194 00:09:47,500 --> 00:09:49,300 I can look in that SSL certificate. 195 00:09:49,300 --> 00:09:51,600 And there's going to be a subject alternative name that 196 00:09:51,600 --> 00:09:55,000 has your spiffy idea is just a string, something super fancy. 197 00:09:55,000 --> 00:09:57,900 And that string will tell me what domain you're in 198 00:09:57,900 --> 00:10:02,200 example.com., And then what your service ID is Foo, I can take 199 00:10:02,200 --> 00:10:05,000 that and then go look up to see. Can you even call? 200 00:10:05,200 --> 00:10:07,200 He's in points. So it's more of a way of 201 00:10:07,200 --> 00:10:10,300 formalizing identity in a Federated way. 202 00:10:10,300 --> 00:10:13,100 That's independent of things like, kubernetes service 203 00:10:13,100 --> 00:10:16,700 accounts or Google cloud service accounts, very interesting 204 00:10:16,700 --> 00:10:18,000 indeed. Thanks for sharing that. 205 00:10:18,000 --> 00:10:21,200 So Kelsey, before we go deep into the technical stuff as 206 00:10:21,200 --> 00:10:23,100 usual. I'd like to ask my guests to 207 00:10:23,100 --> 00:10:25,400 share their courage, any highlighting maybe major 208 00:10:25,400 --> 00:10:28,000 highlights or turning points that are interesting for the 209 00:10:28,000 --> 00:10:30,200 listeners to learn about. So maybe, Kelsey. 210 00:10:30,200 --> 00:10:31,900 Can you share your career Journey? 211 00:10:32,400 --> 00:10:35,000 I've been very fortunate, maybe a couple of weeks ago. 212 00:10:35,100 --> 00:10:36,700 Go. So when did a nice profile 213 00:10:36,700 --> 00:10:39,200 piece, a guy named Tom in the protocol? 214 00:10:39,300 --> 00:10:42,300 So this is the protocol website. If you go there, it's also 215 00:10:42,300 --> 00:10:45,000 pinned to my Twitter profile, but it walks you through my 216 00:10:45,000 --> 00:10:48,400 career trajectory from working at fast food in high school 217 00:10:48,400 --> 00:10:50,700 McDonald's. At maybe the age of 15 all the 218 00:10:50,700 --> 00:10:53,800 way to where I am now and Google for those that haven't read the 219 00:10:53,800 --> 00:10:55,500 article. The biggest turning point for 220 00:10:55,500 --> 00:10:57,500 me. Number one is like many people 221 00:10:57,500 --> 00:10:59,100 listening. I'm self-taught. 222 00:10:59,200 --> 00:11:02,600 I remember, just buying books, on Unix and learning python a 223 00:11:02,600 --> 00:11:04,900 little bit on my own even though we say self-taught. 224 00:11:05,200 --> 00:11:08,200 Our own actually, we were taught by the authors of those books 225 00:11:08,300 --> 00:11:12,100 and doing a lot of self-study. So, no college background. 226 00:11:12,100 --> 00:11:15,000 I really just got off the ground just doing certifications and I 227 00:11:15,000 --> 00:11:18,800 tell most people that was my start into Tech just getting 228 00:11:18,800 --> 00:11:21,100 certifications. There was a few turning points. 229 00:11:21,100 --> 00:11:24,700 There was a time where I have my own small computer store in a 230 00:11:24,708 --> 00:11:27,000 small city, right outside of Atlanta Georgia. 231 00:11:27,100 --> 00:11:29,900 And from there. I've met a lot of customers did 232 00:11:29,900 --> 00:11:33,200 a lot of Windows support built PCS inside of the computer 233 00:11:33,200 --> 00:11:35,000 store. Maid service call. 234 00:11:35,100 --> 00:11:36,800 Calls. And if we were to fast forward, 235 00:11:36,800 --> 00:11:40,300 a lot of my early career is around system administration 236 00:11:40,300 --> 00:11:43,900 change Windows deploying software watching monitors and 237 00:11:43,900 --> 00:11:46,800 trying to resolve issues Zoom a little further out. 238 00:11:46,800 --> 00:11:49,000 A lot of my experience starts to become more development. 239 00:11:49,000 --> 00:11:52,200 Experience, writing code, automation tools and some apps 240 00:11:52,200 --> 00:11:54,100 that would even go on to run in production. 241 00:11:54,200 --> 00:11:56,600 And then there's this other Turning Point around, open 242 00:11:56,600 --> 00:11:59,200 source and public speaking around 2012. 243 00:11:59,200 --> 00:12:02,400 I ended up working at Puppet Labs, which is one of the first 244 00:12:02,400 --> 00:12:05,000 open source container or configuration. 245 00:12:05,200 --> 00:12:09,000 It tools for managing servers. This is right around the Arab 246 00:12:09,000 --> 00:12:12,800 devops this idea that developers and operations folks with work a 247 00:12:12,800 --> 00:12:16,200 little bit closer together and infrastructure as code was born. 248 00:12:16,300 --> 00:12:17,900 And that was a right around the time. 249 00:12:17,900 --> 00:12:20,800 I started doing a lot more public speaking at meetups and 250 00:12:20,800 --> 00:12:24,300 larger conferences that kind of helped me identify. 251 00:12:24,300 --> 00:12:26,900 My second set of skills, which is teaching people. 252 00:12:26,900 --> 00:12:29,700 So instead of just Building Technology and shipping things 253 00:12:29,700 --> 00:12:33,100 teaching other people how to do. So, I think those are the major 254 00:12:33,100 --> 00:12:36,100 turning points in my career. That Kind of lands me where I am 255 00:12:36,100 --> 00:12:38,100 today. Yeah, I read that piece of story 256 00:12:38,100 --> 00:12:39,800 as well. It's really inspirational. 257 00:12:39,800 --> 00:12:42,100 I would say, looking back reading your article. 258 00:12:42,100 --> 00:12:44,500 How do you feel reaching your career so far? 259 00:12:45,000 --> 00:12:47,100 It can be good to hear other people. 260 00:12:47,100 --> 00:12:48,900 Tell your story through their eyes. 261 00:12:48,900 --> 00:12:51,900 One thing that was nice about that particular post or article 262 00:12:51,900 --> 00:12:54,800 was the fact that they took the time to interview people that 263 00:12:54,800 --> 00:12:58,100 I've crossed paths with over my life and let them tell that part 264 00:12:58,100 --> 00:13:00,700 of the story. I know how I viewed that story 265 00:13:00,700 --> 00:13:03,400 but watching the other people even though I know them and some 266 00:13:03,400 --> 00:13:06,600 people I've only met once. But just watching them, recount 267 00:13:06,600 --> 00:13:10,100 those stories and Scenic put in that timeline with some context 268 00:13:10,100 --> 00:13:12,100 around it. It was also like reading and 269 00:13:12,100 --> 00:13:14,900 learning about someone that I've never met either. 270 00:13:14,900 --> 00:13:17,100 It was flattering nonetheless, but it was also nice to see 271 00:13:17,100 --> 00:13:20,600 someone recap my life in a way that I can digest as an 272 00:13:20,600 --> 00:13:23,100 outsider. Yeah, interesting indeed Kelsey 273 00:13:23,100 --> 00:13:26,500 like one of the major phrase in the article saying that there's 274 00:13:26,500 --> 00:13:29,900 just no way for a guy like you be able to succeed in the tech 275 00:13:30,000 --> 00:13:33,200 that represents a lot of effort and probably a lot of things 276 00:13:33,200 --> 00:13:34,900 that it got involved into your career. 277 00:13:35,100 --> 00:13:36,800 Or to be where you are at this moment. 278 00:13:36,800 --> 00:13:39,600 And one of the things that I see, for example, is that you 279 00:13:39,600 --> 00:13:41,700 are problem, the underrepresented groups in 280 00:13:41,700 --> 00:13:44,200 technology or so these days, there are a lot of people from 281 00:13:44,200 --> 00:13:47,000 those kind of groups. Also trying to break through in 282 00:13:47,000 --> 00:13:50,000 the technology landscape in the technology communities in the 283 00:13:50,000 --> 00:13:52,300 technology career from your point of view. 284 00:13:52,300 --> 00:13:55,800 What are some of your maybe advices, or maybe even tips on 285 00:13:55,800 --> 00:13:58,100 how to break those kind of barrier? 286 00:13:58,100 --> 00:14:00,700 Especially for these under-represented groups? 287 00:14:00,700 --> 00:14:02,700 Because we can learn probably from your journey. 288 00:14:03,100 --> 00:14:04,900 Yeah, so think about tech it's warm. 289 00:14:05,100 --> 00:14:08,600 Industries, I think on the positive note, where typically 290 00:14:08,600 --> 00:14:13,400 skills are enough to get you to succeed typically or should be 291 00:14:13,400 --> 00:14:16,500 because in many situations a lot of this technology is so new. 292 00:14:16,500 --> 00:14:20,000 That if people only try to hire people with phds, it will be 293 00:14:20,000 --> 00:14:24,000 hard for them to be relevant because there is no great Ph.D 294 00:14:24,000 --> 00:14:26,200 program for things like kubernetes or some of the 295 00:14:26,200 --> 00:14:29,500 software development practices. We use today in Industry. 296 00:14:29,600 --> 00:14:31,700 So that's good news that you don't necessarily require 297 00:14:31,700 --> 00:14:33,700 credentials to be successful in Tech. 298 00:14:33,800 --> 00:14:36,600 Now some of the barriers Is that can be challenging in every 299 00:14:36,600 --> 00:14:38,800 country is different, right? When you think about globally, 300 00:14:38,800 --> 00:14:42,900 every country has local social issues that make it harder for 301 00:14:42,900 --> 00:14:45,800 some groups to participate than others. 302 00:14:45,800 --> 00:14:48,700 Maybe it's not appropriate to assign all of those problems to 303 00:14:48,700 --> 00:14:52,500 the tech field, but they're exaggerated inside of tech 304 00:14:52,500 --> 00:14:54,600 because of the social things that are around them. 305 00:14:54,700 --> 00:14:57,000 So for me coming from an underrepresented group, I'm 306 00:14:57,000 --> 00:14:59,700 considered black or African-American and there's 307 00:14:59,700 --> 00:15:02,200 lots of biases in this country that I live in, right? 308 00:15:02,200 --> 00:15:04,700 Some people may look at me and say there's no way you know what 309 00:15:04,700 --> 00:15:07,300 you're I mean, there's no way you can be technical, maybe you 310 00:15:07,300 --> 00:15:08,800 should be playing sports or something. 311 00:15:08,900 --> 00:15:10,700 And so that presents a challenge meaning. 312 00:15:10,800 --> 00:15:14,200 If people look at you that way, it may be harder to get a job or 313 00:15:14,200 --> 00:15:16,900 even if you get the job. It may be hard to work on 314 00:15:16,900 --> 00:15:19,400 complex projects. You need to skill up and level 315 00:15:19,400 --> 00:15:20,400 up. So what happens? 316 00:15:20,400 --> 00:15:23,800 Then you now have to take on a little bit more responsibility 317 00:15:23,900 --> 00:15:28,000 of finding those opportunities holding onto those opportunities 318 00:15:28,000 --> 00:15:31,200 and then being able to execute and then outside of that in 319 00:15:31,200 --> 00:15:32,900 general. It's always amazing to me that 320 00:15:32,900 --> 00:15:34,900 in technology, lots of copies, just water. 321 00:15:35,000 --> 00:15:38,800 I hire people who know everything on day one, even for 322 00:15:38,800 --> 00:15:40,900 a beginner role. You want someone that has five 323 00:15:40,900 --> 00:15:43,900 years of Technology, x, five years of Technology, Y. 324 00:15:43,900 --> 00:15:48,000 And we just don't do a good job in our field of teaching people 325 00:15:48,000 --> 00:15:51,000 continuously, whether they're new or they've been around for a 326 00:15:51,000 --> 00:15:53,200 while. It's always this friction of. 327 00:15:53,400 --> 00:15:56,000 We expect you to know everything and we don't really have any 328 00:15:56,000 --> 00:15:59,600 formalized training to continue to grow skills. 329 00:15:59,600 --> 00:16:01,700 There's other Industries like being an electrician. 330 00:16:01,700 --> 00:16:04,900 They have a whole progress. You go from like a journeyman to 331 00:16:05,100 --> 00:16:07,400 It's new you pair up with someone who does know what 332 00:16:07,400 --> 00:16:10,000 they're doing or have been doing it longer and allows you to 333 00:16:10,000 --> 00:16:13,700 continue to improve over time. And there's an expectation that 334 00:16:13,700 --> 00:16:16,100 you can pair and have something more official. 335 00:16:16,200 --> 00:16:18,300 So those are some of the challenges in Tech that I think 336 00:16:18,300 --> 00:16:21,200 a lot of people have to deal with but I also feel that to be 337 00:16:21,200 --> 00:16:24,900 able to overcome those things by having access to the knowledge. 338 00:16:24,900 --> 00:16:27,900 So that's one thing I think Tech has done well, which is making a 339 00:16:27,908 --> 00:16:30,500 lot of this knowledge and tools accessible. 340 00:16:30,500 --> 00:16:32,800 Whether that's free and open-source the knowledge that 341 00:16:32,800 --> 00:16:35,500 we see in blog posts and in books, but The other thing we 342 00:16:35,500 --> 00:16:38,300 haven't done. Well, I think is make the rolls 343 00:16:38,300 --> 00:16:41,000 the opportunities to leverage those skills. 344 00:16:41,100 --> 00:16:44,100 We haven't made those as accessible as we have the 345 00:16:44,100 --> 00:16:46,300 information. It's very interesting that you 346 00:16:46,300 --> 00:16:48,400 pointed out about these continuous training. 347 00:16:48,400 --> 00:16:51,700 So I didn't think of it that way initially, but now that you said 348 00:16:51,700 --> 00:16:54,900 it, I think it's true as well, and especially these days. 349 00:16:54,900 --> 00:16:57,600 People want to hire people who know a lot of stuff. 350 00:16:57,600 --> 00:16:59,600 Could it be also? Because of that technology, 351 00:16:59,600 --> 00:17:03,400 moves so fast and they just can't probably spend enough time 352 00:17:03,400 --> 00:17:06,400 to invest time in people. You upscale themselves and they 353 00:17:06,400 --> 00:17:09,099 just want to have everything starting from the day. 354 00:17:09,099 --> 00:17:10,800 They join, and then start running straight away. 355 00:17:10,800 --> 00:17:12,200 Could it be? Because of the pace of the 356 00:17:12,200 --> 00:17:15,200 technology itself, doesn't allow them to actually have the time 357 00:17:15,200 --> 00:17:17,900 to invest for training. You know what, I used to think 358 00:17:17,900 --> 00:17:20,500 that but what I've come to realize is that technology 359 00:17:20,500 --> 00:17:24,500 doesn't move that fast. The fundamentals are roughly the 360 00:17:24,500 --> 00:17:26,099 same. Like when people say, kubernetes 361 00:17:26,099 --> 00:17:29,700 is new, all the fundamentals. I can probably recall. 10 years 362 00:17:29,700 --> 00:17:31,500 ago. The workflows may be different. 363 00:17:31,600 --> 00:17:34,800 Instead of copying a binary onto a Linux server and start. 364 00:17:35,000 --> 00:17:37,200 Earn it by hand. There's a much bigger system 365 00:17:37,200 --> 00:17:39,200 around kubernetes that does that for us. 366 00:17:39,200 --> 00:17:42,700 So the concept of scheduling isn't new technology that dates 367 00:17:42,700 --> 00:17:45,800 back, 40 to 50-plus years, this idea of scheduling. 368 00:17:45,900 --> 00:17:47,700 It's just a how we're using the fundamental. 369 00:17:47,700 --> 00:17:50,700 So for anyone that has fundamentals, you look at these 370 00:17:50,700 --> 00:17:52,100 new systems and you'll say, okay. 371 00:17:52,100 --> 00:17:55,300 They're more workflow engines. They're more about composing, 372 00:17:55,300 --> 00:17:59,000 the fundamentals into a system with a design purpose. 373 00:17:59,200 --> 00:18:02,700 So, I think when people look at technology shifts their bigger 374 00:18:02,700 --> 00:18:05,700 in the minds of people who don't, The fundamentals and 375 00:18:05,700 --> 00:18:08,800 there's nothing wrong with that. What I'm saying is it's the fact 376 00:18:08,800 --> 00:18:11,000 that we don't necessarily teach fundamentals. 377 00:18:11,100 --> 00:18:13,900 When you go to a job. You hear people say I'm a Linux 378 00:18:13,900 --> 00:18:17,900 system administrator or I'm a Oracle DBA, not really that 379 00:18:17,900 --> 00:18:21,000 you're a database engineer. If you are focused on databases, 380 00:18:21,000 --> 00:18:24,300 then you would focus more on how data structures are held in 381 00:18:24,300 --> 00:18:27,100 memory. How the sequel execution engine 382 00:18:27,100 --> 00:18:30,400 works, how the storage is laid out on this because those 383 00:18:30,400 --> 00:18:34,100 fundamentals apply to postgres. They apply to db2. 384 00:18:34,200 --> 00:18:37,200 They also Apply to things like Cloud spanner, where you have a 385 00:18:37,200 --> 00:18:40,100 multi-region, replicate a SQL database. 386 00:18:40,200 --> 00:18:42,500 When you start to focus on the fundamentals, then you don't 387 00:18:42,500 --> 00:18:45,600 mentally get attached to one particular implementation. 388 00:18:45,700 --> 00:18:48,400 So, that's what makes things seem impossible is like, oh, I 389 00:18:48,400 --> 00:18:50,400 have to learn this implementation that 390 00:18:50,400 --> 00:18:53,500 implementation and that implementation and then people 391 00:18:53,500 --> 00:18:55,200 feel like they need to start from scratch. 392 00:18:55,300 --> 00:18:57,600 The way I look at new technologies just says, okay, 393 00:18:57,600 --> 00:19:00,300 what fundamentals is this thing building on top of? 394 00:19:00,400 --> 00:19:01,800 And once I can see those, it's okay. 395 00:19:01,800 --> 00:19:04,800 Now, I know that I know 80% of what's going on here. 396 00:19:05,200 --> 00:19:07,700 Now, let me go fill in a twenty percent which is their 397 00:19:07,700 --> 00:19:10,900 configuration, their workflows. In your opinion. 398 00:19:11,000 --> 00:19:14,300 What are some of the building blocks of the fundamentals that 399 00:19:14,300 --> 00:19:16,500 people in the tech? Should know about? 400 00:19:16,700 --> 00:19:19,400 Let's talk about networking. So you'll see people in Tech to 401 00:19:19,400 --> 00:19:22,300 say, hey, we're going to be doing service mesh and I say why 402 00:19:22,300 --> 00:19:24,500 or what is the service mesh doing for you? 403 00:19:24,600 --> 00:19:27,500 And then you might see a long pause, because it's just, it's 404 00:19:27,500 --> 00:19:30,800 Theo, is going to make it easy for me to secure my 405 00:19:30,800 --> 00:19:33,600 microservices, and that's straight off the website. 406 00:19:33,700 --> 00:19:37,000 Now, the fundamentals in is Is at the very bottom there still 407 00:19:37,000 --> 00:19:40,700 networking. So IP addresses subnets routes 408 00:19:40,700 --> 00:19:46,000 L3 versus L7 L3 is going to be in some ways to simplify this. 409 00:19:46,000 --> 00:19:48,900 How does one packet get to another destination? 410 00:19:48,900 --> 00:19:52,000 May be outside of the core Network and at L7 now we start 411 00:19:52,000 --> 00:19:55,100 to get into the protocols. We're all used to like HTTP 412 00:19:55,100 --> 00:19:58,900 where we think about posting a request to summoned Point. 413 00:19:58,900 --> 00:20:01,200 That's great. So, when we think about securing 414 00:20:01,200 --> 00:20:03,600 those layers, you're going to do different things for each layer. 415 00:20:03,600 --> 00:20:06,300 So, at L7, we're going To be talking about things like TLS 416 00:20:06,300 --> 00:20:08,100 certificates. SSL. 417 00:20:08,200 --> 00:20:10,800 We're going to do things like we want security to help us with 418 00:20:10,800 --> 00:20:13,600 deciding if you're trying to make a request that this path. 419 00:20:13,600 --> 00:20:16,500 How do I identify you? And then how do I reject you in 420 00:20:16,500 --> 00:20:19,600 a way that makes sense to are seeing you back up, 500 or do I 421 00:20:19,608 --> 00:20:22,000 send you back a 403? Those are things that you just 422 00:20:22,000 --> 00:20:24,500 know at the networking, tier based on their protocols that 423 00:20:24,500 --> 00:20:26,200 you're dealing with? But guess what? 424 00:20:26,300 --> 00:20:29,900 It's still IP addresses. They're still routes TLS is not 425 00:20:29,900 --> 00:20:32,800 necessarily brand-new. So doing TLS Mutual off to 426 00:20:32,800 --> 00:20:36,300 encrypt between your two. And then give them an identity 427 00:20:36,300 --> 00:20:38,200 that you can actually apply policies on. 428 00:20:38,300 --> 00:20:41,600 These are fundamentals that were true 20, 30 years ago. 429 00:20:41,700 --> 00:20:44,900 I think in that case make sure you learn about authentication 430 00:20:44,900 --> 00:20:47,800 and authorization and while those are different if you 431 00:20:47,808 --> 00:20:50,200 understand those fundamentals, then when you look at something 432 00:20:50,200 --> 00:20:53,500 like is Theo or service mesh, you can look at how they try to 433 00:20:53,500 --> 00:20:56,400 represent those Concepts and their own systems. 434 00:20:56,600 --> 00:20:58,000 Yeah. I think the yellow message is 435 00:20:58,000 --> 00:21:00,000 definitely resonated with me as well. 436 00:21:00,100 --> 00:21:03,200 So focusing on the fundamentals, they tend not to change 437 00:21:03,200 --> 00:21:06,200 especially for a long years. We can go back, not just for 438 00:21:06,200 --> 00:21:09,200 infrastructure but also application design like design 439 00:21:09,200 --> 00:21:12,100 patterns and also integration patterns and things like that. 440 00:21:12,100 --> 00:21:14,300 They tend not to change so much but the tools and the 441 00:21:14,300 --> 00:21:17,300 implementations seemed a plenty these days with all the 442 00:21:17,300 --> 00:21:19,800 Frameworks and the language is popping up here and there. 443 00:21:20,000 --> 00:21:23,800 So another aspect of breaking through in Tech, I feel is that 444 00:21:23,800 --> 00:21:27,000 there's this thing called impostor syndrome, especially as 445 00:21:27,000 --> 00:21:30,300 a junior person coming to the tech industry with so many 446 00:21:30,300 --> 00:21:33,600 technologies that are available these days either open source, 447 00:21:33,600 --> 00:21:36,200 either cloud. Also, our pride three. 448 00:21:36,400 --> 00:21:38,800 So there seems to be insurmountable amount of 449 00:21:38,800 --> 00:21:41,900 technologies that someone needs to understand first of all, or 450 00:21:41,900 --> 00:21:45,000 know the general principle and also understand about the 451 00:21:45,000 --> 00:21:46,800 implementation of it. The details. 452 00:21:47,000 --> 00:21:50,400 These things tend to put someone down in the first place in the 453 00:21:50,400 --> 00:21:52,200 sense that, oh, there are so many things. 454 00:21:52,200 --> 00:21:54,600 I'm probably not good enough to learn all these things. 455 00:21:54,700 --> 00:21:58,500 So what are the lobby suggestion or advice from you of dealing 456 00:21:58,500 --> 00:22:01,100 with this imposter syndrome? I think there's probably way 457 00:22:01,100 --> 00:22:03,500 smarter people have written about this in general. 458 00:22:03,500 --> 00:22:06,900 So I'll try to just speak from My own experience at some point 459 00:22:06,900 --> 00:22:09,400 in my career. I realized that I didn't need to 460 00:22:09,400 --> 00:22:12,200 be the best in every piece of technology. 461 00:22:12,200 --> 00:22:13,600 I was going to be responsible with. 462 00:22:13,700 --> 00:22:17,300 I knew I needed to understand it to the degree that my job 463 00:22:17,300 --> 00:22:19,600 required. And if I thought it was going to 464 00:22:19,600 --> 00:22:22,500 make sense. I could go a bit deeper than the 465 00:22:22,500 --> 00:22:25,400 job required as an investment in myself. 466 00:22:25,400 --> 00:22:28,700 That was the foundation of my career that I at some point 467 00:22:28,700 --> 00:22:30,300 arrived to. So, what does that mean? 468 00:22:30,300 --> 00:22:34,000 That means that I can decide what technologies are important 469 00:22:34,000 --> 00:22:36,700 to me? My skill set that I want to be 470 00:22:36,700 --> 00:22:39,100 able to put on the market or Leverett for the things I want 471 00:22:39,100 --> 00:22:40,700 to do it. Mel is hot right. 472 00:22:40,700 --> 00:22:42,900 Now. I have very little interest in 473 00:22:42,900 --> 00:22:45,600 learning tensorflow right now. Someone can save your missing 474 00:22:45,600 --> 00:22:47,400 out. That's the hottest job prospect 475 00:22:47,400 --> 00:22:49,600 in the world Etc. But that's not for me. 476 00:22:49,600 --> 00:22:52,000 Maybe I'll touch it every once in a while just to see what's 477 00:22:52,000 --> 00:22:54,900 going on there. Maybe do a Hello World type of 478 00:22:54,900 --> 00:22:58,700 tutorial and then I'm okay saying that it is not my area of 479 00:22:58,700 --> 00:23:00,500 expertise. There's only so much time in the 480 00:23:00,500 --> 00:23:02,600 day. Now the areas where I am 481 00:23:02,600 --> 00:23:06,500 interested I take on the A of going as deep as I can. 482 00:23:06,500 --> 00:23:09,100 For example, I like to go programming language, but I'm 483 00:23:09,100 --> 00:23:12,600 familiar about how it parses a syntax unfamiliar about the 484 00:23:12,600 --> 00:23:15,500 surrounding ecosystem. I understand how go routines 485 00:23:15,500 --> 00:23:18,200 work, understand some of the trade-offs you make in the go 486 00:23:18,200 --> 00:23:20,500 programming language when you're making system calls to the 487 00:23:20,500 --> 00:23:23,400 kernel because I also deal with things like containers and 488 00:23:23,400 --> 00:23:25,400 containers definitely get low level. 489 00:23:25,400 --> 00:23:29,300 And so for me, I'm very patient with saying I'm investing in 490 00:23:29,300 --> 00:23:32,600 myself and I'll pick and choose the right things to make that 491 00:23:32,600 --> 00:23:34,700 investment in. And in terms of imposter. 492 00:23:35,000 --> 00:23:36,900 Drum, I think there's two people who feel this. 493 00:23:36,900 --> 00:23:39,500 There are people who are truly in postures. 494 00:23:39,600 --> 00:23:42,100 Meaning you're trying to be something, you're not. 495 00:23:42,200 --> 00:23:44,800 And whenever you do that, that can also make you feel very 496 00:23:44,800 --> 00:23:47,400 uncomfortable because you're pretending to be something. 497 00:23:47,400 --> 00:23:50,200 You're not around people who might be and that's not 498 00:23:50,200 --> 00:23:52,300 necessarily A person who knows the most. 499 00:23:52,300 --> 00:23:55,000 But if you try to force yourself to be one of the people who 500 00:23:55,000 --> 00:23:57,600 knows everything, then you're going to trap yourself in this 501 00:23:57,600 --> 00:23:59,300 feeling. I've resigned to say, you know 502 00:23:59,300 --> 00:24:01,800 what, it's okay to learn in public since I don't know 503 00:24:01,800 --> 00:24:04,400 everything. I'm comfortable with asking 504 00:24:04,400 --> 00:24:06,000 questions. Ian's and I get it. 505 00:24:06,000 --> 00:24:08,700 Sometimes you're going to get penalized for not knowing 506 00:24:08,700 --> 00:24:10,300 everything. There's some companies who are 507 00:24:10,300 --> 00:24:13,600 some organizations or teams, who practice a very unhealthy 508 00:24:13,600 --> 00:24:15,900 practice of anyone who asks a question. 509 00:24:16,000 --> 00:24:18,600 We're just going to believe that they're dumb and no longer ask 510 00:24:18,600 --> 00:24:20,700 them to do anything. That is just unhealthy. 511 00:24:20,700 --> 00:24:22,200 That's what I was talking about earlier. 512 00:24:22,200 --> 00:24:25,200 We don't have a formalized set of training to say we are going 513 00:24:25,200 --> 00:24:27,300 to invest in people continuously. 514 00:24:27,400 --> 00:24:30,600 So for me I decided I'm not going to pretend, I know 515 00:24:30,600 --> 00:24:32,600 everything. So therefore I'm not worried 516 00:24:32,600 --> 00:24:35,400 about being an imposter and therefore I don't Worry about 517 00:24:35,400 --> 00:24:37,300 trying to be the best at everything. 518 00:24:37,400 --> 00:24:40,400 So I Stay Focus in the areas that I am interested in and take 519 00:24:40,400 --> 00:24:44,000 the responsibility just to get slightly better day over day 520 00:24:44,000 --> 00:24:46,700 year over year. So in the first place, knowing 521 00:24:46,700 --> 00:24:49,700 what you want needs a certain kind of conviction for some 522 00:24:49,700 --> 00:24:52,500 people, this tends to be easy while you got at. 523 00:24:52,500 --> 00:24:54,700 For example, I'm good in application development. 524 00:24:54,700 --> 00:24:57,900 So I know what I need to focus on, maybe programming language, 525 00:24:57,900 --> 00:25:01,200 maybe some Frameworks, but for some people, especially those 526 00:25:01,200 --> 00:25:03,900 who come from non Tech background, they might not have 527 00:25:03,900 --> 00:25:06,400 such a conviction. They might just see from the 528 00:25:06,408 --> 00:25:09,400 news or see from the job. Korea's what are some of the hot 529 00:25:09,400 --> 00:25:11,300 things to do. So, is there any things? 530 00:25:11,300 --> 00:25:14,200 Maybe how should you advise people to have that kind of 531 00:25:14,200 --> 00:25:16,600 conviction? If I think back to high school? 532 00:25:16,600 --> 00:25:18,300 I remember you had elective classes. 533 00:25:18,300 --> 00:25:22,000 So outside of math science, may be English, you had to take 534 00:25:22,000 --> 00:25:24,500 electives and this could be things like home Mac where you 535 00:25:24,500 --> 00:25:27,200 learn how to cook and maybe so close. 536 00:25:27,200 --> 00:25:30,400 I check on Mike by the way, there's technology class their 537 00:25:30,400 --> 00:25:32,000 Sports. There's all kind of things you 538 00:25:32,000 --> 00:25:33,600 can do in that. Elective in the point of the 539 00:25:33,600 --> 00:25:37,300 elective is to Those kids two more things than they would 540 00:25:37,300 --> 00:25:38,800 probably naturally pick on their own. 541 00:25:38,800 --> 00:25:40,800 So it's about exposure. So, I think when people are 542 00:25:40,800 --> 00:25:43,600 starting their career or making a career transition, I think 543 00:25:43,600 --> 00:25:46,600 it's healthy to try a little of everything because there's no 544 00:25:46,600 --> 00:25:49,600 way for you, to know what you're hearing from other people is 545 00:25:49,600 --> 00:25:52,300 things that may have worked for them, but it may not necessarily 546 00:25:52,300 --> 00:25:54,400 work from you. So I think one thing is hey, 547 00:25:54,400 --> 00:25:57,800 maybe try tech support. Maybe you like helping people in 548 00:25:57,800 --> 00:26:00,700 a way that allows us to support people go into and don't think 549 00:26:00,700 --> 00:26:03,600 one role is inferior to another. I think that's another mistake 550 00:26:03,600 --> 00:26:06,100 people make. I in my career and tech support 551 00:26:06,100 --> 00:26:09,200 and even within tech support, you can go super deep and I 552 00:26:09,208 --> 00:26:11,100 think tech support is a great path to site. 553 00:26:11,100 --> 00:26:14,600 Reliability engineering as free or even software development, 554 00:26:14,600 --> 00:26:17,000 especially if you can understand how to troubleshoot and debug 555 00:26:17,000 --> 00:26:18,400 these systems. The next area. 556 00:26:18,400 --> 00:26:22,300 I think people have to look at here is once you try a little 557 00:26:22,300 --> 00:26:26,300 bit of everything and something resonates with you that might be 558 00:26:26,300 --> 00:26:28,100 a period of your life. We always talk about the 559 00:26:28,100 --> 00:26:30,900 t-shaped engineer. So you might say, hey, I'm 560 00:26:30,900 --> 00:26:33,100 really liking working for some reason. 561 00:26:33,500 --> 00:26:35,400 It motivates me to want to Deeper. 562 00:26:35,700 --> 00:26:38,200 He know what? For the next 125 years. 563 00:26:38,400 --> 00:26:40,700 Maybe you want to become a network engineer. 564 00:26:40,800 --> 00:26:42,800 Go get all your certifications work. 565 00:26:42,800 --> 00:26:44,800 In an industry where you can actually improve your skills 566 00:26:44,800 --> 00:26:46,600 around networking. And guess what? 567 00:26:46,600 --> 00:26:49,200 It's okay to switch. Maybe you go from network 568 00:26:49,200 --> 00:26:53,500 engineer to someone who write code for networking systems and 569 00:26:53,500 --> 00:26:56,300 now you're shifting to software engineering and maybe you like 570 00:26:56,300 --> 00:26:59,500 python that's another opportunity to go super deep on 571 00:26:59,500 --> 00:27:03,800 Python and then maybe after 10-15 years you step back you've 572 00:27:03,800 --> 00:27:07,400 gone D and Several areas, and now you have the top of the T. 573 00:27:07,400 --> 00:27:10,600 You have the horizontal set of skills, and maybe at that time 574 00:27:10,600 --> 00:27:13,300 you're super deep, and maybe you go back to network engineering 575 00:27:13,300 --> 00:27:15,900 where you combine all your skills and go deeper than you 576 00:27:15,900 --> 00:27:18,300 were before. Thanks for sharing that Kelsey. 577 00:27:18,300 --> 00:27:20,500 I think there are few things that I could pick up here. 578 00:27:20,600 --> 00:27:23,200 So, first of all, is that? If you don't know what you're 579 00:27:23,200 --> 00:27:26,700 good at all, you don't know what to pursue, try a little of 580 00:27:26,700 --> 00:27:29,200 everything. And also don't think of one role 581 00:27:29,200 --> 00:27:31,900 as inferior to the other. This applies not just to roll 582 00:27:31,900 --> 00:27:35,100 but maybe also to Technologies. And also, when you Find 583 00:27:35,100 --> 00:27:38,100 something that you are resonating with, you can go deep 584 00:27:38,100 --> 00:27:40,200 and the last is that it's okay to switch. 585 00:27:40,200 --> 00:27:43,200 You don't have to self identify yourself with a particular 586 00:27:43,200 --> 00:27:46,500 technology or particular role. So at one point in time in your 587 00:27:46,500 --> 00:27:49,100 life, if you feel like comfortable switching to another 588 00:27:49,100 --> 00:27:51,300 role, I think it's okay to do so as well. 589 00:27:51,500 --> 00:27:54,900 So Kelsey you have been working in the cloud landscape for the 590 00:27:54,900 --> 00:27:56,300 past. I don't know how many years. 591 00:27:56,300 --> 00:27:58,800 It's a long time. Now, what are some of the 592 00:27:58,800 --> 00:28:01,400 possibilities in the future when you talk about Cloud? 593 00:28:01,700 --> 00:28:03,300 Yeah. Crowded interesting cloud is 594 00:28:03,300 --> 00:28:06,000 infrastructure for most people. And if you think about 595 00:28:06,000 --> 00:28:09,500 infrastructure, what's possible, if you think about airports, 596 00:28:09,500 --> 00:28:13,200 then it becomes possible to travel other parts of the world 597 00:28:13,200 --> 00:28:15,700 in a more accessible way. And for a lot of people more 598 00:28:15,700 --> 00:28:18,100 affordable. A lot of times infrastructure is 599 00:28:18,100 --> 00:28:22,000 going to enable us to do things. We can't do by ourselves or with 600 00:28:22,000 --> 00:28:25,000 limited set of resources. So when I think about cloud and 601 00:28:25,000 --> 00:28:27,300 we talk about public Cloud, there's a lot of computing 602 00:28:27,300 --> 00:28:31,000 tasks, where maybe you want to start an online e-commerce site 603 00:28:31,000 --> 00:28:34,600 and these days, people expect that side to be available in 604 00:28:34,600 --> 00:28:36,800 all. The country's High availability. 605 00:28:36,800 --> 00:28:40,200 It's up all the time and they want to be able to use any form 606 00:28:40,200 --> 00:28:43,000 of payment that they want. And the goal of the cloud is to 607 00:28:43,000 --> 00:28:45,300 enable that as seamless as possible. 608 00:28:45,500 --> 00:28:48,100 So, when we think about the cloud, I think we've got a good 609 00:28:48,100 --> 00:28:51,900 lock on infrastructure, components, like databases and 610 00:28:51,900 --> 00:28:55,300 compute networking, some security layers. 611 00:28:55,500 --> 00:28:58,300 So when we think about the friction that's left, is we're 612 00:28:58,300 --> 00:29:02,100 asking people to understand all of those things before, they can 613 00:29:02,100 --> 00:29:04,500 go out and build something. And that's the opportunity for 614 00:29:04,500 --> 00:29:06,500 the Cloud. So this is why I'm excited about 615 00:29:06,500 --> 00:29:10,100 things like serverless, where we try to abstract away as much of 616 00:29:10,100 --> 00:29:13,500 that underlying infrastructure as possible to get people closer 617 00:29:13,500 --> 00:29:17,500 to, here's my idea. Here's the code that powers, it 618 00:29:17,600 --> 00:29:20,000 run it for me. We have a lot of work to do in 619 00:29:20,000 --> 00:29:21,900 terms of user experience there, right? 620 00:29:21,900 --> 00:29:25,300 We still exposed to many configuration options, when most 621 00:29:25,300 --> 00:29:27,100 people are just after the best practice. 622 00:29:27,100 --> 00:29:30,100 So if you're going to create a database you may not understand 623 00:29:30,100 --> 00:29:33,200 all of those hundred options that are available on cloud SQL, 624 00:29:33,300 --> 00:29:35,900 what you want, is it? Where's the button that says, 625 00:29:35,900 --> 00:29:37,500 best practice for what I'm doing? 626 00:29:37,700 --> 00:29:39,200 That's what most people want to do. 627 00:29:39,300 --> 00:29:41,800 So I think cloud should be something where you can bring 628 00:29:41,800 --> 00:29:43,900 your ideas. And when you have an advanced 629 00:29:43,900 --> 00:29:46,700 use case, of course, you can always drop down to the lower 630 00:29:46,700 --> 00:29:50,200 level infrastructure and kind of build a platform that you need. 631 00:29:50,200 --> 00:29:53,800 But as Cloud providers, we should be trying to make the 80% 632 00:29:53,800 --> 00:29:57,100 use case as secure and easy to adopt as possible. 633 00:29:57,500 --> 00:30:00,900 So when adopting Cloud these days, people also tend to talk 634 00:30:00,900 --> 00:30:02,500 about being Cloud. Native. 635 00:30:02,500 --> 00:30:06,200 So can you explain to us? What is Cloud native basically, 636 00:30:06,600 --> 00:30:08,900 that's a fun one. Some people would say cloud, 637 00:30:08,900 --> 00:30:13,400 native is 100% in the cloud and leveraging, the patterns that 638 00:30:13,400 --> 00:30:16,500 were born in the cloud. I like to simplify this a little 639 00:30:16,500 --> 00:30:18,200 bit. If you think about the patterns 640 00:30:18,200 --> 00:30:22,700 around observability having structured logs in a way that 641 00:30:22,700 --> 00:30:25,200 instead of logging that there's just an error, you're going to 642 00:30:25,208 --> 00:30:27,100 log that. With some context, this 643 00:30:27,100 --> 00:30:30,300 particular package or service is having this error. 644 00:30:30,400 --> 00:30:32,000 Here's the client that called it. 645 00:30:32,100 --> 00:30:34,700 Here's what I was doing and to give you more insight. 646 00:30:34,800 --> 00:30:36,400 To go along with that log message. 647 00:30:36,400 --> 00:30:40,000 We may even put in a request ID and that request ID could have 648 00:30:40,000 --> 00:30:43,800 been generated from the client or the hdp load balancer that 649 00:30:43,800 --> 00:30:46,600 will sit in front of me and I can then take that request 650 00:30:46,600 --> 00:30:50,700 context and put it into HTTP traces so you can know how much 651 00:30:50,700 --> 00:30:53,700 latency between the various Services because you're thinking 652 00:30:53,700 --> 00:30:55,800 about these distributed systems. You're going to need a lot more 653 00:30:55,800 --> 00:30:58,100 observability than you have before, right? 654 00:30:58,100 --> 00:30:59,800 Because these things are a lot more complex. 655 00:30:59,800 --> 00:31:01,600 Again. This is a pattern born in the 656 00:31:01,600 --> 00:31:04,600 cloud where we've made it really easy to get machines. 657 00:31:04,700 --> 00:31:07,400 Across the globe. So in order to make those things 658 00:31:07,400 --> 00:31:11,300 easier to troubleshoot, we need things like observability, and 659 00:31:11,300 --> 00:31:14,300 not just logging plaintext to some file. 660 00:31:14,400 --> 00:31:16,100 We need a different kind of pattern. 661 00:31:16,300 --> 00:31:18,800 And as you look around, the whole Cloud native set of 662 00:31:18,800 --> 00:31:20,400 patterns, right? So when you say cloud native, I 663 00:31:20,408 --> 00:31:23,000 think of patterns, think about health checks, instead of 664 00:31:23,000 --> 00:31:25,900 running some bash script to see if application is healthy, that 665 00:31:25,900 --> 00:31:28,500 won't necessarily scale to the cloud model. 666 00:31:28,500 --> 00:31:30,900 And I'm not talking about just a bunch of machines. 667 00:31:31,000 --> 00:31:34,400 I'm talking about having things across multiple zones or regions 668 00:31:34,400 --> 00:31:37,600 or That could go away at any time because in early Cloud, 669 00:31:37,600 --> 00:31:40,700 there was no guarantee your virtual machine or run forever. 670 00:31:40,800 --> 00:31:43,000 So you need it better patterns around Health checking. 671 00:31:43,000 --> 00:31:46,300 So you had some other tool that can come by and check the health 672 00:31:46,300 --> 00:31:49,300 of all you're in points. And if one were to go away, it 673 00:31:49,300 --> 00:31:52,600 would then be able to automatically provision another. 674 00:31:52,800 --> 00:31:55,500 So to me, it's a collection of patterns that were born in the 675 00:31:55,500 --> 00:31:57,800 cloud. I think, most people would do a 676 00:31:57,800 --> 00:32:01,000 good job of deciding what your those patterns benefit them the 677 00:32:01,000 --> 00:32:03,600 most, because you can actually apply some of those patterns 678 00:32:03,600 --> 00:32:06,500 even outside of Of the cloud, maybe you're running a couple of 679 00:32:06,500 --> 00:32:10,000 servers in your own data center. You might still be able to 680 00:32:10,000 --> 00:32:12,300 benefit from things like standardized, help, checks and 681 00:32:12,300 --> 00:32:14,100 metrics. And then the last thing I'll say 682 00:32:14,100 --> 00:32:16,200 here is that a lot of these Cloud native patterns. 683 00:32:16,200 --> 00:32:19,700 Now are no longer ideas that you find in our white paper there. 684 00:32:19,700 --> 00:32:23,100 Now open source projects that you can find in this CN CF. 685 00:32:23,100 --> 00:32:26,500 So the cloud native Computing Foundation is a home to a lot of 686 00:32:26,500 --> 00:32:28,900 these open source projects with the maintainers and the 687 00:32:28,900 --> 00:32:31,900 communities can come together and collaborate and push a lot 688 00:32:31,900 --> 00:32:34,600 of these standards forward. I do hear some people. 689 00:32:34,800 --> 00:32:38,300 Then say like, for example, Cloud native is if I use all the 690 00:32:38,300 --> 00:32:41,300 particular Cloud providers products, so, then, I'm Cloud 691 00:32:41,300 --> 00:32:43,500 native. Is that a misconception? 692 00:32:43,600 --> 00:32:45,500 Or is that something that is true? 693 00:32:45,500 --> 00:32:47,800 In what sense? Maybe you have a take on that. 694 00:32:48,100 --> 00:32:51,100 If you use all the cloud providers products, I don't 695 00:32:51,100 --> 00:32:53,700 think that automatically qualifies you for cloud native. 696 00:32:53,700 --> 00:32:56,000 I'll give you an example. Let's say you have an app that 697 00:32:56,000 --> 00:32:59,300 just runs on the set of virtual machines, behind a cloud load, 698 00:32:59,300 --> 00:33:01,000 balancer. Well, you Coulda did that on 699 00:33:01,000 --> 00:33:03,100 Prim, you could do that with being where you could do that 700 00:33:03,100 --> 00:33:04,600 with openstack. You don't. 701 00:33:04,700 --> 00:33:08,500 Need to adopt any of the cloud native patterns to make that 702 00:33:08,500 --> 00:33:10,900 work and typically that's referred to as the lift and 703 00:33:10,900 --> 00:33:14,000 Chip, take what you were doing 10, 20 years ago and just do it 704 00:33:14,000 --> 00:33:16,400 in the cloud. And the cloud supports that via 705 00:33:16,400 --> 00:33:20,000 infrastructure-as-a-service is that to me isn't necessarily 706 00:33:20,000 --> 00:33:22,700 Cloud native. Now, there's a lot of value into 707 00:33:22,700 --> 00:33:26,200 leveraging cloud services, and I think nothing's wrong with that. 708 00:33:26,300 --> 00:33:28,900 But I think when we say cloud native, we're basically talking 709 00:33:28,900 --> 00:33:32,900 about a world that allows you to effectively leverage those cloud 710 00:33:32,900 --> 00:33:37,300 services in terms of resilience. See, reliability, observability 711 00:33:37,600 --> 00:33:40,600 and to get all of those things. This is where we start to 712 00:33:40,600 --> 00:33:43,600 delineate, or distinguish. What's a cloud native, set of 713 00:33:43,600 --> 00:33:46,700 patterns that go along with that and in many ways, when I really 714 00:33:46,700 --> 00:33:50,200 think about it, a lot of these Cloud native ideas or concepts 715 00:33:50,200 --> 00:33:52,100 are really at the application tier. 716 00:33:52,100 --> 00:33:55,400 So, for the first time, we're now focusing on the relationship 717 00:33:55,400 --> 00:33:57,900 between the application and the infrastructure. 718 00:33:58,000 --> 00:34:00,300 And that's where a lot of those patterns are to be found. 719 00:34:00,800 --> 00:34:04,100 So you mention about patents and a lot of people associate 720 00:34:04,100 --> 00:34:06,200 clowning. Beef with the 12 Factor 721 00:34:06,200 --> 00:34:08,500 application design or principles. 722 00:34:08,500 --> 00:34:11,800 Do you think that 12 factor is a good representation of all the 723 00:34:11,800 --> 00:34:14,300 patterns? How, this might be an unpopular 724 00:34:14,300 --> 00:34:19,100 opinion, but my answer is no, I think 12 Factor was a great 725 00:34:19,100 --> 00:34:23,199 precursor to allow you to practice some of the patterns 726 00:34:23,199 --> 00:34:26,199 that you find in Cloud native. So, a lot of people have come 727 00:34:26,199 --> 00:34:29,199 from this world, the past, like, Heroku and Heroku. 728 00:34:29,199 --> 00:34:31,100 Was this kind of infrastructure or pass? 729 00:34:31,100 --> 00:34:33,300 That would say, look, giving your source code, but here's 730 00:34:33,300 --> 00:34:37,100 some restrictions in Were to be able to run your application on 731 00:34:37,100 --> 00:34:40,600 any of our servers and a way that's portable for us. 732 00:34:40,699 --> 00:34:43,699 We're not going to allow you to do things like have a local 733 00:34:43,699 --> 00:34:46,000 volume for storage. We're not going to be dealing 734 00:34:46,000 --> 00:34:48,699 with configuration files and copying files all over the 735 00:34:48,699 --> 00:34:49,900 place. So now you're going to have to 736 00:34:49,900 --> 00:34:52,400 take things like in an environment variable and a lot 737 00:34:52,400 --> 00:34:54,300 of times. These are really nice ways to 738 00:34:54,300 --> 00:34:56,800 make an app a little bit more portable because you're no 739 00:34:56,800 --> 00:35:00,400 longer requiring a file system. You're being very explicit about 740 00:35:00,400 --> 00:35:03,300 State, you make sure that if you do have persistent data, you put 741 00:35:03,300 --> 00:35:06,600 in a persistent data. Base explicitly and you also 742 00:35:06,600 --> 00:35:09,100 build your apps in ways that are easier to start up, that can be 743 00:35:09,100 --> 00:35:10,900 rebuilt. So, I think a lot of those 744 00:35:10,900 --> 00:35:14,300 patterns or just really good software engineering patterns, 745 00:35:14,300 --> 00:35:18,900 that allowed us to actually, run applications at scale and a 746 00:35:18,900 --> 00:35:22,900 platform such as Heroku or app engine or Cloud Foundry. 747 00:35:23,100 --> 00:35:24,200 So, I think it was great for those. 748 00:35:24,200 --> 00:35:27,100 Remember those panels came out what 10 15 years ago, nothing 749 00:35:27,100 --> 00:35:30,100 wrong with those, but then we get you a slice of some of these 750 00:35:30,100 --> 00:35:32,400 Cloud native patterns. And the reason why I think they 751 00:35:32,400 --> 00:35:34,900 apply just a little, is because we're talking about Out 752 00:35:34,900 --> 00:35:38,800 documenting and formalizing practices over the years. 753 00:35:38,900 --> 00:35:42,000 So 12 factors a good place to start but here's the thing, you 754 00:35:42,000 --> 00:35:45,000 can have Cloud native applications that are not 12 755 00:35:45,000 --> 00:35:47,900 Factor applications. Like Cloud native could be 756 00:35:47,900 --> 00:35:51,500 things like Kafka or it could be something like, at CD at CD, 757 00:35:51,500 --> 00:35:55,000 definitely uses storage. It definitely doesn't use 758 00:35:55,000 --> 00:35:57,600 environment variable. So it probably violates maybe 759 00:35:57,600 --> 00:36:01,000 four or five of the 12 Factor principles, but that doesn't 760 00:36:01,000 --> 00:36:03,700 mean that it's not Cloud. Native Cloud native is not about 761 00:36:03,700 --> 00:36:06,300 stateless, only. I think stateless applications 762 00:36:06,300 --> 00:36:08,800 are a little bit easier to adopt some of the cloud native 763 00:36:08,800 --> 00:36:11,600 practices, but I don't think we should exclude stateful 764 00:36:11,600 --> 00:36:14,900 applications because they're not 12 factor that the totally makes 765 00:36:14,900 --> 00:36:15,900 sense. Kelsey. 766 00:36:15,900 --> 00:36:18,600 You mentioned that you have been dealing a lot with several has 767 00:36:18,600 --> 00:36:21,400 Technologies these days. So what do you see the trends 768 00:36:21,400 --> 00:36:22,900 coming in? The Civil has area? 769 00:36:23,000 --> 00:36:25,600 Are there some technologies or maybe things that everyone 770 00:36:25,600 --> 00:36:27,900 should know about? When I first learned about 771 00:36:27,900 --> 00:36:31,800 surface, I want to through maybe AWS Lambda functions as a 772 00:36:31,800 --> 00:36:34,000 service changing events together. 773 00:36:34,000 --> 00:36:37,300 And these were So engines that we lay on top, that was a really 774 00:36:37,300 --> 00:36:38,800 nice way to think about this problem. 775 00:36:38,800 --> 00:36:41,200 It wasn't necessarily a brand new way of thinking about this 776 00:36:41,200 --> 00:36:43,900 problem, because a lot of people have tried of have done 777 00:36:43,900 --> 00:36:47,300 successfully, event-driven architectures in the past, but 778 00:36:47,300 --> 00:36:50,100 when I hear serverless, I think about the operational model that 779 00:36:50,100 --> 00:36:54,100 comes with it, which is, how do I reduce as much friction as 780 00:36:54,100 --> 00:36:55,900 possible. And you think about the word 781 00:36:55,900 --> 00:36:57,600 servlets, we're talking about a couple of things. 782 00:36:57,600 --> 00:36:58,500 One. We're talking about the 783 00:36:58,500 --> 00:37:01,900 application Level, the concept of a server, if you're going to 784 00:37:01,900 --> 00:37:04,500 write a web app you typically in bed. 785 00:37:04,600 --> 00:37:08,100 A web server that you get from your framework and that web 786 00:37:08,100 --> 00:37:10,300 server has to buy into an IP address. 787 00:37:10,300 --> 00:37:13,600 It has to think about logging. If you get to the lower levels, 788 00:37:13,600 --> 00:37:15,700 you have to think about some of the connection details and 789 00:37:15,700 --> 00:37:18,400 timeouts. There's a lot that goes into 790 00:37:18,400 --> 00:37:21,800 running the server, even outside of your application logic. 791 00:37:21,900 --> 00:37:24,700 And then when you add in the underlying server, that needs to 792 00:37:24,700 --> 00:37:27,400 be patched, it needs to be updated and he's a network. 793 00:37:27,600 --> 00:37:30,000 There's a lot of friction there. So if you look at Lambda, it 794 00:37:30,000 --> 00:37:33,300 removes all of those things are attempts to and what you're left 795 00:37:33,300 --> 00:37:36,800 with is a function. Business logic will be invoked 796 00:37:36,800 --> 00:37:40,100 whenever there's a data packet or something that you need to 797 00:37:40,100 --> 00:37:42,900 request or an event. And what I think we're trying to 798 00:37:42,900 --> 00:37:46,900 do now is say, hey can we not give the same operational model 799 00:37:46,900 --> 00:37:50,600 to normal containers where you do decide that you want to 800 00:37:50,600 --> 00:37:53,400 package in your own web server or some other protocol? 801 00:37:53,400 --> 00:37:55,800 That makes sense for you. So I think one thing we're 802 00:37:55,800 --> 00:37:58,100 trying to do now is on the cloud provider side. 803 00:37:58,100 --> 00:38:01,100 We're asking ourselves tougher questions and trying to meet a 804 00:38:01,100 --> 00:38:05,100 higher bar of usability. So what I do, I want to do is 805 00:38:05,100 --> 00:38:06,500 tell you to rewrite your application. 806 00:38:06,500 --> 00:38:09,400 The perfect state would be keep your application as it is. 807 00:38:09,600 --> 00:38:12,700 Now if you do certain things like enable health checks or 808 00:38:12,800 --> 00:38:14,900 support metrics, it will definitely help you because 809 00:38:14,900 --> 00:38:17,700 there will be no server for you to log into to troubleshoot. 810 00:38:17,700 --> 00:38:19,000 So you may want to add those things. 811 00:38:19,000 --> 00:38:21,900 But if you don't, I still want to give you the same operational 812 00:38:21,900 --> 00:38:23,300 model. Meaning, I want to be able to 813 00:38:23,308 --> 00:38:26,000 scale down to zero. So when you're not using this 814 00:38:26,000 --> 00:38:29,600 application may be in, Deborah QA, then you don't pay for it. 815 00:38:29,700 --> 00:38:31,700 If you want to run over multiple regions. 816 00:38:31,700 --> 00:38:33,900 You don't have to learn about all of this multi-region. 817 00:38:33,900 --> 00:38:35,900 Networking. And it gets very complex at 818 00:38:35,900 --> 00:38:38,800 those layers and then I can also promise you a bit of security 819 00:38:38,800 --> 00:38:41,200 because I can keep the server's patched underneath you. 820 00:38:41,300 --> 00:38:43,500 If the contract becomes a little bit clearer. 821 00:38:43,600 --> 00:38:46,000 So I think what people should be paying attention to is think 822 00:38:46,000 --> 00:38:48,600 about all of your favorite tools and services whether they're 823 00:38:48,600 --> 00:38:51,800 open source databases like postgres in MySQL, or if you're 824 00:38:51,800 --> 00:38:55,400 writing containers, regardless of the framework Ruby on Rails 825 00:38:55,400 --> 00:38:57,300 or spring boot in the Java World. 826 00:38:57,300 --> 00:39:00,200 Imagine just being able to tell the cloud provider, you run 827 00:39:00,200 --> 00:39:03,200 those systems for me. And now just give you the code 828 00:39:03,200 --> 00:39:06,000 and configuration. I want to leverage with them. 829 00:39:06,300 --> 00:39:08,700 What do you think the current state of civilization? 830 00:39:08,700 --> 00:39:11,500 Is it good enough for people to use and bet there are 831 00:39:11,500 --> 00:39:14,900 Technologies on it, or is it something that still needs a lot 832 00:39:14,900 --> 00:39:17,800 of improvements? I think it's super mature 833 00:39:17,800 --> 00:39:20,000 depending on what you want to do for certain workloads. 834 00:39:20,000 --> 00:39:24,100 So if you're doing event-driven architectures Lambda from AWS 835 00:39:24,100 --> 00:39:27,500 Cloud functions from Google Cloud, those are super mature, 836 00:39:27,500 --> 00:39:30,600 and tons of people are already using those things in production 837 00:39:30,600 --> 00:39:33,600 at pretty decent scales. So this means that you've 838 00:39:33,600 --> 00:39:36,700 written code. Executes fast understands how to 839 00:39:36,707 --> 00:39:39,000 deal with events and the ecosystem around. 840 00:39:39,000 --> 00:39:42,800 That is also fairly mature. A lot of the data Brokers are 841 00:39:42,800 --> 00:39:46,700 doing a good job of retries and giving you visibility into how 842 00:39:46,700 --> 00:39:49,900 the execution flow is going. And then there's configuration 843 00:39:49,900 --> 00:39:52,300 tools that help you to deploy those kind of systems. 844 00:39:52,300 --> 00:39:55,800 So I think for event-driven architectures is fairly mature, 845 00:39:55,800 --> 00:39:59,000 especially when you're being very explicit about State on the 846 00:39:59,000 --> 00:40:01,800 container ecosystem side. I think our goal should be. 847 00:40:01,800 --> 00:40:04,500 Can we provide the equivalent experience? 848 00:40:04,500 --> 00:40:06,700 Is that you get with a virtual machine, for example, with a 849 00:40:06,700 --> 00:40:09,400 virtual machine, you can mount a data volume. 850 00:40:09,400 --> 00:40:12,200 You can do em FS. You can do machine learning with 851 00:40:12,200 --> 00:40:14,800 the GPU. You can do all of these things. 852 00:40:14,800 --> 00:40:17,500 When someone gives you a virtual machine and the serverless work 853 00:40:17,500 --> 00:40:19,700 today. If I think about Google Cloud, 854 00:40:19,700 --> 00:40:22,800 run we can do about 70% of the things. 855 00:40:22,800 --> 00:40:26,300 I just talked about, we could do NFS, we can run any Docker 856 00:40:26,300 --> 00:40:28,800 container. You can use any library that you 857 00:40:28,800 --> 00:40:30,500 want. But there's some challenges 858 00:40:30,500 --> 00:40:33,900 around doing things that maybe you want to run Docker inside of 859 00:40:33,908 --> 00:40:36,400 that thing. Today, that won't be necessary. 860 00:40:36,400 --> 00:40:39,700 Easy to do, bi-directional to your PC is also something that's 861 00:40:39,700 --> 00:40:41,200 coming down. So you have to think about the 862 00:40:41,200 --> 00:40:43,900 protocol that you use. We support websockets into your 863 00:40:43,900 --> 00:40:48,100 PC, but we may not support every single protocol that you're used 864 00:40:48,100 --> 00:40:50,100 to when you're dealing with a virtual machine. 865 00:40:50,300 --> 00:40:53,500 We got to close that Gap. And once that Gap is closed, 866 00:40:53,500 --> 00:40:56,800 then it becomes a trade-off. How much control do I want on 867 00:40:56,800 --> 00:41:00,100 the underlying infrastructure and not about what you can and 868 00:41:00,100 --> 00:41:02,700 can't run. So we got work to do this. 869 00:41:02,700 --> 00:41:05,900 Some other Technology support from Outrun upcoming in the 870 00:41:05,900 --> 00:41:09,000 civiles area. So when I say serverless, now, 871 00:41:09,000 --> 00:41:11,500 I'm thinking about the operational model serve. 872 00:41:11,500 --> 00:41:15,100 This can be applied to more of our data stores and databases. 873 00:41:15,100 --> 00:41:18,400 Typically, they'll have a free tier, they'll scale, 20 pay for 874 00:41:18,400 --> 00:41:20,100 use. We also have things around 875 00:41:20,100 --> 00:41:22,100 workflows and for building things. 876 00:41:22,100 --> 00:41:24,200 There's Cloud. Build a lot of people. 877 00:41:24,200 --> 00:41:26,900 Like, I don't run Docker on my machine anymore, as it may be 878 00:41:26,900 --> 00:41:29,900 two and a half years ago. I just don't run Docker locally. 879 00:41:30,000 --> 00:41:32,700 I just use cloud build, so I still keep dr. 880 00:41:32,700 --> 00:41:35,600 Files, but whenever I want to build I just have a build script 881 00:41:35,600 --> 00:41:38,700 that just says g-cloud submit to the cloud build system. 882 00:41:38,900 --> 00:41:41,700 And then there's a container that's living in some registry 883 00:41:41,700 --> 00:41:43,600 in the cloud. And then I can actually complete 884 00:41:43,600 --> 00:41:46,300 the rest of my workflow. That to me is another concept of 885 00:41:46,300 --> 00:41:48,600 service. Just more managed Services where 886 00:41:48,600 --> 00:41:50,500 I don't really have to do all of this work. 887 00:41:50,600 --> 00:41:52,300 And we're trying to do that with control plane. 888 00:41:52,300 --> 00:41:55,400 So, if you're thinking about service mesh today, instead of 889 00:41:55,400 --> 00:41:58,000 your clusters, a lot of people will install sto and all of its 890 00:41:58,000 --> 00:42:00,400 control plane components. That one thing we're trying to 891 00:42:00,400 --> 00:42:03,300 do with tools, like traffic director is say, hey, what are 892 00:42:03,300 --> 00:42:06,300 we were able to centralize This open source control plane, same 893 00:42:06,300 --> 00:42:10,600 open protocol support standard sto and Envoy proxies, even 894 00:42:10,600 --> 00:42:13,400 bring your own but then that just runs if a more managed 895 00:42:13,400 --> 00:42:17,000 environment to me that can also be seen as a form of serverless. 896 00:42:17,300 --> 00:42:20,800 So I think for us to goals going forward is Imagine taking as 897 00:42:20,800 --> 00:42:24,700 much of our managed Services as we can and giving people the 898 00:42:24,700 --> 00:42:28,800 option to leverage a cost model. That's paper, use today with a 899 00:42:28,800 --> 00:42:32,300 VM you created in your pay by the hour, but we want a world 900 00:42:32,300 --> 00:42:34,400 where you only pay when that thing is doing. 901 00:42:34,600 --> 00:42:37,200 Something. So, that's a goal that we have, 902 00:42:37,200 --> 00:42:40,300 and that could be Cloud SQL, that can be postgres, that can 903 00:42:40,300 --> 00:42:42,600 be Cloud spanner. That could be Memory store. 904 00:42:42,900 --> 00:42:44,200 I just want to see it everywhere. 905 00:42:44,500 --> 00:42:47,100 Interesting, take indeed. So, Kelsey, let's switch to 906 00:42:47,100 --> 00:42:50,100 another topic, which you also a passionate about, which is about 907 00:42:50,100 --> 00:42:53,600 monolith fascist microservices. So I want to go back into a 908 00:42:53,600 --> 00:42:57,000 tweet that you posted somewhere around late 2017. 909 00:42:57,200 --> 00:42:59,600 You wrote something that in 2020 prediction. 910 00:42:59,600 --> 00:43:02,500 The monolithic applications will be back in style. 911 00:43:02,600 --> 00:43:04,900 What do you see about this? Action. 912 00:43:05,200 --> 00:43:08,100 Yeah, that was more of an observation because people had 913 00:43:08,100 --> 00:43:11,200 already been going back or some people have never left. 914 00:43:11,200 --> 00:43:13,000 I have an example. I wouldn't say it's a good 915 00:43:13,000 --> 00:43:16,000 example, but it's an example is to use this service that we 916 00:43:16,000 --> 00:43:18,700 talked about a few times here and it had a few components, it 917 00:43:18,700 --> 00:43:22,100 had what we call the mixer. This is where you would send all 918 00:43:22,100 --> 00:43:25,100 your metrics and logs and the mixture would decide. 919 00:43:25,100 --> 00:43:27,100 There's a good a data dog or stackdriver. 920 00:43:27,100 --> 00:43:28,600 It was pluggable and configurable. 921 00:43:28,800 --> 00:43:31,700 We had a thing called the pilot. It was an independent service 922 00:43:31,700 --> 00:43:33,800 that will integrate with things like kubernetes. 923 00:43:34,000 --> 00:43:37,200 We had Like the galley, there's just like all of these small 924 00:43:37,200 --> 00:43:41,000 little Services, then when you start sto it was also 925 00:43:41,000 --> 00:43:43,400 leveraging. Microservices itself to help you 926 00:43:43,400 --> 00:43:45,900 manage your microservices, but guess what, the biggest 927 00:43:45,900 --> 00:43:49,200 complaint we had was it's really hard to deploy all of these 928 00:43:49,200 --> 00:43:53,300 components configure, all these components and most people 929 00:43:53,300 --> 00:43:55,400 wanted something, a little easier to manage. 930 00:43:55,400 --> 00:43:57,100 So guess what? The solution was the solution 931 00:43:57,100 --> 00:43:59,500 was to take all of these components and make them to a 932 00:43:59,500 --> 00:44:02,000 single service. So they went the other way. 933 00:44:02,100 --> 00:44:05,800 They went from microservices to a Monolith and this is not a 934 00:44:05,808 --> 00:44:07,900 knock against them. It was a good idea because you 935 00:44:07,900 --> 00:44:11,200 still can deploy the individual components if you ever need to 936 00:44:11,200 --> 00:44:15,400 scale, but the fact that they did that to simplify things. 937 00:44:15,600 --> 00:44:17,700 I've seen this come up a lot. If you look at some of the 938 00:44:17,700 --> 00:44:20,500 engineering blog post from, I won't mention all the companies 939 00:44:20,500 --> 00:44:22,900 names, but they've done these blog posts with they say, hey, 940 00:44:22,900 --> 00:44:26,400 we used to have 20,000 services and we noticed that we were 941 00:44:26,400 --> 00:44:30,500 spending, a lot of our CPU serializing, Json or tracking 942 00:44:30,500 --> 00:44:34,000 metrics or applying security policies instead of doing actual 943 00:44:34,000 --> 00:44:36,000 work. So instead of doing that, we're 944 00:44:36,000 --> 00:44:40,200 going to go from 20,000, back to 2000 and things are faster. 945 00:44:40,300 --> 00:44:43,600 Things are easier to manage things are easier to understand. 946 00:44:43,800 --> 00:44:46,800 And I think in those cases it's not that microservices are bad. 947 00:44:46,900 --> 00:44:49,600 It's just that when some people were leveraging this pattern 948 00:44:49,600 --> 00:44:53,700 unnecessarily or too far, it became unmaintained, Belen might 949 00:44:53,700 --> 00:44:56,400 even make performance worse. It's the trade-off that you 950 00:44:56,400 --> 00:44:59,200 should make when you're doing it for organizational purposes. 951 00:44:59,200 --> 00:45:01,700 So if you're at Google, you might have a Gmail service. 952 00:45:01,700 --> 00:45:04,400 And even within the Gmail team there might be. 953 00:45:04,500 --> 00:45:06,300 Don't services, but that's where I see it. 954 00:45:06,300 --> 00:45:09,100 Being super effective when it helps you align, your 955 00:45:09,100 --> 00:45:11,700 organization around areas of specialty. 956 00:45:11,900 --> 00:45:15,400 But even then in the monolithic world, you can achieve a lot of 957 00:45:15,400 --> 00:45:18,600 these things with a monolith. If you're just a solo developer, 958 00:45:18,700 --> 00:45:20,700 you're probably better off just writing the bottle. 959 00:45:20,700 --> 00:45:23,900 If the start, if you're in a small team and maybe have some 960 00:45:23,900 --> 00:45:27,000 good engineering practices, like writing modules that then get 961 00:45:27,000 --> 00:45:30,800 compiled together as a. Deployable again, monoliths may 962 00:45:30,800 --> 00:45:33,900 help you go very far in the last thing, I'll say on this is for 963 00:45:33,900 --> 00:45:37,400 most Intents and purposes, a large majority of Facebook could 964 00:45:37,400 --> 00:45:40,800 be considered a big model in the same is probably true of GitHub. 965 00:45:40,800 --> 00:45:43,700 I'm not saying they don't have any microservices, I'm saying 966 00:45:43,700 --> 00:45:47,000 that you can get real far without them interesting. 967 00:45:47,000 --> 00:45:50,200 Take, actually, I also heard about the sto project how they 968 00:45:50,200 --> 00:45:52,600 started as a micro services with all the components that you 969 00:45:52,600 --> 00:45:54,700 mentioned. Just now, and with the recent 970 00:45:54,700 --> 00:45:57,500 version release a, go back into a monolithic design. 971 00:45:57,600 --> 00:46:00,400 So, certainly, there's some wisdom on why they're doing it 972 00:46:00,400 --> 00:46:02,200 that way. Although some people now are 973 00:46:02,200 --> 00:46:06,000 still trying to adopt, Services for their architectures. 974 00:46:06,000 --> 00:46:08,800 So it seems almost like the de facto standard. 975 00:46:08,800 --> 00:46:11,000 I would say in the industry, like oh, I want to build 976 00:46:11,000 --> 00:46:12,800 something. Let's start with microservices. 977 00:46:12,800 --> 00:46:16,000 So what's your take on that? Is there any rule of thumb for 978 00:46:16,000 --> 00:46:18,900 you to decide when to use micro service or monolith? 979 00:46:19,200 --> 00:46:21,200 Yeah. I think I would probably start 980 00:46:21,200 --> 00:46:22,800 with the monolith whenever I can. 981 00:46:22,800 --> 00:46:24,900 But remember we're not talking about a monolith with no 982 00:46:24,900 --> 00:46:27,300 engineering discipline. I think when people say monolith 983 00:46:27,300 --> 00:46:31,600 there, really describing in some cases, not all in some cases, a 984 00:46:31,607 --> 00:46:34,100 lack of engineering discipline and standards. 985 00:46:34,500 --> 00:46:37,600 A lot of times, if you have modular code based, meaning all 986 00:46:37,600 --> 00:46:41,300 the services are in their own repositories, and they have 987 00:46:41,300 --> 00:46:45,100 their own workflow and release schedules and integration tests 988 00:46:45,100 --> 00:46:47,700 with the rest of the other services at a package level. 989 00:46:47,700 --> 00:46:49,300 We're not talking about deployables yet. 990 00:46:49,300 --> 00:46:52,200 We're still just talking about modular packages, just like the 991 00:46:52,200 --> 00:46:55,400 standard library and maybe different libraries, you use to 992 00:46:55,400 --> 00:46:58,100 create your own Services when those things are modular. 993 00:46:58,100 --> 00:47:00,400 And there's clear ownership and good testing. 994 00:47:00,400 --> 00:47:02,600 Then you can make a decision. Do you deploy? 995 00:47:02,600 --> 00:47:04,300 All of those things individually? 996 00:47:04,400 --> 00:47:08,200 Or do you import them all into the same main binary? 997 00:47:08,200 --> 00:47:10,400 And then wire them up with some routes? 998 00:47:10,400 --> 00:47:14,300 And that can actually be as maintainable or scalable from 999 00:47:14,300 --> 00:47:17,800 Team concept as having independent, Deployable. 1000 00:47:17,800 --> 00:47:20,900 So, when you separate those two, I think you can say, hey, even 1001 00:47:20,900 --> 00:47:23,600 if we start with a monolith, we're still going to adopt some 1002 00:47:23,600 --> 00:47:26,400 of the practices that you find in a micro Services 1003 00:47:26,400 --> 00:47:28,800 architecture. We're going to split our 1004 00:47:28,800 --> 00:47:30,200 services into different repositories. 1005 00:47:30,200 --> 00:47:33,300 We're going to have clean interfaces for invoking. 1006 00:47:33,300 --> 00:47:36,900 Those I've seen Go as far as making a monolith and then 1007 00:47:36,900 --> 00:47:40,000 having all the services have to call each other service through 1008 00:47:40,000 --> 00:47:42,100 localhost. You can see that in some of the 1009 00:47:42,100 --> 00:47:45,400 old JBoss world or some of those big application Frameworks. 1010 00:47:45,500 --> 00:47:48,900 Everything is a web request even when you're deployed together in 1011 00:47:48,900 --> 00:47:51,400 a single binary. So you don't necessarily have to 1012 00:47:51,400 --> 00:47:54,300 get that kind of discipline in isolation, just from 1013 00:47:54,300 --> 00:47:56,500 microservices. And then if you develop this way 1014 00:47:56,500 --> 00:47:59,200 from the beginning, when the time comes to split one of those 1015 00:47:59,200 --> 00:48:01,900 components out, you'll be able to do it very naturally because 1016 00:48:01,900 --> 00:48:04,300 the boundaries will be very clear about how. 1017 00:48:04,400 --> 00:48:06,000 You do it. The last thing I'll say here is 1018 00:48:06,000 --> 00:48:08,600 for people that are struggling. Like I really want to do 1019 00:48:08,600 --> 00:48:11,600 microservices for my resume, or I want to make my LinkedIn 1020 00:48:11,600 --> 00:48:14,200 profile look really good. If you have a model of today, 1021 00:48:14,200 --> 00:48:16,600 one thing I always highlight to the team that's thinking about 1022 00:48:16,600 --> 00:48:20,000 making this transition. I say I guarantee you you're 1023 00:48:20,000 --> 00:48:23,000 already doing microservices today and I say no no Kelsey. 1024 00:48:23,000 --> 00:48:24,500 We're doing monologues. Trust me. 1025 00:48:24,500 --> 00:48:27,000 I wrote the code. I know my company better than 1026 00:48:27,000 --> 00:48:27,900 you do. That's okay. 1027 00:48:28,000 --> 00:48:31,100 How do you do DNS? They say my library calls the 1028 00:48:31,107 --> 00:48:33,000 DNS server based on this configuration. 1029 00:48:33,000 --> 00:48:36,200 Why are you asking that's your Service, right domain name 1030 00:48:36,200 --> 00:48:37,600 service. It runs over here. 1031 00:48:37,600 --> 00:48:41,200 So usually a separate binary and it does one particular thing and 1032 00:48:41,200 --> 00:48:44,800 all your apps call on that service to do name lookups and 1033 00:48:44,800 --> 00:48:47,900 they look around and say so you mean we've already been doing 1034 00:48:47,900 --> 00:48:50,200 microservices was like yeah. There you go. 1035 00:48:50,200 --> 00:48:52,400 You have Micro service architecture already. 1036 00:48:53,100 --> 00:48:57,100 Interesting story indeed in your definition is also is confusing 1037 00:48:57,100 --> 00:48:59,500 for people, right? What is actually micro service 1038 00:48:59,500 --> 00:49:02,000 to Cal CI Towers. If you don't compare the two 1039 00:49:02,100 --> 00:49:04,800 then I think it's easier to understand I worked at A company 1040 00:49:04,800 --> 00:49:07,100 that had a lot of stuff written in Python. 1041 00:49:07,200 --> 00:49:09,800 Everything is written in Python. That was a standard language and 1042 00:49:09,800 --> 00:49:12,100 then we had to do some work where there's only Java 1043 00:49:12,100 --> 00:49:14,700 libraries available. The thing we needed to integrate 1044 00:49:14,700 --> 00:49:17,900 with there was only a Java SDK. So we have to make a decision. 1045 00:49:18,000 --> 00:49:22,500 Do we write our own integration and maintain it in python or do 1046 00:49:22,500 --> 00:49:26,600 we leverage the Java mature SDK and we decided to do that 1047 00:49:26,600 --> 00:49:30,200 integration work. Using the Java SDK and naturally 1048 00:49:30,200 --> 00:49:33,500 that forced us into a separate Deployable and a separate 1049 00:49:33,500 --> 00:49:36,200 service. So now we have this big monolith 1050 00:49:36,200 --> 00:49:39,200 over here and we have this one new service over here that's 1051 00:49:39,200 --> 00:49:42,600 written in Java. But it exposes an HTTP API so we 1052 00:49:42,607 --> 00:49:45,400 can integrate with it with our python monolith. 1053 00:49:45,400 --> 00:49:47,900 That makes a lot of sense. And then someone says, Hey 1054 00:49:47,900 --> 00:49:51,300 coughs, we need to process some batch files again. 1055 00:49:51,400 --> 00:49:54,400 I revisit this decision. Should I really add batch 1056 00:49:54,400 --> 00:49:58,400 processing into the monolith and then have to deploy all of that, 1057 00:49:58,400 --> 00:50:00,700 monolith? Just to do, batch processing. 1058 00:50:00,900 --> 00:50:03,600 My answer would be no. So in that case, even if I 1059 00:50:03,600 --> 00:50:07,400 choose to stay with python, I might start a new binary, or a 1060 00:50:07,400 --> 00:50:10,900 new project or a new service that is written in Python, but 1061 00:50:10,900 --> 00:50:14,000 it can be deployed independently for dealing with the batch 1062 00:50:14,000 --> 00:50:16,100 process. Now, there might be code in the 1063 00:50:16,100 --> 00:50:18,700 monolith that I need to reuse. So then I have to make another 1064 00:50:18,700 --> 00:50:21,800 decision. Do I call the monolith or do I 1065 00:50:21,800 --> 00:50:25,500 import the same libraries at the monolith isn't using inside of 1066 00:50:25,500 --> 00:50:27,100 the thing doing batch processing. 1067 00:50:27,200 --> 00:50:30,300 And so when I think about microservices, I tend to think 1068 00:50:30,300 --> 00:50:33,900 of there is a pattern for deciding when to keep all the 1069 00:50:33,900 --> 00:50:35,700 logic. Gather and went to split it 1070 00:50:35,700 --> 00:50:38,900 apart and you can do both at the same time. 1071 00:50:38,900 --> 00:50:41,300 At the same company on the same team. 1072 00:50:41,700 --> 00:50:44,700 Yeah, I think it makes sense in that sense, but I would try to 1073 00:50:44,700 --> 00:50:47,500 also think of it like, it's a service-oriented architecture. 1074 00:50:47,500 --> 00:50:49,400 Anywhere. Is there any particular reason 1075 00:50:49,400 --> 00:50:52,400 why there's this micro in the prefix of the word. 1076 00:50:52,800 --> 00:50:56,000 So when I was first introduced to like so our service oriented 1077 00:50:56,000 --> 00:50:59,600 architecture, it was actually the Java ecosystem when I was 1078 00:50:59,600 --> 00:51:01,600 dealing with JBoss quite a bit. The Java. 1079 00:51:01,600 --> 00:51:04,200 Ecosystem to me did a decent job back. 1080 00:51:04,300 --> 00:51:06,600 Back then of saying, even if all this stuff is going to end up in 1081 00:51:06,607 --> 00:51:09,100 the same War ear file. There's a way to make sure that 1082 00:51:09,100 --> 00:51:12,100 we draw clean boundaries over each service. 1083 00:51:12,100 --> 00:51:14,400 So even though we may have deployed it all together. 1084 00:51:14,500 --> 00:51:16,500 It was a clean. Way to say this service is for 1085 00:51:16,500 --> 00:51:20,000 the user database will have this particular context this servers 1086 00:51:20,000 --> 00:51:21,600 for dealing with the data domain. 1087 00:51:21,800 --> 00:51:23,400 You had all these ways of deciding. 1088 00:51:23,400 --> 00:51:25,800 Okay, here's a various area. So that different people on the 1089 00:51:25,800 --> 00:51:27,900 team could work on the different service. 1090 00:51:28,000 --> 00:51:30,600 Maybe that's in the form of a jar or whatever. 1091 00:51:30,600 --> 00:51:33,800 And then at build time, we would take all these services and 1092 00:51:33,800 --> 00:51:35,800 we'll push. Together and we will create a 1093 00:51:35,800 --> 00:51:38,400 release and then that release, we can drop into a web 1094 00:51:38,400 --> 00:51:41,400 application server. And then that thing will deploy 1095 00:51:41,400 --> 00:51:44,400 all the services and then hook them up in a way that they can 1096 00:51:44,400 --> 00:51:47,300 either call each other directly or they could call each other 1097 00:51:47,300 --> 00:51:49,200 over HTTP. Depending on the framework, you 1098 00:51:49,200 --> 00:51:51,200 reuse them. So that kind of services 1099 00:51:51,200 --> 00:51:52,500 architecture, made a lot of sense. 1100 00:51:52,500 --> 00:51:55,400 Now, the drawbacks to that in some cases were when people 1101 00:51:55,400 --> 00:51:57,900 start reaching instead of a service inappropriately. 1102 00:51:57,900 --> 00:52:00,500 If you're not using HTTP as an interface, you may be going 1103 00:52:00,500 --> 00:52:03,200 behind the scenes, start calling private methods or you make the 1104 00:52:03,200 --> 00:52:05,700 private method public. So you can call it and now you 1105 00:52:05,700 --> 00:52:09,200 got the spaghetti code. It's things are so bad that you 1106 00:52:09,200 --> 00:52:11,800 just say, you know what, let's never allow this to happen 1107 00:52:11,800 --> 00:52:13,700 again. So what people say, look, if the 1108 00:52:13,700 --> 00:52:16,400 monolith was too big, if we regulate ourselves to make 1109 00:52:16,400 --> 00:52:20,800 things small, that might be one way of preventing those past 1110 00:52:20,800 --> 00:52:23,400 mistakes. So it's like going from a 10,000 1111 00:52:23,400 --> 00:52:26,000 square foot mansion. You live in a huge house with 20 1112 00:52:26,000 --> 00:52:27,500 bedrooms. And you say, you know what? 1113 00:52:27,500 --> 00:52:30,200 I have too much Furniture. The whole place is dirty. 1114 00:52:30,400 --> 00:52:33,100 I'm just going to move into a one-bedroom apartment, to make 1115 00:52:33,100 --> 00:52:35,200 sure that never happens. But guess what? 1116 00:52:35,200 --> 00:52:37,900 If you still have the same practices of not, cleaning up 1117 00:52:37,900 --> 00:52:41,000 after yourself, there's a huge chance that your one-bedroom 1118 00:52:41,000 --> 00:52:43,900 apartment will also be messy over time. 1119 00:52:44,100 --> 00:52:47,100 So, I think the idea with the micro service would be, let's 1120 00:52:47,100 --> 00:52:50,600 try to split things up in a way that we can be very clear about 1121 00:52:50,600 --> 00:52:53,100 Our intention. The user service, only does user 1122 00:52:53,100 --> 00:52:54,700 service stuff. And when you want to do 1123 00:52:54,700 --> 00:52:58,000 something else, you have to go to a whole different repository. 1124 00:52:58,100 --> 00:53:00,600 A whole different way of thinking about it and we can 1125 00:53:00,600 --> 00:53:02,700 then catch it. Things are getting too big. 1126 00:53:02,700 --> 00:53:04,200 If I start seeing the user service. 1127 00:53:04,300 --> 00:53:08,500 Is handling the data model for the web catalog and I can say, 1128 00:53:08,500 --> 00:53:10,000 hey. Well, well, that doesn't belong 1129 00:53:10,000 --> 00:53:11,900 over here. This thing is getting too big. 1130 00:53:11,900 --> 00:53:13,400 It has too many responsibilities. 1131 00:53:13,600 --> 00:53:15,800 That's how we got in trouble last time now. 1132 00:53:15,800 --> 00:53:18,000 All this is a good idea when you start to think about different 1133 00:53:18,000 --> 00:53:20,800 departments, where there's a team that only deals with user 1134 00:53:20,800 --> 00:53:22,800 management. It might be nice for them to 1135 00:53:22,800 --> 00:53:28,200 have a service that's coped. Well for their domain AKA micro. 1136 00:53:28,300 --> 00:53:31,400 But yes, to your point, the word micro is debatable. 1137 00:53:31,800 --> 00:53:36,000 Should it be maximum 1,000 lines of Load should only have five 1138 00:53:36,000 --> 00:53:39,300 HTTP routes. That's a debatable thing that I 1139 00:53:39,300 --> 00:53:41,500 don't know if it makes sense to try to regulate yourself to a 1140 00:53:41,500 --> 00:53:45,300 certain size, but I think it has to be around a certain domain. 1141 00:53:45,300 --> 00:53:46,800 And I think that's what we're after. 1142 00:53:47,100 --> 00:53:50,000 I like the story where you use the analogy of mansion. 1143 00:53:50,000 --> 00:53:53,100 And to one bedroom. I think habits never change. 1144 00:53:53,100 --> 00:53:56,100 And I think, yeah, the term micro is very confusing in the 1145 00:53:56,100 --> 00:53:58,700 world these days. Like sometimes I tend to speak 1146 00:53:58,700 --> 00:54:01,600 with fuel Technologies or sometimes even friends talking 1147 00:54:01,600 --> 00:54:03,700 about micro Services. They will say yeah, I'm doing 1148 00:54:03,700 --> 00:54:06,000 microservices. This but all I can see is okay. 1149 00:54:06,000 --> 00:54:08,900 You almost like just splitting your model it into just three 1150 00:54:08,900 --> 00:54:11,400 different services and call them micro services. 1151 00:54:11,500 --> 00:54:14,800 So to me, that's confusing and I like the responsibility of the 1152 00:54:14,800 --> 00:54:17,800 domain thing that you explain, maybe we should even call it 1153 00:54:17,800 --> 00:54:21,000 responsible service, but that's probably about another time. 1154 00:54:21,100 --> 00:54:24,900 So Kelsey, you also do a lot of things around kubernetes, right? 1155 00:54:24,900 --> 00:54:28,300 Including even in the beginning, where people haven't even heard 1156 00:54:28,300 --> 00:54:31,500 about kubernetes and sometimes the containers as well. 1157 00:54:31,700 --> 00:54:34,200 And also, you wrote a book about kubernetes up. 1158 00:54:34,300 --> 00:54:36,700 Running. We also did kubernetes the hard 1159 00:54:36,700 --> 00:54:39,500 way, which is your GitHub repository about learning 1160 00:54:39,500 --> 00:54:42,600 communities, the hard way. And I also heard that you are 1161 00:54:42,600 --> 00:54:44,800 doing the service mesh the hard way. 1162 00:54:44,900 --> 00:54:47,800 So, first of all, what are some of the lessons learned from 1163 00:54:47,800 --> 00:54:49,700 doing all these things? The hard way? 1164 00:54:50,100 --> 00:54:51,700 Yes. Remember we talked about going 1165 00:54:51,700 --> 00:54:53,700 deep. I remember when I first got 1166 00:54:53,700 --> 00:54:55,500 involved with the kubernetes project. 1167 00:54:55,500 --> 00:54:58,300 I was working at Coral West and we need this project was going 1168 00:54:58,300 --> 00:55:01,400 to be coming out red hat and Google or big partners and maybe 1169 00:55:01,400 --> 00:55:03,800 a few other companies. But court was wasn't really 1170 00:55:03,800 --> 00:55:05,300 contributing. Shooting at the time. 1171 00:55:05,300 --> 00:55:06,400 There's going to be a press release. 1172 00:55:06,400 --> 00:55:09,100 Those going to come out the next day and I remember getting early 1173 00:55:09,100 --> 00:55:11,600 access to the repository and I'm looking at this things. 1174 00:55:11,600 --> 00:55:13,500 Like, how do I even try it? I don't need to see the 1175 00:55:13,500 --> 00:55:16,500 documentation for running this on a system that I have. 1176 00:55:16,500 --> 00:55:18,800 At that time. It was my MacBook with VMware 1177 00:55:18,800 --> 00:55:21,100 Fusion running on it. So I have to spend that night 1178 00:55:21,100 --> 00:55:23,800 just really learning what the couplet is. 1179 00:55:23,800 --> 00:55:25,200 What does it do? What are these flags? 1180 00:55:25,200 --> 00:55:27,200 Even mean? What is the scheduler doing? 1181 00:55:27,200 --> 00:55:28,600 How does it work? Where should it run? 1182 00:55:28,800 --> 00:55:31,600 And going through that process? I really learned all the 1183 00:55:31,600 --> 00:55:34,200 individual components of kubernetes how to compile. 1184 00:55:34,300 --> 00:55:36,200 How to deploy them. And I remember just 1185 00:55:36,200 --> 00:55:38,300 experimenting with the configuration till I got 1186 00:55:38,300 --> 00:55:39,900 something that could actually run a container. 1187 00:55:40,100 --> 00:55:42,600 I remember a publishing that blog post with screenshots. 1188 00:55:42,600 --> 00:55:45,400 Here's how you run kubernetes on VMware fusion. 1189 00:55:45,500 --> 00:55:47,700 And I remember when I was going through the code base, I was 1190 00:55:47,700 --> 00:55:50,100 like, wow, a lot of this go code, looks like Java. 1191 00:55:50,100 --> 00:55:53,900 We should call it covid g eyes to contribute early improvements 1192 00:55:53,900 --> 00:55:56,800 to try to clean up the code base a little bit and also maybe add 1193 00:55:56,800 --> 00:55:59,400 a few missing pieces. So some earlier work that I was 1194 00:55:59,400 --> 00:56:02,800 doing, was thinking about how to automate node membership because 1195 00:56:02,800 --> 00:56:05,500 at that time you would have to bring NG a node in and then just 1196 00:56:05,500 --> 00:56:08,900 generate the config and connect manually to the API server, and 1197 00:56:08,900 --> 00:56:12,200 then register the node yourself. So, Otto node registration was 1198 00:56:12,200 --> 00:56:14,900 one of the first things that I worked on and added support for 1199 00:56:14,900 --> 00:56:18,200 coreos to automatically provision nodes and join them to 1200 00:56:18,200 --> 00:56:20,900 the API server. Little contributions like that 1201 00:56:20,900 --> 00:56:23,600 around and did a little bit of work on C and I but what I've 1202 00:56:23,600 --> 00:56:26,500 learned from then documenting was, when people would say 1203 00:56:26,500 --> 00:56:28,800 kubernetes is Hardware. I will go and do a lot of these 1204 00:56:28,800 --> 00:56:30,800 workshops. I'm super excited in those early 1205 00:56:30,800 --> 00:56:32,200 days. I'm like, who wants to learn 1206 00:56:32,200 --> 00:56:33,400 kubernetes? I could be walking down the 1207 00:56:33,408 --> 00:56:34,100 street. Hey, what are you? 1208 00:56:34,500 --> 00:56:37,200 What a last will cover Nettie's and then I would just sharing 1209 00:56:37,200 --> 00:56:39,800 all the knowledge I had with people because I was still 1210 00:56:39,800 --> 00:56:42,700 learning and this is what I call learning in public as I'm 1211 00:56:42,700 --> 00:56:45,200 getting excited. I had all of these Avenues to 1212 00:56:45,200 --> 00:56:47,200 share my excitement. Whether that was a keynote 1213 00:56:47,200 --> 00:56:50,600 stage, or a YouTube video, or my text editor, adding some new 1214 00:56:50,600 --> 00:56:53,000 functionality. And I remember when we were 1215 00:56:53,000 --> 00:56:56,100 asking ourselves, why are people saying kubernetes is hard? 1216 00:56:56,300 --> 00:56:58,300 My conclusion was, they don't understand it. 1217 00:56:58,300 --> 00:57:00,800 It's not about having the easiest bash scripts run, that 1218 00:57:00,800 --> 00:57:02,900 gives you a kubernetes cluster and five minutes. 1219 00:57:03,000 --> 00:57:05,900 It's that even if you ran the script, most people didn't know 1220 00:57:05,900 --> 00:57:08,000 how to maintain the cluster. They don't even know what 1221 00:57:08,000 --> 00:57:11,100 components are running there. So I decided early on maybe a 1222 00:57:11,107 --> 00:57:14,200 little later when I first joined Google right before that instead 1223 00:57:14,200 --> 00:57:16,700 of trying to build tools that make everything easy. 1224 00:57:17,000 --> 00:57:20,700 How about we make it easy to understand not necessarily easy 1225 00:57:20,700 --> 00:57:24,200 to provision and we ended up doing both soku badman came out 1226 00:57:24,200 --> 00:57:27,700 around the same time, but I also wrote kubernetes the hard way, 1227 00:57:27,700 --> 00:57:31,300 which was stepping people through all the underlying task 1228 00:57:31,300 --> 00:57:32,900 getting the binaries provisioning. 1229 00:57:32,900 --> 00:57:35,900 The VMS creating. SSL certificates, copying them 1230 00:57:35,900 --> 00:57:38,600 to the servers, and wiring everything up. 1231 00:57:38,600 --> 00:57:41,300 And then what we found was, lots of people around the world were 1232 00:57:41,300 --> 00:57:43,800 like, wow, I finally, never understand, all the moving 1233 00:57:43,800 --> 00:57:45,400 pieces, and that adopt gone through it. 1234 00:57:45,400 --> 00:57:48,500 Maybe once or twice, it's still complex, but it doesn't 1235 00:57:48,500 --> 00:57:51,600 necessarily need to be hard. Once you understand the 1236 00:57:51,600 --> 00:57:53,300 components. And remember, this is written 1237 00:57:53,300 --> 00:57:56,400 towards anyone that has an operations mindset or wants to 1238 00:57:56,400 --> 00:57:58,300 learn how it works at the infrastructure, level. 1239 00:57:58,300 --> 00:58:00,200 That was for them. It wasn't meant for developers. 1240 00:58:00,200 --> 00:58:03,000 Even if you're a developer and you're curious, it wasn't to try 1241 00:58:03,000 --> 00:58:05,400 to make your developer workflow. Oh easy, but for people 1242 00:58:05,400 --> 00:58:08,600 responsible for managing a cluster, it was from them. 1243 00:58:08,600 --> 00:58:11,700 So what I kind of learned from this is sometimes the easiest 1244 00:58:11,700 --> 00:58:14,800 way to make something easy is not necessarily make it easy to 1245 00:58:14,800 --> 00:58:17,000 use. But make it easy to understand 1246 00:58:17,300 --> 00:58:21,200 and is that also the motivation. Why you coming with the service, 1247 00:58:21,200 --> 00:58:24,100 smash the hard way. So anything that you want to 1248 00:58:24,100 --> 00:58:27,000 learn more about service mesh. Yeah, you're exactly right 1249 00:58:27,100 --> 00:58:29,800 again, learning and public. I started learning things about 1250 00:58:29,800 --> 00:58:32,800 issue, maybe two years ago, maybe two and a half. 1251 00:58:32,800 --> 00:58:36,000 I even gave a few key notes. Is the when I was looking at it 1252 00:58:36,000 --> 00:58:38,500 I first learned sto, like a black box, like a lot of people 1253 00:58:38,500 --> 00:58:41,000 I installed it. It has a config interface. 1254 00:58:41,100 --> 00:58:44,100 I can configure things like encryption between my services 1255 00:58:44,100 --> 00:58:47,600 rate-limiting, all kind of nice, high level networking policies. 1256 00:58:47,600 --> 00:58:49,500 And this is great. When I started to really look at 1257 00:58:49,500 --> 00:58:52,200 the code base, one of the first things that contributed was a 1258 00:58:52,200 --> 00:58:54,600 prototype for the sidecar injector. 1259 00:58:54,600 --> 00:58:56,100 So for people that use service mesh. 1260 00:58:56,100 --> 00:58:59,800 Typically, you will deploy Envoy next to your application and 1261 00:58:59,800 --> 00:59:03,900 then Envoy would do the heavy lifting in terms of making sure 1262 00:59:03,900 --> 00:59:07,200 that the policy that you put in STO would be enforced by the 1263 00:59:07,200 --> 00:59:09,900 psyche, our Envoy and Envoy all traffic. 1264 00:59:09,900 --> 00:59:13,500 Will go in Envoy and all traffic will come out of envoy, but you 1265 00:59:13,500 --> 00:59:15,900 need to configure your deployments to do that. 1266 00:59:15,900 --> 00:59:19,000 So the injector would basically rewrite your deployments 1267 00:59:19,000 --> 00:59:21,800 automatically before they got scheduled to a node. 1268 00:59:22,000 --> 00:59:24,400 And then when they start to really understand this TSA, wait 1269 00:59:24,400 --> 00:59:25,900 a minute. If I look at the history of 1270 00:59:25,908 --> 00:59:29,000 control plane and its high-level configuring, which what is it 1271 00:59:29,000 --> 00:59:31,000 actually doing? And looking underneath the 1272 00:59:31,000 --> 00:59:32,900 covers. I was like, wow, this thing is 1273 00:59:32,900 --> 00:59:37,800 basically just Dating a config for Envoy, including the SSL. 1274 00:59:37,800 --> 00:59:40,700 Certificates to do this encryption between the services 1275 00:59:40,800 --> 00:59:43,100 and just pushing everything down. 1276 00:59:43,100 --> 00:59:44,300 How's it? Pushing it down? 1277 00:59:44,400 --> 00:59:48,200 Go through the XDS protocol Envoy has a way of streaming 1278 00:59:48,200 --> 00:59:50,300 configuration. So as things change in the 1279 00:59:50,300 --> 00:59:53,700 infrastructure, you can keep the policies and the back ends up to 1280 00:59:53,700 --> 00:59:55,100 date. That's like, wow, this is 1281 00:59:55,100 --> 00:59:57,400 intriguing. But what about everything else? 1282 00:59:57,400 --> 01:00:00,600 Like how do you do off Z once you do get a service that 1283 01:00:00,600 --> 01:00:03,900 connects to, you has Envoy handle dealing with whether you 1284 01:00:03,900 --> 01:00:05,900 are? Allowed to do this thing or not. 1285 01:00:05,900 --> 01:00:08,700 And again, you need something like open policy agent or you 1286 01:00:08,700 --> 01:00:12,500 can say craft the set of policies that says this service 1287 01:00:12,500 --> 01:00:16,100 ID or this spiffy ID can call these paths. 1288 01:00:16,300 --> 01:00:18,000 And then how do you lock all these things? 1289 01:00:18,000 --> 01:00:20,500 But it's Prometheus fit in. So I look the best if that's a 1290 01:00:20,508 --> 01:00:22,900 lot to understand coming from the top down. 1291 01:00:23,100 --> 01:00:25,700 So I decided to start working on this, from the bottom up. 1292 01:00:25,800 --> 01:00:29,100 What I've done is to set the stage for mesh, the hard way is. 1293 01:00:29,100 --> 01:00:31,100 Okay. Let's start with just a set of 1294 01:00:31,100 --> 01:00:32,100 apps. Actually, I start with the 1295 01:00:32,100 --> 01:00:34,100 monolith where I do everything inside of a single. 1296 01:00:34,200 --> 01:00:37,100 Binary is a very simple calculator app with an API. 1297 01:00:37,300 --> 01:00:40,600 So you call the API, it will call the ad service subtract 1298 01:00:40,600 --> 01:00:43,200 service or multiplication service and it has a little bit 1299 01:00:43,200 --> 01:00:44,800 of authentication before you can. 1300 01:00:44,900 --> 01:00:47,400 And then I split that up with no visibility. 1301 01:00:47,400 --> 01:00:50,700 No logging, no tracing and no security and just have a bunch 1302 01:00:50,700 --> 01:00:53,000 of little services and then I posed, the question. 1303 01:00:53,200 --> 01:00:54,900 How would you lock this thing down? 1304 01:00:55,000 --> 01:00:57,500 And that's when I start introducing things like Envoy. 1305 01:00:57,600 --> 01:01:01,100 Start introducing things like open policy agent Prometheus 1306 01:01:01,300 --> 01:01:05,800 Zipkin for tracing and I start adding these Things one by one 1307 01:01:05,800 --> 01:01:08,900 so that people can understand the role of a service mesh and 1308 01:01:08,900 --> 01:01:12,100 how it all works under the covers as they build back up to 1309 01:01:12,100 --> 01:01:15,300 their own service mesh by hand. Wow, really interesting. 1310 01:01:15,400 --> 01:01:18,300 So, how far before we can see it in public, or is it already 1311 01:01:18,300 --> 01:01:22,000 available as available to me on our private GitHub repository? 1312 01:01:22,000 --> 01:01:24,700 All the code is written. All my configs are written, is 1313 01:01:24,700 --> 01:01:26,900 this thousands of envoy configs in there. 1314 01:01:27,000 --> 01:01:29,800 So now what I got to do is get the narrative if anyone's seen 1315 01:01:29,800 --> 01:01:32,500 any of my latest talk to. You see me tease a little bit. 1316 01:01:32,500 --> 01:01:34,000 I've been doing a little sections of it. 1317 01:01:34,200 --> 01:01:36,300 Little Live demos, I think couple of days ago. 1318 01:01:36,300 --> 01:01:39,500 I did one for the production identity day, for the Linux 1319 01:01:39,500 --> 01:01:41,900 foundation and the CN CF right before, Coop, Khan. 1320 01:01:42,100 --> 01:01:45,100 And there, I showed a little bit about how to create your own 1321 01:01:45,100 --> 01:01:48,200 spiffy IDs and jot tokens yourself from scratch. 1322 01:01:48,300 --> 01:01:49,600 All of that stuff will be covered. 1323 01:01:49,600 --> 01:01:51,400 So for me, it's going to probably take me about three or 1324 01:01:51,400 --> 01:01:55,100 four more months given that I'll probably release it in 2021. 1325 01:01:55,200 --> 01:01:57,400 Maybe I'll do it around my birthday, which is in February 1326 01:01:57,400 --> 01:01:59,400 as a present to myself to deliver it. 1327 01:01:59,500 --> 01:02:03,000 And this year, or this time. I want to add a lot of diagrams. 1328 01:02:03,000 --> 01:02:05,500 One thing that kubernetes. The heart of it doesn't have is 1329 01:02:05,500 --> 01:02:08,500 any diagrams and I think a lot of people would like me to go 1330 01:02:08,500 --> 01:02:11,300 and just say, hey, add a few visualisations and diagrams. 1331 01:02:11,300 --> 01:02:13,700 So we know what's going on each step of the way and I think I'm 1332 01:02:13,700 --> 01:02:16,200 going to do that this time. I'm looking forward for that. 1333 01:02:16,200 --> 01:02:18,300 For sure. So Kelsey, another Trend that I 1334 01:02:18,300 --> 01:02:21,700 see in communities world or people thinking about adopting 1335 01:02:21,700 --> 01:02:24,800 kubernetes is actually to use it almost for everything. 1336 01:02:24,800 --> 01:02:27,100 These days. We see people create their own. 1337 01:02:27,100 --> 01:02:30,400 See are these custom resource definitions or you see a lot of 1338 01:02:30,400 --> 01:02:33,300 kubernetes related tools and Frameworks even or something 1339 01:02:33,300 --> 01:02:35,700 workflows. And the more of it, actually, I 1340 01:02:35,700 --> 01:02:38,400 see, the more these tools will keep popping up. 1341 01:02:38,400 --> 01:02:41,300 So what is your take on? Doing everything the kubernetes 1342 01:02:41,300 --> 01:02:43,600 way? So, one thing that I'm really 1343 01:02:43,600 --> 01:02:46,900 happy is that the curvature is Project, really decided to draw 1344 01:02:46,900 --> 01:02:49,100 the line around, what's core functionality. 1345 01:02:49,300 --> 01:02:52,000 And what's not so core functionality, and kubernetes is 1346 01:02:52,000 --> 01:02:54,500 going to be some of the components, like the scheduler 1347 01:02:54,700 --> 01:02:57,800 things, like our back, so you can control, who can write what 1348 01:02:57,800 --> 01:02:59,900 configs, and who can read, what configs. 1349 01:02:59,900 --> 01:03:02,500 And configs would be things like your deployment objects, your 1350 01:03:02,500 --> 01:03:05,200 secrets, your config minutes. And then we have some objects 1351 01:03:05,200 --> 01:03:07,900 that are also considered core like a replication controller. 1352 01:03:07,900 --> 01:03:11,400 So when you say hey create me a deployment, those replication. 1353 01:03:11,400 --> 01:03:13,600 Controllers are the thing. That makes sure that you have 1354 01:03:13,600 --> 01:03:16,400 three or five pods depending on how you configure it. 1355 01:03:16,400 --> 01:03:18,900 But then we said, okay, outside of that core stuff. 1356 01:03:18,900 --> 01:03:21,800 What else do people want to do? And most people want to create 1357 01:03:21,800 --> 01:03:24,200 their own object type. So instead of just the standard 1358 01:03:24,200 --> 01:03:26,900 collection of deployments and config Maps Etc. 1359 01:03:27,000 --> 01:03:29,300 They want to create their own things and deploy their own 1360 01:03:29,300 --> 01:03:31,200 control loops. So, the nice thing about 1361 01:03:31,200 --> 01:03:34,800 kubernetes is if you step back from kubernetes, And you don't 1362 01:03:34,800 --> 01:03:37,900 install the agent for running containers, the couplet and you 1363 01:03:37,900 --> 01:03:39,400 don't do any of that. What are you left? 1364 01:03:39,400 --> 01:03:41,900 With your left? With this, basically control 1365 01:03:41,900 --> 01:03:45,200 playing framework? It has roles, and permissions. 1366 01:03:45,300 --> 01:03:48,700 It can generate routes for you. It can generate client libraries 1367 01:03:48,700 --> 01:03:50,700 for you. It can do all of these things 1368 01:03:50,700 --> 01:03:52,600 like what we call the API machinery. 1369 01:03:52,800 --> 01:03:56,100 And so an API Machinery does is it allows you to also create new 1370 01:03:56,100 --> 01:03:59,600 API endpoints without writing all the code to do all the other 1371 01:03:59,600 --> 01:04:01,900 things. And so the contract there is 1372 01:04:02,000 --> 01:04:03,700 given this universal control plane. 1373 01:04:04,100 --> 01:04:07,500 You can create your own API through a crd custom resource 1374 01:04:07,500 --> 01:04:09,200 definition and maybe that control. 1375 01:04:09,200 --> 01:04:10,500 Plane does. I don't know. 1376 01:04:10,500 --> 01:04:13,100 Let's call it fly an airplane. Some reason you might want to do 1377 01:04:13,100 --> 01:04:14,500 that. So you might create a resource 1378 01:04:14,500 --> 01:04:18,000 definition that says tell me the plane tell me it's starting 1379 01:04:18,000 --> 01:04:19,900 point and tell me this destination. 1380 01:04:20,100 --> 01:04:23,800 So with those three things you may design a crd that captures 1381 01:04:23,800 --> 01:04:26,700 that and also in your crd you also talk about how it should be 1382 01:04:26,700 --> 01:04:29,200 presented. So when I say Coupe CTL get 1383 01:04:29,200 --> 01:04:32,100 airplane controller, then you'll see them listed out. 1384 01:04:32,100 --> 01:04:34,900 So great. So you have all the Side server 1385 01:04:34,900 --> 01:04:37,800 side stuff done for you. So then what's left then you can 1386 01:04:37,800 --> 01:04:40,000 create your own control Loop. And here's the thing. 1387 01:04:40,100 --> 01:04:43,300 A lot of people get confused. You don't have to deploy the 1388 01:04:43,300 --> 01:04:46,200 thing that flies airplanes that control Loop inside of 1389 01:04:46,200 --> 01:04:48,700 kubernetes. You can deploy that on a VM, you 1390 01:04:48,700 --> 01:04:51,400 can deploy that on the service platform because kubernetes 1391 01:04:51,400 --> 01:04:53,300 doesn't need everything to be in a container. 1392 01:04:53,500 --> 01:04:56,200 The only thing you have to be able to do is communicate with 1393 01:04:56,200 --> 01:04:58,600 the API server. So you don't even need any 1394 01:04:58,600 --> 01:05:01,800 machines in your quote-unquote, kubernetes cluster. 1395 01:05:01,900 --> 01:05:05,300 You just need to API machinery and Then given that Machinery, 1396 01:05:05,300 --> 01:05:07,000 you can run that control Loop somewhere else. 1397 01:05:07,000 --> 01:05:09,200 So, at that point, then cabernets can actually be 1398 01:05:09,200 --> 01:05:12,800 helpful in almost any context where you want to declarative 1399 01:05:12,800 --> 01:05:14,500 control plane. As long as you're willing to 1400 01:05:14,500 --> 01:05:18,300 create this, crd the API and the thing that does the work. 1401 01:05:18,500 --> 01:05:21,000 So when you start to say, hey, let's use coupons for 1402 01:05:21,000 --> 01:05:23,400 everything. The truth is on one hand. 1403 01:05:23,400 --> 01:05:26,800 It can be helpful in any of these contexts as where you want 1404 01:05:26,800 --> 01:05:30,900 to control plane to drive some outcome, whether that's eicd. 1405 01:05:30,900 --> 01:05:33,900 So you see it used for tools like Argo or tecton, where you 1406 01:05:34,000 --> 01:05:36,300 Say, hey, here's a list of build steps. 1407 01:05:36,300 --> 01:05:38,600 And then, yeah, Cooper days was like, great give me. 1408 01:05:38,600 --> 01:05:40,200 That definition. I'm not going to do anything. 1409 01:05:40,200 --> 01:05:43,600 I'll just store it, secure it, and let things collaborate with 1410 01:05:43,600 --> 01:05:45,400 this object. But other than that, there's 1411 01:05:45,400 --> 01:05:47,900 nothing for me to do and then you can build your own control 1412 01:05:47,900 --> 01:05:50,000 Loop that actually runs the ICD jobs. 1413 01:05:50,000 --> 01:05:52,900 That's the beauty of kubernetes. So this is why you're seeing a 1414 01:05:52,900 --> 01:05:56,400 lot of people use kubernetes, but more appropriately, the 1415 01:05:56,400 --> 01:06:00,200 kubernetes API Machinery to back these other projects. 1416 01:06:00,200 --> 01:06:04,100 So in that sense, looking at these Trends and especially The 1417 01:06:04,100 --> 01:06:06,400 containers has becoming more and more popular. 1418 01:06:06,400 --> 01:06:08,900 Do you see that? The VM approach will be 1419 01:06:08,900 --> 01:06:11,000 Obsolete? And do you see more like 1420 01:06:11,000 --> 01:06:13,600 containers in the future, becoming more like a platforms 1421 01:06:13,600 --> 01:06:16,100 and there will be the infrastructure of choice for 1422 01:06:16,100 --> 01:06:17,900 people to build the application on. 1423 01:06:18,300 --> 01:06:20,100 So the funny thing about kubernetes. 1424 01:06:20,500 --> 01:06:23,800 Kinase is actually very node Centric, even though we talked 1425 01:06:23,800 --> 01:06:26,300 about containers. We've done a good job in the 1426 01:06:26,300 --> 01:06:30,200 container Community for the most part of separating the machines 1427 01:06:30,200 --> 01:06:32,900 from our applications. So that means we typically 1428 01:06:32,900 --> 01:06:36,100 package all of our Tendencies but we still need the colonel. 1429 01:06:36,300 --> 01:06:38,900 What could burn Eddie's does as actually in my opinion? 1430 01:06:39,000 --> 01:06:43,300 It's just a very thin layer on top of for most people virtual 1431 01:06:43,300 --> 01:06:46,000 machines. So kubernetes to me, makes 1432 01:06:46,000 --> 01:06:49,800 virtual machines easier to use, not necessarily makes them go 1433 01:06:49,800 --> 01:06:51,700 away. Now, of course, you can use 1434 01:06:51,700 --> 01:06:55,500 kubernetes with bare metal, but for most people they're using 1435 01:06:55,500 --> 01:06:57,800 kubernetes with virtual machines. 1436 01:06:57,900 --> 01:06:59,700 So does that make virtual machines go away? 1437 01:06:59,900 --> 01:07:02,800 I wouldn't say that. I would say kubernetes makes it 1438 01:07:02,800 --> 01:07:06,400 easier to Manage a group of resources, typically, since 1439 01:07:06,400 --> 01:07:09,100 we're talking about nodes, and the form of a virtual machine, 1440 01:07:09,200 --> 01:07:11,600 and this is not very different from like puppet Chef or 1441 01:07:11,600 --> 01:07:12,200 ansible. Right? 1442 01:07:12,200 --> 01:07:14,200 These are configuration management tools, where you can 1443 01:07:14,200 --> 01:07:16,600 take all of your machines and put them into some form of an 1444 01:07:16,600 --> 01:07:18,700 inventory and assign roles to them. 1445 01:07:18,800 --> 01:07:21,400 And then that configuration management tool will do the work 1446 01:07:21,400 --> 01:07:24,200 of making sure that those machines behave the way that 1447 01:07:24,200 --> 01:07:27,100 you've described turbinates. Does it slightly differently by 1448 01:07:27,100 --> 01:07:30,600 having higher level Concepts like a container and that will 1449 01:07:30,600 --> 01:07:33,300 be placed in run. So what it does for this step of 1450 01:07:33,300 --> 01:07:35,600 our journey. Makes the virtual machine have 1451 01:07:35,600 --> 01:07:37,900 to do less work. It basically says, Hey Lennox, 1452 01:07:37,900 --> 01:07:40,600 we don't need a package manager down there anymore because the 1453 01:07:40,600 --> 01:07:43,700 user is going to be bringing all the code and dependencies that 1454 01:07:43,700 --> 01:07:45,800 they need. We no longer need people to be 1455 01:07:45,800 --> 01:07:48,600 logging into the machine. We no longer need to be putting 1456 01:07:48,600 --> 01:07:52,000 a bunch of Agents on the server, because now we can include some 1457 01:07:52,000 --> 01:07:54,300 of those agents with the deployment object. 1458 01:07:54,400 --> 01:07:58,400 So it reduces the role a little bit of a virtual machine. 1459 01:07:58,600 --> 01:08:01,400 Now, serve this, a slightly different, depending on the 1460 01:08:01,400 --> 01:08:04,500 contract of your service platform for So if you look at 1461 01:08:04,500 --> 01:08:08,100 Lambda s Lambda is code-based, then Lambda can do things. 1462 01:08:08,100 --> 01:08:10,300 Interesting. Lambda can say, give me your 1463 01:08:10,300 --> 01:08:12,400 code. Here's the languages we support, 1464 01:08:12,400 --> 01:08:14,500 but it's up to me. If I want to compile your 1465 01:08:14,500 --> 01:08:18,300 deployment for Intel or arm. You may not even get to pick the 1466 01:08:18,300 --> 01:08:21,399 CPU architecture because they can compile it to something that 1467 01:08:21,399 --> 01:08:24,000 they want to do for their own efficiency, whereas with the 1468 01:08:24,000 --> 01:08:27,700 container and if you pre-compile the binary, then I'm going to be 1469 01:08:27,700 --> 01:08:30,399 a little bit closer to a particular machine architecture. 1470 01:08:30,399 --> 01:08:32,200 So this is the big battle we have. 1471 01:08:32,200 --> 01:08:35,300 So in the serverless world at the Treatment is typically 1472 01:08:35,300 --> 01:08:38,800 source code based because then we can control what the 1473 01:08:38,800 --> 01:08:43,000 underlying architecture is. If you give me a container then 1474 01:08:43,000 --> 01:08:45,700 I may have to expose and make you make a decision. 1475 01:08:45,700 --> 01:08:48,600 Is this a Windows? Is this Lennox or is this 1476 01:08:48,600 --> 01:08:50,700 entail? Or is this arm? 1477 01:08:50,800 --> 01:08:53,100 Those are the things that kind of keep us gravitated to a 1478 01:08:53,100 --> 01:08:56,800 particular set of machines. So for those people who haven't 1479 01:08:56,800 --> 01:08:59,700 been exposed to communities, what would be your advice for 1480 01:08:59,700 --> 01:09:03,100 them to start with, like we're to learn these kubernetes, ask 1481 01:09:03,100 --> 01:09:05,000 yourself what your real? Our goal is, it's okay. 1482 01:09:05,000 --> 01:09:09,100 If your goal is just to learn kubernetes just to be educated 1483 01:09:09,100 --> 01:09:11,200 in the know. And in those cases, there are 1484 01:09:11,207 --> 01:09:13,899 lots of great kubernetes books out their crewmates up and 1485 01:09:13,899 --> 01:09:16,800 running is going to be probably a much gentler introduction. 1486 01:09:16,800 --> 01:09:20,600 My co-authors are Brendan Burns and Joe beta, those two are two 1487 01:09:20,600 --> 01:09:22,800 of the founders, not the only Founders but two of the founders 1488 01:09:22,800 --> 01:09:25,800 of the kubernetes project. So all three of our voices are 1489 01:09:25,800 --> 01:09:28,500 in this book, there's a second edition out and we try to take 1490 01:09:28,500 --> 01:09:30,800 your from. Hey, here's where you probably 1491 01:09:30,800 --> 01:09:32,600 are. Now, here's how you build the 1492 01:09:32,600 --> 01:09:33,899 container using things like that. 1493 01:09:34,000 --> 01:09:36,800 Care and then try to progress you up the stack to leverage 1494 01:09:36,800 --> 01:09:40,000 more and more kubernetes over time and I encourage you that 1495 01:09:40,000 --> 01:09:42,500 there's other books out there as well, that will take a different 1496 01:09:42,500 --> 01:09:45,200 angle at this and then there's some people who's like, hey, 1497 01:09:45,200 --> 01:09:46,800 maybe I'm going to pass the basics. 1498 01:09:47,100 --> 01:09:49,600 I'm done trying things out. I also want to build kubernetes 1499 01:09:49,600 --> 01:09:51,800 from the ground up and that's where kubernetes is. 1500 01:09:51,800 --> 01:09:54,300 The hard way comes in to try to help you with all of those 1501 01:09:54,300 --> 01:09:55,800 things. Now, if you want to be a 1502 01:09:55,808 --> 01:09:58,500 professional in that, you may want to look at maybe the Kuban 1503 01:09:58,500 --> 01:10:00,900 a certification program that the scene CF run. 1504 01:10:00,900 --> 01:10:03,400 So I think it's like the cuckoo bird, a certified administrator 1505 01:10:03,400 --> 01:10:05,200 or NG. And in that world you might say, 1506 01:10:05,200 --> 01:10:08,200 look, I want to be able to prove my skills so I can start 1507 01:10:08,200 --> 01:10:11,100 managing the stuff at companies or take a job with it. 1508 01:10:11,200 --> 01:10:13,900 That's a lot of infrastructure, Focus paths. 1509 01:10:14,100 --> 01:10:17,100 Now, if you're a developer, the way I like to think about it is 1510 01:10:17,200 --> 01:10:19,500 as a developer, you can start in a different direction. 1511 01:10:19,600 --> 01:10:22,300 One is, you can start with your own application, is my 1512 01:10:22,300 --> 01:10:25,500 application portal Bowl, where it can actually be decoupled 1513 01:10:25,500 --> 01:10:28,800 from the machine in a way that kubernetes likes, for example, 1514 01:10:28,800 --> 01:10:32,400 in my building, my containers, in the way, where it can run on 1515 01:10:32,500 --> 01:10:35,200 a wide range of kernels. That's a good place to start. 1516 01:10:35,200 --> 01:10:38,100 Do I have helped checks and my leveraging some of those Cloud 1517 01:10:38,100 --> 01:10:40,000 native patterns that we talked about earlier. 1518 01:10:40,200 --> 01:10:42,400 And if you do all of those things, then if your 1519 01:10:42,400 --> 01:10:45,100 infrastructure team or maybe even yourself decide to use 1520 01:10:45,100 --> 01:10:47,100 something like kubernetes, you're going to have a great 1521 01:10:47,100 --> 01:10:50,500 head, start of being able to use all the features of kubernetes. 1522 01:10:50,700 --> 01:10:54,500 Because your application has a lot of those standard interfaces 1523 01:10:54,500 --> 01:10:57,600 that crewmates can use. For example, if you expose 1524 01:10:57,600 --> 01:10:59,900 metrics using something like Prometheus, and those standard 1525 01:10:59,900 --> 01:11:03,700 libraries, then those metrics can be used to Auto, scale your 1526 01:11:03,700 --> 01:11:05,000 application. Education and side of 1527 01:11:05,000 --> 01:11:07,400 kubernetes. If you log to standard out and 1528 01:11:07,400 --> 01:11:10,100 maybe even do some structured logging again, criminals will 1529 01:11:10,100 --> 01:11:13,100 automatically collect those logs for you and send them to 1530 01:11:13,100 --> 01:11:15,200 something like stackdriver logging. 1531 01:11:15,300 --> 01:11:17,800 You have so many choices. But if I was the developer, I 1532 01:11:17,800 --> 01:11:20,900 would probably start by making sure that my application can 1533 01:11:20,900 --> 01:11:22,600 take advantage of all those things. 1534 01:11:22,600 --> 01:11:25,500 And then learn more about how to do a deployment inside of 1535 01:11:25,500 --> 01:11:27,900 kubernetes. So again, if I was purely focus 1536 01:11:27,900 --> 01:11:30,700 on development, maybe I don't necessarily take a lot of time 1537 01:11:30,700 --> 01:11:33,500 to learn how to build a cluster from scratch, but I will try to 1538 01:11:33,500 --> 01:11:35,300 learn how to A deployment object. 1539 01:11:35,300 --> 01:11:38,500 How to expose my service, we have things like pod disruption 1540 01:11:38,500 --> 01:11:40,600 budgets and that's more of a little bit of an advanced 1541 01:11:40,600 --> 01:11:42,000 concept. The idea there. 1542 01:11:42,000 --> 01:11:45,400 If you say I want three copies of my app, you can use a pod 1543 01:11:45,400 --> 01:11:47,900 disruption budget to say. If someone is doing maybe 1544 01:11:47,900 --> 01:11:51,200 automatic upgrades for the cluster, I don't want to ever 1545 01:11:51,200 --> 01:11:55,100 have list into of my apps running for reasons. 1546 01:11:55,100 --> 01:11:58,200 And that way, when someone goes try to scale you down to one 1547 01:11:58,200 --> 01:12:00,800 that pod disruption configuration will be your way 1548 01:12:00,800 --> 01:12:03,300 of saying. Hey, you can go no lower than to 1549 01:12:03,300 --> 01:12:06,100 and it Will prevent the administrator from doing that. 1550 01:12:06,100 --> 01:12:08,700 So those are a lot of application Centric things that 1551 01:12:08,700 --> 01:12:10,900 you can learn inside of kubernetes in order to 1552 01:12:10,900 --> 01:12:12,800 articulate how your workload should run. 1553 01:12:13,100 --> 01:12:15,300 Thanks for sharing that. I'll make sure that to put all 1554 01:12:15,300 --> 01:12:16,900 these resources in the show notes. 1555 01:12:17,000 --> 01:12:19,200 So, Kelsey, it's been a pleasure talking to you. 1556 01:12:19,200 --> 01:12:21,500 I learned a lot about communities, Cloud native 1557 01:12:21,500 --> 01:12:24,600 civilization, and all the things that we have discussed so far as 1558 01:12:24,600 --> 01:12:27,300 my last question, normally, I would ask every guest that. 1559 01:12:27,300 --> 01:12:29,600 I have to share their three technical leadership. 1560 01:12:29,600 --> 01:12:31,800 Wisdom, Kelsey. Do you have any that you want to 1561 01:12:31,800 --> 01:12:35,700 share it all of us here here? So the I've learned over time is 1562 01:12:35,700 --> 01:12:39,800 to decouple your identity from the technology and that helps 1563 01:12:39,800 --> 01:12:42,500 you make decisions. I think in a better way, so 1564 01:12:42,500 --> 01:12:45,300 instead of being a Linux system administrator because there's 1565 01:12:45,300 --> 01:12:47,600 going to come a time where Windows is going to be the best 1566 01:12:47,600 --> 01:12:51,200 platform what you're doing. If your identity is so close to 1567 01:12:51,300 --> 01:12:55,700 Linux and Linux only you may not even consider anything else 1568 01:12:55,700 --> 01:12:58,600 because you're so walking to that the same is true for people 1569 01:12:58,600 --> 01:13:00,600 to ICD system. There are some people that will 1570 01:13:00,600 --> 01:13:03,400 only use Jenkins even when something like Spinnaker, might 1571 01:13:03,400 --> 01:13:05,400 be a better. A fit or something like 1572 01:13:05,400 --> 01:13:07,900 Spinnaker and Jenkins is a better fit. 1573 01:13:07,900 --> 01:13:11,500 So if you decouple yourself from the low-level Technologies and 1574 01:13:11,500 --> 01:13:14,300 you step back and maybe try to align yourself more with the 1575 01:13:14,300 --> 01:13:16,300 fundamentals. I think that's going to help you 1576 01:13:16,300 --> 01:13:18,300 be a little bit. Little bit easier to work with 1577 01:13:18,300 --> 01:13:21,200 because you won't be so dogmatic about things but it also helped 1578 01:13:21,200 --> 01:13:24,100 you open the door to New Perspectives versus getting 1579 01:13:24,100 --> 01:13:27,800 bogged down in your job title. The second one would be take 1580 01:13:27,800 --> 01:13:30,200 your time. I know everyone talks about high 1581 01:13:30,200 --> 01:13:33,800 productivity and going fast and all these things. 1582 01:13:34,200 --> 01:13:38,600 But what I've learned over time was I slow down and enjoy the 1583 01:13:38,600 --> 01:13:41,000 path to get there. So if I'm learning a new 1584 01:13:41,000 --> 01:13:44,000 programming language, I'm okay. Slowing down. 1585 01:13:44,100 --> 01:13:47,100 Do some Hello World. Try to rebuild things that I've 1586 01:13:47,100 --> 01:13:50,600 done before and then stop. And then next week, pick it up 1587 01:13:50,600 --> 01:13:54,500 some more and I know that maybe within a year, I'm going to be 1588 01:13:54,500 --> 01:13:57,300 really comfortable with building the things that I want to build. 1589 01:13:57,300 --> 01:13:58,900 That doesn't need to happen in two weeks. 1590 01:13:59,100 --> 01:14:00,700 It doesn't need to happen in three months. 1591 01:14:00,900 --> 01:14:03,200 I'm okay if it takes a little bit of time because it's an 1592 01:14:03,200 --> 01:14:04,900 investment. For the Long Haul. 1593 01:14:05,000 --> 01:14:07,400 So to me that level of patient. So what does that mean? 1594 01:14:07,400 --> 01:14:09,500 I don't look for how do I learn everything? 1595 01:14:09,500 --> 01:14:12,200 I need to know in five minutes or show me the easy way. 1596 01:14:12,300 --> 01:14:15,800 I'm okay saying it's going to take a while and then slowly 1597 01:14:15,800 --> 01:14:18,300 builds up my skills and continue to make progress. 1598 01:14:18,800 --> 01:14:22,300 I guess the third one. I found it easier to inspire 1599 01:14:22,300 --> 01:14:26,900 people and to boss them around and that's by bringing my whole 1600 01:14:26,900 --> 01:14:29,800 self to the job. So if you're in a situation 1601 01:14:29,800 --> 01:14:32,800 where you're someone's boss or manager, of course, you could 1602 01:14:32,800 --> 01:14:35,800 always try to tell them. Exactly what to do and then 1603 01:14:35,800 --> 01:14:38,500 maybe punish them if they don't do it correctly or praise them. 1604 01:14:38,500 --> 01:14:41,200 If they do, that's one way of doing things and it may work for 1605 01:14:41,200 --> 01:14:44,300 a lot of people but what I found most effective for me was to 1606 01:14:44,300 --> 01:14:48,200 inspire people into action because when that happens they 1607 01:14:48,200 --> 01:14:51,500 fill in the blanks in a way that I would have never asked them to 1608 01:14:51,700 --> 01:14:55,700 and then approach it typically with way more passion and energy 1609 01:14:55,800 --> 01:14:58,400 and they will bring their whole selves to the project and I 1610 01:14:58,400 --> 01:15:02,200 think inspiration, so leading by inspiration or persuasion 1611 01:15:02,200 --> 01:15:05,200 instead of authority. Even when you have authority 1612 01:15:05,200 --> 01:15:08,300 over, folks can change the outcome and dramatic ways and 1613 01:15:08,300 --> 01:15:11,100 allow the other person to grow. So I would think, for a lot of 1614 01:15:11,108 --> 01:15:14,600 people explore, what it would take to inspire people versus 1615 01:15:14,600 --> 01:15:17,300 forcing them to do something and you might be happy with the 1616 01:15:17,300 --> 01:15:19,300 results. Very insightful indeed. 1617 01:15:19,300 --> 01:15:22,500 So thank you so much, Kelsey for participating in the show. 1618 01:15:22,600 --> 01:15:25,100 I really, really enjoyed this conversation, and I'm looking 1619 01:15:25,100 --> 01:15:26,900 forward to have you in the future episodes. 1620 01:15:27,000 --> 01:15:29,300 So, thanks again. Kelsey and good luck with your 1621 01:15:29,400 --> 01:15:31,000 mesh, the hard way. Awesome. 1622 01:15:31,000 --> 01:15:35,100 Thanks for having me. Thank you for listening to this 1623 01:15:35,100 --> 01:15:37,800 episode and for staying right till the end. 1624 01:15:37,900 --> 01:15:40,800 If you highly enjoyed, please share it with your friends and 1625 01:15:40,800 --> 01:15:44,200 colleagues who you think would also benefit from listening to 1626 01:15:44,200 --> 01:15:46,400 this episode. And if you're new to the 1627 01:15:46,400 --> 01:15:49,800 podcast, make sure to subscribe and leave me your valuable 1628 01:15:49,800 --> 01:15:53,100 review and feedback. It really really helps me a lot 1629 01:15:53,200 --> 01:15:55,700 in order to grow this podcast better. 1630 01:15:56,200 --> 01:15:59,500 You can also find the full show notes of this conversation on 1631 01:15:59,500 --> 01:16:02,800 the episode page at technology. No, the death website. 1632 01:16:03,000 --> 01:16:06,300 Including the full transcript interesting quotes, and links to 1633 01:16:06,300 --> 01:16:09,200 the resources and mentions from the conversation. 1634 01:16:09,700 --> 01:16:12,600 And lastly make sure to subscribe to the show's mailing 1635 01:16:12,600 --> 01:16:15,700 list on technology. No, the deaf to get notified for 1636 01:16:15,700 --> 01:16:18,600 any future episodes. Stay tuned for the next 1637 01:16:18,600 --> 01:16:21,000 technique Journal episode. And until then. 1638 01:16:21,200 --> 01:16:21,800 Goodbye.