Committing to Cloud Native

Sponsored by Reblaze, creators of Curiefense

Panelists

Justin Dorfman | Richard Littauer | Tzury Bar Yochay

Guest

Kelsey Hightower

Show Notes

Hello and welcome to Committing to Cloud Native Podcast! It’s the podcast by Reblaze where we talk about open source maintainers, contributors, sustainers, and their experiences in the cloud native space. If you are ready to be taken on a magical journey look no further. We are super excited to have as our awesome guest today, Kelsey Hightower, who is Principal Engineer and Principal Staff Advocate at Google in the Google Cloud Platform Division. Kelsey shares with us how ended up in the Cloud Native space, joining Google, and his job offer at NASA. We also learn about how Kelsey succeeds with his live demo’s, why he calls himself a Minimalist, and the amazing story behind No Code. Find out why Justin calls Kelsey the “Metaphor King,” and how Kelsey thinks engaging people and telling stories can help a little better at building things. Don’t wait any longer and download this episode now to find out more magical things from the “Principal Storyteller!”

[00:02:20] Kelsey talks about how he ended up in the Cloud Native Space and how he joined Google.

[00:04:20] Find out about Kelsey’s job offer at NASA.

[00:06:33] Richard wonders since open source has longer timelines if it resonates with Kelsey.

[00:09:38] Kelsey tells us his role in Google with open source projects.

[00:11:59] We hear Kelsey’s thoughts on if Istio is really good at delivering all that documentation, if it could use work, or if that’s the Google way when it comes to open source.

[00:17:27] Tzury wonders how Kelsey’s been doing all these years pitching to the Developers who can be a tough crowd in the industry.

[00:19:18] Justin mentions how “suspenseful” Kelsey’s live demos are and he wonders how he goes in front of thousands of people without freaking out.

[00:23:22] Tzury wonders why Kelsey calls himself a minimalist on his Twitter when he’s so fascinating on stage.

[00:24:55] We learn about Kelsey’s GitHub repo called No Code, which has 46,000 stars.

[00:28:15] Kelsey tells us how he came up with the No Code idea.

[00:30:54] Kelsey shares where he sees Cloud Native going in the future.

[00:33:54] Find out why Kelsey said, “Magicians are cool, but teachers are better!”

[00:37:24] Justin calls Kelsey the “Metaphor King” since he’s so successful at communicating what he sees and his values, and Richard wonders if he has any tips to share on how to do that effectively do that. Kelsey shares some outstanding advice!

[00:40:21] Justin wonders if it’s been a blessing in disguise for Kelsey to have the year off speaking at conferences because of the COVID 19 breakout.

[00:43:46] Find out where you can follow Kelsey online.

Quotes

[00:03:40] “So, when Kubernetes dropped I kind of looked at it and said you know what, this is probably it!”

[00:04:29] “After I left CoreOS I actually signed, you know, my deal to go work for JPL out in Pasadena, and I had done a little bit of work before then on the open source front, and they were using Kubernetes to power their kinda on-site data center there.”

[00:05:35] “They explained to me some of the projects you work on at NASA, I think there was one project where, you know, one of the spacecrafts flew past Pluto and took a bunch of pictures, and it’s like that person that worked on that retired two decades ago.”

[00:06:36] “It depends on how these projects are launched.”

[00:07:22] “And then you have things that are kind of wide open, hey, we’re taking all contributions and then maybe you find out that may or may not be sustainable.”

[00:07:37] “You build a product, you gotta make that thing profitable day one. That is the success metric.”

[00:08:48] “Because when you say yes or no, you’re signing up for long-term maintenance. Someone can drop by with a contribution and then be gone forever, but it’s on you to maintain.”

[00:09:11] “You see people get mad. It’s like, when is this thing going to get updated. I’ve been using it for twenty years for free and this is unacceptable. And you’re like, I’ll give you a refund?”

[00:09:57] “I think what people may not understand is Google doesn’t have to try very hard on the open source side.”

[00:10:46] “So when it comes to open source and when people say Cloud Native, I think Google has earned appropriate credit for helping spawn this thing. At CoreOS, our mission was GIFEE (Google’s Infrastructure for Everyone Else).

[00:12:11] “I mean if you think about it, what does have great documentation? Almost no one likes any documentation anywhere. “

[00:12:22] “What’s the documentation for Bash?”

[00:12:46] “I think documentation is kind of a community thing. You can always go write a book to fill in the gaps. You can always create a documentation site all on your own.”

[00:13:07] “Google’s approach has been, number one, Envoy is amazing. Let’s contribute to it.”

[00:14:58] “But, I also am one of those persons that wrote Kubernetes the hard way because I thought there was a lack of documentation.”

[00:17:28] “So I don’t pitch to them which is the key. The key is I’m just learning in public.”

[00:17:33] “I think when people say, when Kelsey talks about something, I have that empathy that you can see yourself probably typing the same commands that I do in my live demo.”

[00:18:54] “Imagine if every developer had to implement HTTP first, we would all be like this is crazy. But that’s kind of what we’re doing on the infrastructure side and we’re proud of it.”

[00:20:17] “All those micro feelings of joy that I get from making these work, I try to bottle them up and make that part of the talk.”

[00:22:40] “I feel like I’m being the Dungeon Master. I’m telling the story and you can see people leaning in like, this ain’t gonna work!”

[00:25:22] “So No Code, honestly I think the people took it and ran with it, but it told me one thing, that I think people are getting tired of all this complexity.”

[00:31:01] “I just think any technology that’s super successful has to get democratized, that the people who use it in mass shouldn’t know how to actually build it. That shouldn’t be a requirement.”

[00:31:13] “If you want to see any technology, see global adoption, then it can’t require everyone to know how to operate it at the very lowest levels.”

[00:33:54] “I would say magicians are cool, but teachers are better!”

[00:36:39] “If you’re listening to this and you’re struggling, like why language is good for diversity, some people resonate with food better. You go and taste food from another country it’s like, wow, I would have never thought to put those things together! This is delicious! That’s what diversity gets you when people are trying different things based on their own independent culture, so maybe that would help a lot more people understand and maybe appreciate diversity exists.”

Links

Curiefense

Curiefense Twitter

Cloud Native Community Groups-Curifense

community@curiefense.io

Reblaze

Justin Dorfman Twitter

Richard Littauer Twitter

Tzury Bar Yochay Twitter

Kelsey Hightower Twitter

Google Cloud

“From McDonald’s to Google: How Kelsey Hightower became one of the most respected people in cloud computing” by Tom Krazit (Protocol)

No Code-GitHub

GIFEE (Google’s Infrastructure for Everyone Else)-GitHub

Credits

• Executive Produced by Tzury Bar Yochay
• Produced by Justin Dorfman
• Edited by Paul M. Bahr at Peachtree Sound
• Show notes by DeAnn Bahr at Peachtree Sound
• Transcript by Layten Pryce

Transcript

Intro: Hello, welcome to Committing To Cloud Native, the podcast where we talk about the interface between open source and Cloud Native.

Richard Littauer: We're super excited about our guest today, can't wait to introduce him very briefly before we get to that. I want to introduce the other panelists besides Richard Littauer, that's this guy. We also have Justin Dorfman, Justin how are you?

Justin Dorfman: Hey Richard, how are you?

Richard Littauer: Doing alright and we have Tzury Bar Yochay. Tzury, how are you doing good?

Tzury Bar Yochay: I'm good Richard, thank you.

Richard Littauer: Excellent, our guest is awesome, don't think it'll be a surprise to any listeners of this podcast and I can see he's already blushing or trying not to make it clear like that's the thing that I'm doing right now, but we're really excited. So Kelsey Hightower is a principal engineer, principal staff advocate, it's kind of confusing, but he has a lot of terms going on. But wears a lot of hats at Google, he is in the Google Cloud platform division and he's calling today from, I believe his house in Keemas, Washington, which is really exciting across the river from Portland but not in Portland. Kelsey, how are you doing today?

Kelsey Hightower: I'm doing fantastic, I woke up my internet was working so I knew everything was probably going to be okay.

Richard Littauer: I hope that's the case like 365 days out of the year, is that not always the case for you?

Kelsey Hightower: Yeah, there's some days you wake up and it's just like, nope not today.

Richard Littauer: Not today, not today. So you've been an engineer now for a long time, you wear a ton of hats, I read a bio of you on this awesome website. I'll put a link of that in the show notes, can you tell us how you ended up in the Cloud Native space?

Kelsey Hightower: I think the cloud native space, if you think about the way we talk about today, some people would say it probably started with Kubernetes. But I think my days of configuration management is when I was personally a search of a better abstraction. So I used to work for Puppet Labs in 2011, 2012 timeframe. And back then, I think that's when Cloud was available, right? So you could always launch VMs and there were API for infrastructure and I think people were then trying to figure out what are the missing abstractions from all these kind of virtualized things. Like virtualized networks, virtual machines, but we didn't have anything at the app layer. So I think that was my initial journey into this thing, we call Promise Theory and then we got an app abstraction with containers. So I spent some time at CoreOS and during my time at CoreOS, that's when I really got into Docker but maybe more importantly, I got into things like Kubernetes. And I think that's what most people kind of think of as the Genesis of Cloud Native, even though the practices started much earlier.

Justin Dorfman: Was that an acquisition that Google made or that was how you joined Google?

Kelsey Hightower: No, actually so when I was at CoreOS, I joined and partnered close with the founders over there. And when Kubernetes came out, we had a different idea of what the future would look like for us, right? We had a tool called Fleet, which was its own container management platform built on system D. And so when Kubernetes dropped, I kind of looked at it and says, you know what? This is probably it, this is the thing I think we've been all trying to build, but we didn't know how and we didn't necessarily have the experience. And so once I was kind of contributing at the core level on the source code level, a lot of people knew me from the workshops and the key notes and the conference talks. But behind the scenes, we were just deep in the code base figuring out how to synergize these two directions that the industry was going in. So after a couple of years, it just made sense, right? I was already into the go programming language, I was already using GCP that was already in the Kubernetes space. It just made sense to transition over to the Google Team.

Richard Littauer: I know you also thought about joining NASA for a while, space level is a thing of yours as well?

Kelsey Hightower: Yeah, that was the offer I accepted before going to Google. So after I left CoreOS, I actually signed my deal to go work for JPL out in Pasadena and I had done a little bit of work with them before then, right on the open source front and they were using Kubernetes to power their kind of onsite data center there. And their idea was like, look we're all in on these technologies so you've been helping ramp our team up, help us acquire these particular skills. Why not help come get us to Mars and be part of that whole mission. So I went on site a few times and I got a nice little preview of the new experimental Rover that they were building with a laser on the front. I was like, yes, this is the job that I want and so, yeah, I was committed to doing that. Then I got a call from Google and said, hey, give us a shot first and the NASA team was like, hey look, this is going to be 10 years plus before we get a person on Mars, go to Google, you don't like it you can come back here and I promise you we'll still be working on this.

Justin Dorfman: Wow! What a cool organization to be like, you know what, go there and then when you're done just come back, we got our seat for you. That's pretty awesome.

Kelsey Hightower: They explain to me that some of the projects you work on at NASA, I think there was one project where one of the spacecraft flew past Pluto and took a bunch of pictures. And it's like that person that worked on that retired two decades ago, and you just know that the results of your work, you may not see until way later on. So this is why I think they're grown patients in terms of like working on things.

Justin Dorfman: Yeah, I couldn't do that. I need to see like instant results, that's just the way my mind works.

Richard Littauer: So you're not only an advocate and a speaker at conferences or keynote of some report, but you're also a developer. You've also been back in the sack, working directly on the code itself. You've been overseeing things that probably never saw the light of day and you also love open source stuff. And open source also has these long timeline issues because you're never totally in control and community projects is kind of, well that's kind of how it's going. Does that resonate with you that open source tends to have a longer timeline.

Kelsey Hightower: Depends on how these projects are launched as some projects launch with a very clear vision about what they want to solve. And then what you'll see is that core will stay roughly the same and then you'll get features over time. Especially if you have a strong maintainer with a good plugin system, when you have those two things then the core can stay pretty solid and kind of address it's core mission. Take the Lennox Car Portal for example, if you want more drivers there's like a whole place to go and experiment with drivers. But some people, if you looked at Lennox 20 years ago and he looked at it today, it will roughly feel the same, right? Maybe your user land is different. So I think open source is really about the type of community that spawns up and you can have success with both models, right? So that benevolent dictator model Python, there's some things that don't have foundations and they have a core team. Then you have things that are kind of wide open, okay we're take an all contributions and then maybe you find out that may or may not be sustainable. So I think that's kind of one thing, but I think it's a place where we can innovate without necessarily the pressures you tend to have when you're trying to run a business. When you build a product, you got to make that thing profitable day one, that is the success metric. But with open source, you can just share an idea and if people like the idea, they can take it and run with it even if you can't build a successful business on top.

Justin Dorfman: Well, I think you bring up a good point. Curl just passed its 20th birthday; I believe that's a run by Daniel. With that side, I mean, he ran this project and he still runs this project. He dedicated two hours a day after work and just really has dedicated his life to Curl and getting back to the Mars thing that we were going at; his Curl runs in the helicopter. But you know the helicopter that everyone's like, wow! That's really cool. So you're right, it could be a BDFL or a, or an organization, a nonprofit or a foundation like the CNCF. So it's hard to know, it really depends on I think the leaders of the project.

Kelsey Hightower: We also get into sustainability issues, right? Because a lot of times, sometimes these code bases become super complex and there's really only a handful of people who understand them and are willing to make the tough decisions of saying no or yes to something. Because when you say yes or no, you're signing up for long-term maintenance, someone can drop by with a contribution and then be gone forever, but it's on you to maintain. So I think this idea of maintainer ship, I don't think that's actually sorted out well in open source. I think the community will talk about community and not realize that you're kind of burdening one or two people with the sustainability promise. And you see people get mad, it's like, what is this thing going to be updated? I've been using it for 20 years for free and this is unacceptable as a maintainer you're like, I'll give you a refund.

Justin Dorfman: Yeah, seriously.

Kelsey Hightower: And it's like a really hard problems open source and yeah, refunds accepted. We're sending your money back in the mail for the free thing that you downloaded this really great way of dealing with that.

Robert: I'm really curious about your role in Google with open source projects. I know Google has an open source program office, there's some excellent people in that office. I don't know how well they interface with the Cloud Native space. Did you have like open source projects that are really well staffed and managed by the [inaudible09:36] there, how does that work?

Kelsey Hightower: I think what people may not understand is Google doesn't have to try very hard on the open source side is just part of its natural DNA. Now I work with a lot of companies and they're trying really hard. Like they're doing workshops seminars, learning about inner source, and having guest speakers and good for them, they can go on their trajectory and learn about it. Google has been that way for a very long time so it was very natural. So what you end up with is things like Chrome has been open source forever, so much so that even Microsoft has rebased Edge, their new browser on top of Chrome. So it's just in our DNA, right? And most people can't understand it. It's like, shouldn't you hoard all the great technology for yourself should have more of an open core model. We don't really need to do that; we have kind of SAS like services where we don't always have to worry about selling software to someone else. So when it comes to open source and when people say Cloud Native, I think Google has earned appropriate credit for helping spawn this thing. At CoreOS, our mission was GIFEE, Google's infrastructure for everyone else. That's what we used to talk about when that project was getting off the ground, that's how we used to talk about it. Permitius. A lot of those ideas come from Monarch, which is the system internally at Google. We're doing something similar Kubernetes based on Borg and even before all of the open source products that you can touch, we were producing those white papers, like the MapReduce paper and all of these things. So I think we've got to remind people that this has been normally part of our DNA. And I think a lot of times people are finding tension in the vendor community where they don't know how to interact at that level where it's just a genuine thing that we do.

Justin Dorfman: Well, there's one thing that we just did a podcast with Richard Lee of ambassador labs. I think you just did a podcast with them as well and he said, one thing that was really driving him insane was upgrading Istio is very difficult and he's like Googled really doesn't have to try hard with the documentation and obviously this is just his opinion. What are your thoughts about that, do you think that Istio is really good at delivering all the documentation? Could it use work or is that just the Google way when it comes to open source?

Kelsey Hightower: I mean, if you think about it, what does have great documentation? Almost no one likes any documentation anywhere, typically this sentiment is really heard louder in the early days. What's the documentation for Bash.

Justin Dorfman: That is a good point.

Kelsey Hightower: Most people have never seen the documentation or read it, you just get on there and start pounding away through muscle memory, after 20 years you can jump on a shale and know how to use 7,000 different commands. Have you seen the Curl Docs? No, you know what I mean? Like the examples are hard so what do you do, you look at the main page and then you go look for real examples.

Richard Littauer: Man, Bash has 48 different lines.

Justin Dorfman: Wow!

Kelsey Hightower: I think documentation is kind of a community thing, you can always go write a book to fill in the gaps. You can always create a documentation site all on your own and remember that's that maintainer thing again. I gave you something, have hundreds of people working on something for $0 and it's easy to kind of point out some of the faults. On the documentation front so I think Google's approach has been number one, Envoys amazing, let's contribute to it. Istio came from IBM, had a different name before they had a control plain, Google look at that, let's contribute to it. And we brought a lot of our own experience from internal, the way we actually run we have something similar; we call it a different name. But we have a kind of a service mesh that is rooted around identity and policy and we brought a lot of that expertise into that community. So in part, we are contributors to a thing and we stepped up and we'd done the hard maintainer ship. Remember that API went through two or three major refactors and now we've kind of landed on this thing that adopts most of that Kubernetes model and tries to find a little bit of synergy for the rest of the industry, while also working on hard Load of problems like supports that can be custom filters. Just all of these things that you need to have something to be enterprise grade and so do we spend a lot of time on docs? I mean, if you look at the Istio site, I think they've tried their best to give you real world examples and I know people who worked on the kind of Sock Shop App, so you can have a real microservice to test things out. So I think Google did a really good job, now there's some bad blood around like this relationship between foundations and who owns a thing and remember, we get back to that benevolent dictator thing. So some people will say it should be owned by everyone, if you've ever maintained a project owned by everyone is really hard to pull off. I've maintained a few projects where people will come in and say, you should do this totally different thing, I'm out, let me know when you're done. That gets a little tricky, right? So I would say, in the Istio case the fact that you can download it get started add any room for improvement, I see those as opportunities.

Justin Dorfman: Totally and I want to be very clear what he said, I'm just resaying it.

Kelsey Hightower: No it's valid, everyone should be able to have a valid kind of like this thing could be better, this thing could be better because that's where the features come from, that's where the improvements from. But I also am one of those persons that wrote Kubernetes the hard way, because I thought there was a lack of documentation. Started writing a book on the hole subject because I thought there was a lack of documentation, so again opportunities.

Tzury Bar Yochay: Yeah, the hard way is actually the easiest way as we know. And by the way regarding Istio that Kelsey indeed are refactoring the API APIs with probably some incompatibility, may make it a bit harder for people to upgrade from existing platform to new one. But the purpose of the refactoring is actually to make it far easier for newcomers. So new deployments will like a more consistent API and simpler and more intuitive and so on. And by the way, since Richard Lee podcast, we have a podcast with a guy from Cisco, actually one of the co-creators of Curiefense. And he told us about using Istio and to switch from situation where they were deploying a new data center, took them between four to six months, with Istio and Kubernetes it's now a matter of three to four minutes. So imagine that Cisco Scale deploying a new data center.

Kelsey Hightower: If you're listening to this, you probably could have done this with Engine Next, just to be fair. So when I hear Istio, I hear decisions being made, Istio already has a framework for thinking about TLS mutual law. Istio already has a framework for describing a config to include those other things. So a lot of times we'll hear like, oh when I adopted Kubernetes or Cloud things got faster, it was more like somebody made a bunch of decisions and then when you make those decisions and we give those decisions, names like Istio. Because when you break down Istio, like when you really break it down, you got Envoy, you got a bunch of little side cars that do things like mint certificates and rotate them. You got a thing like the pilot that goes to Kubernetes and tries to read your config and then match it up and generate an Envoy config and you have a pilot object thing that distributes it out. So when you look at it, you'll say the fundamentals are the same, so I think aloud that time savings come from you don't have to as a team try to make 25 different decisions. You can just say, we're going to do Istio and then boom, there you go. Now you have your kind of network substrate there.

Tzury Bar Yochay: I'm looking at it Kelsey as I'm listening to you and thinking what the toughest job you took upon yourself in the industry, which is pitching to developers. This is a tough crowd, man, how have you been doing all these years?

Justin Dorfman: So I don't pitch to them, which is the key, the key is I'm just learning in public. And I think when people say, when Kelsey talks about something, I have that empathy that you can see yourself probably typing the same commands that I do in my live demo. I forget all the extras that would just make it unbelievable. I just say, if this is what you're trying to do, here it is, let me show you. This is what I was trying to do, here's where I got stuck, scroll down, here's where I worked around it. This is what we're trying to do, here's the hype, let's peel back the hype a little bit and talk about the fundamentals. And I think what most engineers respect is when you can go below the hype and just say, make it click for me, I think you gained this bit of trust. So once I've had that trust, I've just been careful not to violate it. So if I'm interested in Server less, I try to approach it the same way. Here's why I'm interested in Serverless, you don't have to buy it from me, but here's why I'm interested. This concept, that over time as developers, we tend to serialize our expertise into runtimes, frameworks, and SDKs. So if you're a developer and I have a big ops background, you might be confused why are we still talking about low-level infrastructure 20 and 30 years later? When is someone going to step up and serialize those things into systems like Docker and Kubernetes and we know that we're never going to be finished because as we learn new patterns, we should be creating new SDKs and frameworks. Imagine if every developer had to implement HDP first, we will all be like, this is crazy, but that's kind of what we're doing on the infrastructure side and we're proud of it.

Justin Dorfman: Your paragraph, great points. I think one thing about you saying learning in public and if no one has seen one of your live demos, it's probably one of the most suspenseful and it's a great show and you learn stuff. And I mean, how do you go in front of thousands of people and do a live demo without freaking out? I mean, I guess my question.

Kelsey Hightower: You know what I do freak out, I freak out. So here's the thing, I write all the code and so let's use the one from like one of the Coop Cons when I was like the path to servers, I was showing the Kubernetes community, the benefits of something like Amazon's Lambda. And I remember I was in my room, first of all I don't really know how I'm going to start these things because I don't have any speaker notes, but I might have a few images to put some people in front of the ideas and the stories. And so when I lead with the people, you then can identify and attach and once we're there, I might give you a very simple use case and say, you see this piece of code, now we're going to have to make this code work in these two different models. So when I'm writing all this code, I'm like, you know what, why am I doing this in go, let's up the ante, let's do it in Fortran. It's like, yeah, does Fortran even work in 2018? We're about to find out, totally works, great and I had to learn some Fortran.

So all of those micro feelings of joy that I get from making these work, I try to bottle them up and make that part of the talk. So, all right, now I got the Fortran going and I can put Fortran in Kubernetes, can we put Fortran in Lambda? And when I remember getting this part to work, where I had wrote a little tool that would go to Kubernetes, download a deployment, grab the Docker image, and then extract all the layers and then take out the binary and then wrap it in the Lambda function and then put it in Amazon, I was like, oh I'm a genius. This is cool but it was incredibly boring, I ran the command I'm sitting there like, this is not exciting, of course I could put colors on a terminal. But all of these people in this crowd, I got to do something better and I remember on my Spotify playlist, Diana Ross, I'm coming out was playing and I was like, yeah that's what's happening with the Docker image, right? It's coming out of one thing and going into another. So I use this tool called MP3, MPEG123, it's like an old-school Unix command and you can actually programmatically increment and decrement the volume. So I was like, how about this? I'll write my tool in Go have a separate thread that can deal with the volume.

So people thought I scripted it out to be perfect, no I ran a command in one thread, type the standard out to the screen and in another thread, I started the music. And if that command takes a minute, then we will hear a minute of the song, but it takes 30 seconds, we hear 30 seconds of the song and so I could step back. And the weird thing about that, I was on edge because I was doing this on my Chrome book and at the time Chrome didn't have a real audio solution for the Linux VM to play audio through the main system. So I had to install like a sound server and pipe the audio through the sound server. I'm sitting here on stage, like this only works three out of 10 times when I was in my hotel. So it may not play audio right now, so I hit that button and when I heard Dianna Ross come to the house speakers, I was so happy. I was like, this is going to be dope and then it ended and remember I'm unscripted at this point. I'm basically doing live jazz and I said, what? You all don't have music for your command line tools and you said this and it's applaud and then you move on to the next section. So that's how I do it, I'm nervous, I'm doing improv on stage, but I can look at the developers, I know that look we're on the same team. You guys want to see where this goes, so I feel like I'm being the dungeon master. I'm telling the story and you can see people leaning in like this ain't going work and so that's how I do it.

Justin Dorfman: Love it, love it, love it.

Richard Littauer: I think you'd be an excellent speaker at Bang Con. If you've ever heard of this, it's in New York, it's a conference that's just dedicated towards the joy of computing. I had a friend who made the zip drive, you take mini files and the zip file would go in and out and play the mini file. like, you know the tones of something zip drive.

Kelsey Hightower: That's amazing.

Richard Littauer: And it sounds like what you're doing, right? Just like, hey, okay this is boring, well how could I have more fun here? Let's put jazz in there, sweet! I love it, I love it so much.

Tzury Bar Yochay: Well, we're fascinated Kelsey, obviously then I wonder. I mean, you did all that on stage and then you call yourself a minimalist on your Twitter, where is the minimalism here?

Kelsey Hightower: If you think about it, the story was the thing, I just added elements to the story. There's no slide decks, there was no 10 pieces of a microservice, there was no database. There was no algorithms, I was just tell him the story and so I took the simplistic approach of like, how will I connect with humans? I'm trying to ask people at Kub Con to consider something that replaces Kubernetes as a north star for the future. So what is the simplest way to do that? And I figured it was to tell a story so even when you pick something simple, then it becomes complex to execute on it. Because if you have all these things, I could have used numbers and like 50% of people, new workloads or using Lambda and then try to convince you with a bunch of research papers. I would have been all over the place on stage and then you would have to try to pick and choose what was the thing to convince you. So I only had one tool which was story, so I just told the story show don't tell and you saw it in action. And then you're sitting there and asking yourself, what are you actually trying to do, why is this not actually the path to the future? So I think that's where the simplicity comes from. So as a minimalist, I try to get rid of all the extras, all the slides, all the diagrams, all the charts, and then simplify it and then go deep on the simplification.

Justin Dorfman: Speaking of minimalism, you have a GitHub repo called No Code. My question to you is how many poll requests do you get on No Code?

Kelsey Hightower: Oh, no I don't even look but I remember when I put that thing up, I was getting emails from like engineering managers, like look you need to take this thing down. My whole team is distracted right now, they're in chat talking about this thing and I'm sitting there like this ain't my fault. Like you got other problems and so No Code, honestly, I think the people took it and ran with it, b ut it told me one thing that I think people are getting tired of all this complexity, every new framework has all of these promises that it can solve all your problems. But then that framework becomes a liability because maybe you can't upgrade it, it doesn't keep pace with the features you need. Yeah, so No Code was like a big joke, but I think people took it super serious when you look at some of the comments.

Justin Dorfman: If I remember correctly, there was a very colorful hacker news thread, just people talking about exactly what you're saying, dependency and at what point do we just concentrate on just making it simple as opposed to importing a hundred different dependencies. So I thought that was really interesting and so you don't look at any PR you just say, okay.

Kelsey Hightower: That thing is a monument for the community.

Justin Dorfman: That's cool.

Kelsey Hightower: I think it's a checkpoint in our history where we can go look at it and say, there was an inflection point where I think enough was enough and we need to just really take another look.

Justin Dorfman: I just can't believe there was managers emailing you or hitting you up, like, hey, can you take this down? Like, who says that?

Kelsey Hightower: Oh, you'd be surprised, man, like in this business. I'm also an assessable person, so I'll hear people out and try to respond and be courteous to folks. So I'll hear people out and look, I thought it was funny, I can imagine. I've been a manager before you come in and your whole team is like emojis and look at this comment, look at that comment freaking now and having fun with it, you're like, can you all please write some code and it's like, no we're practicing no code right now, right? Like, you'd be like, you know what? This got to go.

Justin Dorfman: Yeah, it's so brilliant and it's got like, how many stars? Like over 60,000? It's like one of the top repositories.

Kelsey Hightower: You know what's so funny, GitHub did a thing like top repositories that year you had like the React Framework, TensorFlow and No Code up there in the top repositories because of stars and momentum. I was like, I need to go call a venture capitalist and raise a round, right? Because you have stars or like currency.

Justin Dorfman: Yeah, they are.

Richard Littauer: For those of you who don't know No Code is a repo, that's basically just, there's no code in it and the read me is not shown in the program, go read it. It's hilarious, awesome. There's 46,000 stars, which is just.

Justin Dorfman: It's brilliant.

Richard Littauer: Incredible.

Justin Dorfman: It was like, oh my God, that's so awesome and it was minimal, that is Kelsey's like emo. Since this isn't a video podcast described that Kelsey is sitting in a room and in the window, there's one plant.

Kelsey Hightower: From Ikea.

Justin Dorfman: From Ikea.

Kelsey Hightower: It's not even real.

Justin Dorfman: And it's like, I look at it and I'm like, God that looks so cool. It's just like that little minimal touch, so he practices what he preaches.

Tzury Bar Yochay: How did you come up with this idea of no code originally, what was the trigger?

Kelsey Hightower: To be honest, for my job, I work at Google so I was in Mountain View and when we're doing product work, you kind of whiteboard with the engineering team. I might go meet a few customers, you might go sit with the cube startups and their engineering team. And then when you're scrolling through hacker news and it's like, everyone has a new solution, new framework, new code, new libraries, and I just want to tweet because I'm waiting for my flight in the airport. And I just wanted to tweet, like we don't need any more code because there's a lot of existing things that work or you hear about all this duplication, even on the same team. Someone write the exact same class that you already have in the code base and you're like, why didn't you at least do a search to see if that was already implemented? And then I said, you know what? I got a little time; you know what would be funny if I just made a GitHub repository called No Code. And then I was like in Kelsey fashion, because I'm all about the docs, I wrote a tutorial, how to get started with no code and the benefits of no code and.

Tzury Bar Yochay: In design style guide.

Kelsey Hightower: Or add a contribute, right? And the contributing guide says you don't, there's nothing to contribute to it. So then I just posted it, close my laptop, get on the flight and I'm like let me just kind of take a little quick nap. I opened up my laptop and this thing was like product hunt, people had medium posts, Twitter was blowing up, the stars are crazy. And then the coolest thing was someone issued a pull request and the pull request had a blink title, it had a blink commit message and had a blank body, everything was blank and it turned out this was a bug. It's like a GitHub bug, you are not supposed to be able to do that and I think the GitHub team was like, you know what? We'll let it stand for this one, so this issue lives on as this blank issue that does absolutely nothing, changes absolutely nothing and guess what it adhere to the style guide so I merged it.

Justin Dorfman: And that was the only merge.

Kelsey Hightower: I think that's the only merge, I think I did a Docker file or something.

Justin Dorfman: Nice.

Kelsey Hightower: I think inside of that Docker file you can go download it, I think there's still a Tar Ball up. If you download it and you catch what's inside, I think it says something like, are you serious? So it's like a little Easter egg in there. I don't know if I still lift it up, but there is something to download.

Tzury Bar Yochay: Have you begin releasing new versions.

Kelsey Hightower: We are code complete; I mean, I haven't seen a compelling feature to add. I think we nailed it on the first release.

Justin Dorfman: I agree, it's perfect.

Richard Littauer: So you all heard about the story, No Code is a great story is clear from the very beginning, what it is. You keep talking about going towards the future, or this is the future and I'm curious where you see Cloud Native going because you probably have a very concise story for that lined up and I want to hear what it is?

Kelsey Hightower: I just think any technology that's super successful has to get democratized. That the people who use it in mass shouldn't know how to actually build it, that shouldn't be a requirement. Like we want to see any technology see global adoption. Then it can't require everyone to know how to operate at the very lowest levels and so I think that's one challenge that practitioners have and remember this is early days of compute, at least in the style that we're practicing. So we assume that everyone needs to learn all of these low level details in order for them to be able to participate. So if you think long-term like when I was teaching my daughter how to code HTML website on the laptop, 1270.011, website comes up, Blinky tags, cool she's in geo cities. And at this point she's sharing the website where her friend 1270.011 doesn't come up, hey, something's broken. So this is like the inflection point of she's the future. Do I go and say like sit down, pick a Linux, distro, learn some Kubernetes, maybe in a couple of weeks, teach her how to deploy the website or I went to Firebase on her Chromebook. She did Firebase deploy, got a URL, gave it to her friend and it was working.

Richard Littauer: Yeah.

Justin Dorfman: That's like, as you said, it's like the geo cities of today. That's how I learned how to write HTML, I mean, I just did view source and just edited things. But still like and also another thing that happened for a generation is My Space and them allowing like people that weren't in computing or software engineers, they're just like I want to update my background so this is how I do it. And then some folks said, you know what? This is a great career path and take it. So I Firebase, thank you for keeping the geo city theme alive.

Kelsey Hightower: Yeah, if you're a tool builder, don't be discouraged by this we still need people to work on these tools. But we've got to remember that they're tools for creating things and sometimes people want to create things just because you can play the guitar doesn't mean you know how to make a guitar by hand. We just got to understand that's okay and we have to stop thinking that the rite of passage is that you have to build your guitar first before you can make music. So we just got to remove this idea, that's a requirement and just enable people. And then if someone really wants to learn how to build a guitar, then we show them how to do that as well.

Richard Littauer: Reminds me of an Arthur C. Clark quote, right? "Any sufficiently advanced technology is indistinguishable from magic." And it's kind of how I imagined the first people sitting around a fire hearing a guitar, what is this music coming out of this thing? Whereas the person who made it, it's like, well you can take a box and you put a hole in it and put strings over it. And so I kind of want to call you a magician now for your work with Kubernetes and building all these things and even for Firebase.

Kelsey Hightower: Yeah, I mean I would say magicians are cool, but teachers are better because the person that shows you the trick allows everyone else to be a magician for at least once. And then they can show someone else the thing and then they can graduate to becoming a teacher and I think that's the thing, right? Because the best teachers, sometimes you're right, sometimes you start with the magic show and you catch people's interest, you get them curious and then you say, I'm going to show you how to do the same thing. And I think that's like one of the keys to education in general, like how do you get people engaged? And a lot of times that's the way you do it.

Tzury Bar Yochay: It's actually open source showing how the magic happens, opening the source part of that closed source, which is actually showing you just the magic, right?

Kelsey Hightower: I wonder though, is that true a hundred percent, you know what I mean? Because I think if you look at the number of people who can really read code and then the smaller number of people who will actually contribute code and you ask yourself, is that enough? Because there's a lot of people who for example, I met a lot of system administrators and I was trying to teach them Go and their like, why do I need to learn Go? I said, look at your at Laptop, Dockers written in Go Terraform is written in Go, your whole Toolkit is written in go. So if something happens then you need to learn. The language is written in and for a lot of people, it really didn't click a hundred percent. So you're right, I think what you're highlighting is that there is a lot of power and seeing how things are made. But you're right I think people have to actually put a lot of effort today to actually capitalize on it, right? It's like imagine like this magical chemistry recipe that you need, but it's written book that's in German, you got to go learn German first, if you want to get the formula or find someone to translate it for you. And I think that's kind of the issue we have with code because when you go around the world, a lot of code is written in English. We kind of forget the fact that some people don't know English so even though we thought, oh they're just keywords, they don't know these words. So I think we still kind of have a high bar in terms of articulating, this is why I love when you see these diagrams about how things work and then like the philosophy behind them and high-level analogies. And say, hey, this code is just one implementation of these ideas and that's where I think we're missing sometimes because I remember I used to work with a bunch of developers and they say, the code is the documentation, I'm like, are you kidding me? This is not the same thing.

Justin Dorfman: Seriously.

Richard Littauer: Language is really fascinating to me and it's one of the cases of diversity that a lot of people don't think about, especially in our communities forget that speaking English is amazingly privileged. The majority of the world has a lot of issues coding, not just because of lack of access to say technology, but also because maybe their first language is Spanish and they have to learn all these different words or maybe it's something even stranger than that and less common on the internet.

Kelsey Hightower: So if you're listening to this and you're struggling, like why language is good for diversity, some people resonate with food better. Like you go and taste food from another country, it's like, wow, I would've never thought to put those things together, this is delicious. That's what diversity gets you when people are trying different things based on their own independent cultures. So maybe that would help a lot more people understand and maybe appreciate that diversity exists.

Richard Littauer: I like that metaphor a lot.

Justin Dorfman: I was going to just say, he's the metaphor king, like every time it's just like a quote.

Richard Littauer: What's amazing is the amount of work I can see behind those metaphors. You spend a lot of time thinking of ways to describe things easier, a lot of time thinking of how to be successful at communicating what you see and what your values are. Do you have any tips for listeners on how to do that effectively? Like how late at night you set up with a white paper coming up with those sorts of metaphors.

Kelsey Hightower: So the thing is like never at all, it's usually when I'm just talking to other humans. I'll look at the humanist say I'm talking to you as a person, what experience that I can pull from that we may only have like usually the best analogies are the ones you can relate to and so when you're looking at a person in your mind is doing this puzzle of like, who is this person? And if I want to kind of transfer what I'm thinking to them, what's the best way to do it? So I try to pull from these natural and you have to listen to, right? Like you said something around language and I'm thinking language can be related to food so you kind of pull these things in. So sometimes a lot of the analogies are kind of done on the fly and I have to remember to go listen and try to write them down. But yeah, I think I pivoted towards this when I started asking myself can learn how to tell the stories. When you watch a good movie, you really appreciate the story, the fact that someone came up with the story and held true to the story through the editing process.

So during my public speaking, I remember for the very first time, the last Cube Con I was in person, I believe it was Cube Con 2019. Normally I have a clutch when I give presentations and my clutch is the live demo. Even the live demos are hard, they're scary, they became my clutch. So I just used to always have one for safety, as weird as that sounds and then one day I said, you know what? Let the clutches go, that Cube Con no demo, no Laptop, no pictures, no slides, all you get this story. And then you really have to dig deep and start to find those things and the way I practice was just walking around the room and you tell some stories, you tell stories. And for me, the story is good is when you can feel something, when you look at someone else and they laugh and they decide that they want to cry or not, then their mood changes and that emotional roller coaster is dope. So when you're on stage and you see people on the ride and now you know that you can control where they go next, if the laughing you can give a hard pause and say but and then they're back and they can take them somewhere else and at the end of that roller coaster people wake up at the end and the natural human reaction is just a clap. So I'm learning how to tell the stories, that's it. So everything that I'm doing, I'm saying, why am I doing this? Usually that's where the stories come from, why am I writing this app? And then there's a story typically around why you're doing the thing that you're doing and if you learn how to tell stories, I think you actually be a little bit better at building things.

Tzury Bar Yochay: Is your next book going to be the art of public speaking second edition.

Kelsey Hightower: You know what I think I am getting a little bit better at it because for the first time, in a long time, I'm trying to actually work on it. And I think I'm able to work on it because I'm a bit more patient and I don't have my crutches, so now I'm finally learning how to walk.

Justin Dorfman: That's a bit of a blessing in disguise to have the year off pretty much because of the horrible COVID 19 outbreak.

Kelsey Hightower: I wish it was but you know one thing I'm looking at all these streams of information and what was that movie, Bruce Almighty and I remember he got this gift that he could hear what everyone was thinking to experience what God feels. And that is torment for most people and we don't realize it like, can humans really absorb all that information? We know our machines can but once you fill up the hard drive, you start losing stuff, things go down, you run out of I knows. You came to allocate the next block for the next piece of information and then what the computers do, they do weird things when the Colonel can't boot, because there's no way to lay out the partition table. You have corrupted storage machines don't work well so we reboot them and we reformat them and you got to do all of these things to them to keep them maintained. We haven't learned how to do that yet, right now, we're just hooked up to the firehose, sucking down everything with no regard to storage and permit in our cash and so I think for this time off, a lot of people almost had a little too much time off because when you have to go somewhere and come back, you're forced to stop and detach from the firehose. That went away, so I think for me, I had to learn like, hey, am I too close to the fire hose? And if I am, I need to have a better filter. So I think there was a little bit of self-reflection, I had a little bit more time to reflect on these conscious decisions that I wasn't making, even though I make a lot of conscious decisions. So I think that firehose, we're not going to understand the ramifications for that until people get back and detached from the fire hose because some people will start having withdrawal. Like that firehose, someone was dictating your emotions this whole time and it goes away and that void you're going to have to look around the real world and say, where am I going to fill it? That's hard for somebody.

Justin Dorfman: I'm kind of on the fence, actually no, I want to go back to events. But you have pole, can you get Oz Con back? Come on, you can just go to Tim O'Reilly be like, come on man let's just bring it back for the kids.

Kelsey Hightower: What we all forgot about what tech conferences was I think conferences started having way too many tracks.

Justin Dorfman: Yeah.

Kelsey Hightower: Obviously, they try to cover all the topics and we forgot that half the time all we want to do is hang out with people that we don't typically get to hang out with and learn from them, be patient. So if conferences do come back, I think we should just go back to maybe one or two tracks max, because there's something about shared experience. And at a single track conferences, the magic is the shared experience, because if you have lots of breaks, you can talk about your shared experiences and then we can naturally just make sure we don't need a hundred speakers, right? You can have people do once and then that was your time and open up for everyone else.

Richard Littauer: Or maybe the no track conference, a line of no code, right?

Justin Dorfman: I love that! Yeah, that'd be a great collaboration, oh my God.

Richard Littauer: I'll start a repo.

Justin Dorfman: [Cross-Talking43:10] no code and then just do a find a replace, if there's anything to find and replace.

Richard Littauer: Unfortunately, it is time for me to submit an empty PR to this talk because I think it was really excellent. And also to clap, thank you so much Kelsey, it was really great to talk to you. This was super great, where can people find you online if they love the words that you had here, where could they hear more?

Kelsey Hightower: At Kelsey Hightower on Twitter, my DMS are open. I don't get to all of them, but I do try to make time to comb them and really have conversations with people. So that's where you can find me.

Richard Littauer: Thank you so much. I think that's it, any final questions, anything else?

Justin Dorfman: I just want to keep going, why can't we just keep going?

Kelsey Hightower: This is dope, by the way I like this set.

Justin Dorfman: Oh, really.

Kelsey Hightower: Yeah.

Justin Dorfman: Oh, my God.

Kelsey Hightower: In terms of questions, one thing that I'm starting to learn is that having multiple moderators is a really nice pacing technique, right? Like I don't know where the question is going to come from, that keeps me kind of on edge. So I like the variety and then also the questions were super thoughtful and the more thoughtful the questions are typically you get more thoughtful responses, so thanks for taking me there.

Justin Dorfman: Oh my God, is this a dream?

Richard Littauer: Such a great guest thank you so much.

Tzury Bar Yochay: Kelsey I feel like I'm in a dream to be honest, you took us through this journey as you do on stage right here in this podcast and I'm sure listeners will get the true same experience, it's like a magic.

Justin Dorfman: Yeah, like magic, full circle.

Tzury Bar Yochay: That is Kelsey, we celebrate to have you, and we'll look for the next episode with you, hopefully.

Richard Littauer: Thank you.

Special Guest: Kelsey Hightower.

Sponsored By:

• Curiefense: Protect Your Cloud Native Applications ???? Try Curiefense today!