#54 May 21, 2019

Tech, Life, and KubeCon EU, with Bryan Liles

Hosts: Craig Box, Adam Glick

Bryan Liles is a Senior Staff Engineer at VMware, the program co-chair for this week’s KubeCon EU, a sought-after speaker, and a minority in an industry with few people who look like him. He shares his story with Craig and Adam, who also bring you the week’s news from KubeCon EU and beyond.

Do you have something cool to share? Some questions? Let us know:

Chatter of the week

News of the week

CRAIG BOX: Hi, and welcome to the Kubernetes Podcast from Google, from KubeCon EU. I'm Craig Box.

ADAM GLICK: And I'm Adam Glick.

[MUSIC PLAYING]

CRAIG BOX: First thoughts about KubeCon, this is a very, very big venue. There's three conference halls, and man, are they large. And that leads to lots and lots of echo.

ADAM GLICK: Yeah, so you have the main hall. You have the exhibitor hall, and we're here, in the hall of echoes. So it's fantastic for us to be here.

CRAIG BOX: How was your trip?

ADAM GLICK: My trip was great. Got to catch up with some movies. Finally finished "Bohemian Rhapsody" on the flight, nice middle seat the whole way. Met some nice people who are actually coming here, to KubeCon, as well.

CRAIG BOX: Brilliant. Now, I can give you a little update on the fox cubs in the backyard. They're looking a little bit scrawny, so we put a little food out for them. And mom was coming along and eating from the tray we had it in, and I think she must have just been a little upset that we weren't doing it regularly enough. Because I looked out the window at one point, and mom had picked the tray up and was walking off with it toward the back of the yard.

[LAUGHTER]

But we have another video I can link with the three cubs having a nibble, as well. So hopefully-- we're away from home for a week-- they'll survive, and they'll learn not to associate food with humans too directly. What are your themes of the week so far, as you've wandered around KubeCon?

ADAM GLICK: It seems that there is a lot of focus on CI/CD pipelines, deployment tools, along with and tied into multi cloud and hybrid strategy. Lots of folks talking about hybrid, about how do you put Kubernetes in multiple places, how do you deploy to multiple places, and really thinking about how do you set up your clusters and your applications in ways that are resilient to more than just the one cluster or one premises that you might be used to deploying them.

CRAIG BOX: Do you think that's a deliberate split, and that some people are targeting developers, and some people are targeting operators?

ADAM GLICK: That is an interesting question. I think that there is still a lot of discussion as to which Kubernetes is really a tool for. And I think the reality is that, over the long haul, it will be an operators' tool, and that developers are using it. But it will get more and more abstracted away. You'll have the developers that build it, but most people will take a look at what are the things that developers can do to build on top of it.

CRAIG BOX: Let's leave the hard questions for the interview and get to the news.

[MUSIC PLAYING]

ADAM GLICK: Last week, VMware announced that they were purchasing Bitnami to further their multi cloud strategy. Bitnami is mostly known for making a large catalog of open source software packages, available in the marketplace of the three major clouds. Bitnami states they will continue to support and maintain their application catalog, as well as augment VMware's offering.

CRAIG BOX: The Knative Project has released version 0.6. In a textbook example of the use of alpha and beta phases, the proposal has been accepted by the Knative community for the shape of the upcoming v1beta1 APIs. The new API will make the serving resources much more familiar for Kubernetes users, and the new APIs are available but optional in this release. Other new features include an overhaul of the scale to zero system and alpha support for automatic TLS provisioning using Jetstack's cert-manager.

ADAM GLICK: GKE Sandbox, previewed at Google Cloud Next last month, is now available in beta. GKE Sandbox uses gVisor, the sandbox container runtime developed at Google and announced last year at KubeCon EU. It allows you to run workloads in isolation from one another and is a great fit for user provided code. All you need to do is change the runtime class of your pod and have an extra layer of security applied to your application.

Also announced at last year's KubeCon Eu, by Craig, no less, was Stackdriver Kubernetes Monitoring, a tool that gives you GKE observability, metrics, logs, events, and metadata all in one place. That service is now generally available.

CRAIG BOX: The Helm Project has been marching to version 3 since episode 11 with Vic Iglesias, back in July, 2018. And this week saw the release of Helm 3 alpha 1. Version tres removes the TILA component, a cluster super user introduced in version 2. Instead, a user will now render the chart locally with the data subsequently stored in the cluster. This means RBAC and permissions are back where they should be. Helm 3 has been teased in a series of seven blog posts by maintainer Matt Fisher.

ADAM GLICK: GKE has announced release channels in alpha. The three release channels-- Rapid, Regular, and Stable-- will each offer different versions, maturity, and freshness. So you can subscribe your cluster to an update stream that matches your risk tolerance and business requirements. After it proves itself in the Rapid channel, a version will move to Regular and then Stable. The Rapid channel is available now, with the others to follow soon.

CRAIG BOX: Microsoft and Google both announced Windows Server Container support and preview in their hosted Kubernetes products. Microsoft has Windows Server Containers and Public Preview on AKS for Kubernetes 1.13 and 1.14, unless for some reason, you want to run them in Canada, where they're not supported. Google announced support for GKE running Windows Containers on clusters with version 1.14 on the new Rapid channel, which will be available in June, with a sign up form for early access if you just can't wait.

This week's AKS release also introduced shared subnets for Azure, which allows users to bring their own subnets to AKS clusters.

ADAM GLICK: Lyft has announced a bug bounty program for Envoy. Run through the HackerOne platform, bounties will be paid in relation to the criticality of the bugs found and submitted to Lyft and will not negate submissions of bugs to other implementations of Envoy from other vendors.

CRAIG BOX: Velero, the project formerly known as Heptio Ark, has released 1.0, in accordance with our prophecy of two weeks ago. Velero is an open source tool for backing up, restoring, and migrating Kubernetes clusters and persistent volumes. 1.0 brings a new, automated installer, as well as Helm support, and plug-in extensibility.

ADAM GLICK: Digital Ocean announced their Kubernetes service has gone GA, available in seven locations around the world. They've also added an integrated monitoring solution and have announced that they're working on a one click app deployment option.

CRAIG BOX: Speaking of easy deployment, Google announced Kubernetes applications are now generally available. Using the open source application CID to describe the constituent parts of an application, they can be one click deployed from the GCP Marketplace to a GKE cluster or a remote cluster connected to Anthos, in alpha.

ADAM GLICK: Terraform, the declarative multi cloud deployment tool, has always relied on a local file to store its state. Now, HashiCorp has announced the general availability of Remote State Management, a Terraform cloud feature, which provides state as a service. The feature is free for individual users and teams with additional paid features available.

CRAIG BOX: The CNCF made a number of announcements this week. There are 42 new members, including Kong as a gold member, taking the total to more than 400. A new online course on cloud native logging using Fluentd has been announced. And Open Telemetry has been announced as the name for the merger of Open Tracing and OpenCensus.

ADAM GLICK: MayaData's Open EBS storage project has been accepted in the CNCF as a sandbox project. Open EBS provides persistent block storage for containers and has recently hit version 0.9 with new features including vSphere and vMotion integration and low footprint versions for use in edge computing.

CRAIG BOX: Finally, the famous Kubernetes Podcast from Google Lightning Round! Harbor, the open source container registry, has hit version 1.8 with new features including OIDC connect authorization.

ADAM GLICK: Supergiant has released Supergiant's Kubernetes Toolkit 2.1.0. This toolkit brings new features, including the addition of Azure support, greater availability of deploying master nodes behind load balancers, and an experimental feature to import Kube admin backed AWS clusters.

CRAIG BOX: Datawire announced Ambassador, their open source API gateway, has released 0.7. New features include a move to CRDs for configuration, integration with Console, and new strategies for resilience and Layer 7 load balancing.

ADAM GLICK: Mirantis has announced a new BYOD. That's Bring Your Own Distribution, in this case. And as long as it's upstream compliant, Mirantis will support it. They also unveiled their latest service for managing Kubernetes clusters across cloud platforms.

CRAIG BOX: Banzai Cloud announced that the service mesh based on Istio is now part of their pipeline product, which can be run on-prem or in major cloud providers.

ADAM GLICK: Arrikto announced MiniKF, a slimmed down version of KubeFlow. MiniKF comes with Kubeflow version 0.5, a notebook manager UI, support for local and on-prem Kubeflow pipelines, and seamless notebook integration with pipelines.

CRAIG BOX: Gravitational has just dropped the release of Gravity 6.0. Get it? Which includes a multi cloud management plane, application catalog, order logging UI, and a monitoring dashboard.

ADAM GLICK: Cloud 66 announced enhancements to their Kubernetes-based PaaS, Maestro. New build from source features have been added, as well as maestro clusters, which deploy Kubernetes for you. Delivery tool, Skycap, also adds the ability to deploy to multiple clusters.

CRAIG BOX: VSHN, a Swiss develops company, has released k8up ('ketapp') which is a backup operator for Kubernetes. k8up is built on the open source Restic Backup Tool and stores its backups on any Restic supported storage. Top marks to them for providing the pronunciation, although we do think they missed a trick by not calling it ketchup.

ADAM GLICK: And that's the news.

[MUSIC PLAYING]

ADAM GLICK: Bryan Liles is a senior staff engineer in the Cloud Native Apps group at VMware and a program co-chair of this year's KubeCon events, starting with this week's show in Barcelona. Welcome to the show, Bryan.

BRYAN LILES: Thanks for having me.

CRAIG BOX: I've heard you describe yourself as a developer's developer, working in a space inhabited by ops people. Let's start by talking about your background with programming. I understand you learned to program by reading books on military bases?

BRYAN LILES: Yeah. So the way that this happened is when I was young-- and I'm talking 11, 12-- my dad was in the military. And he worked in military bases where they got some pretty crazy computers. He knew nothing about them, but he saw it was the future. So he brought home books and said if I learned the programming languages from the books, and I could prove to him that I understood it, I could get a computer. And so the books he brought home were C and Ada. So I just learned those, because I thought that was programming. And I proved to him that I could understand it, so he got me a computer.

CRAIG BOX: What type of computer did he get you?

BRYAN LILES: That first computer was a Tandy Color Computer 3, so the Tandy sister of the TRS80.

CRAIG BOX: I suspect that didn't run C or Ada compilers.

BRYAN LILES: No, it did not, actually. So it was BASIC. So guess what my second computer was? Tandy 1000 TL with the turbo button.

CRAIG BOX: That was the first PC compatible one?

BRYAN LILES: I think it was the second one. I don't think it was the first one, but it had a turbo button. I think it went from 8 to 16 megahertz.

CRAIG BOX: Wow.

ADAM GLICK: You were staying in the Radio Shack family there, I see.

BRYAN LILES: You know what? I grew up with people who didn't know computers and who don't know computers. There's no great engineers in my family. Radio Shack was pretty much it for where we grew up.

CRAIG BOX: But after that, was it a foregone conclusion that software was going to be your life?

BRYAN LILES: Yes, and for a couple of reasons. I'm tall, but not very athletic or very strong, and I'm allergic to outside. And computers are a great fit for how I look at life.

ADAM GLICK: Awesome. What language do you like to use, these days?

BRYAN LILES: Day to day, I write Python and Go, and then I write some TypeScript and JavaScript. Real talk, I can't say that I particularly like any of them. I wish I was writing software in Swift. I think that's the most exciting language, for me, these days. It just looks neat. And from a developer's point of view, it seems to hit all the right things. But I'm a developer. In the past two weeks, I wrote some lists, the other day. And then I was talking to someone about Prolog, so I had to write some Prolog out for them.

So I just like that I can type things into a keyboard and make computers do things. It doesn't really matter the language, as long it's not something like Forth or Fortran. I don't think like that.

ADAM GLICK: You've been an ops person, as well. What made you decide to shift from the developer side of things into the operations side of things?

BRYAN LILES: Oh, so actually, it's the opposite. I started out, as I would consider, an ops person. My first job was working in an ISP, back in the mid '90s. And I was supporting Apple, because I knew what an Apple was. And then I found out that I knew about Unix, so I became a Unix admin. And I'd always been developing, writing software. Even when I was in high school, I was writing Linux kernel drivers, because--

ADAM GLICK: As one does.

BRYAN LILES: --because I wanted my Sound Blaster card to work with Linux. So I've always had that ops point of view. I've always thought ops first. And I thought that everybody in the operation space should be able to develop. I was a little bit surprised when I became an adult and went into the real world, and I realized that ops people, at that time, didn't really like to write software. And developers were afraid of computers, and I've never been afraid of either.

CRAIG BOX: Do you think we can transition to a world where there's no difference between the two, development and operations?

BRYAN LILES: I think we're trending in that direction. I don't know if we'll make it in the next few years or not. There's this older generation, they're going to go away, and that's going to fade away. But I also think that developers need to be exposed to more hardware and understand when I start talking about CIDR, or I start talking about I/O, and then understanding what that actually means and how it affects our applications. It makes you a better developer, if you can do that.

Even more important than things like knowing algorithms for CS, know how your computer works. And then everything else will fall into place.

ADAM GLICK: Do you think it's possible that a lot of those things will get abstracted away at some point? It's funny. You used the exact example I always talk about. I said no developer ever loves doing CIDR rules. Like no one has ever been like, man, that makes sense to me. That is totally awesome. But it's super important when you get into the networking and how the things actually work. It's very important. And the ops folks live and breathe that kind of stuff, at least on the networking side.

So is it that it will get abstracted away, do you think, of those things? That'll just be handled as an underlying piece, or that developers will get deeper into those pieces and specialize?

BRYAN LILES: No, I think it'll be different. I don't think it'll go away. We don't think about interrupts much, anymore, at our level.

CRAIG BOX: Only if you're programming for your Sound Blaster.

BRYAN LILES: Yeah, if you're still programming your Sound Blaster, shout out to Creative Labs. But I think developers do need to know things like CIDR rules are important. I can't tell you the exact size of a 12, because I don't live in that world anymore. When I say a 12, 12 bits of network. How big is that? Yeah, I can figure it out in probably 10 seconds, if I wrote it down. But I still think that a lot of these things, like understanding the OSI model, when I say Layer 3, Layer 4, skip over Layer 5 and 6, because they're less important. But understand what the difference between a Layer 4 load balancer and a Layer 7 load balancer is. That's still super important.

Layer 1, as you know, has kind of gone away. We don't think about Layer 1, anymore. But those other layers, we still need to think about.

ADAM GLICK: You are a regular on the conference circuit, and it's clear why, because you're a fantastic speaker. How did you get into that?

BRYAN LILES: Oh, this is a funny story. So about 2006, I went to the first RailsConf, and I think it was in Chicago. And I'm watching these people on stage, and they're giving good talks. And I'm like, I could do that. And I go home. I talk to my wife, and she's like, you could do that. So here's a funny thing. I've only been a developer since 2006. Before then, I was just a developing system administrator. I could write software along with the best of them, but I never did huge application development.

So my wife says, well, you should go ahead and do that. And you should go out and do these things. So I submitted for a conference, and I got up on stage. And I talked, and it was good. I think the reason that my talks resonate is because I come to you as someone who's put in a lot of work to sound intellectual. But I think I'm no smarter than anyone else. I just think I work harder than most people, and I love to share. And then I love to share with people who will go out and share more.

So my talking has never been like this ego thing. You have a persona when you're on stage, because it's engaging. But it's always been about showing people that, hey, this black kid from Baltimore can go out there and talk about tech with the best of them, literally. And if he can do it with a little bit of work-- actually, a lot of work-- and some focus, you can do it, too. So it's always been about inspiration. And even now, here's a funny thing. I chair a conference-- the largest open source conference in the world. I actually do not like conferences, because travel, hotels-- it is seriously exhausting hanging around people all day. I am an introvert, but I do like the experience of seeing people give great talks. And I do like giving great talks, so I still do it.

CRAIG BOX: There's a talk of yours that I very much enjoyed. It's called The Darker Side of Tech. It was on unconscious bias and race issues in technology. It's obviously an area you're very passionate about. It's not something that everyone feels comfortable talking about. We'll put a link in the show notes for people who haven't seen it. But would you mind summarizing it?

BRYAN LILES: Yeah, so let me just put this out there. I'm black. I know that, because I have two black parents. I have black children. I look in the mirror. What society says is that, maybe not overtly all the time, but subvertly, tells me that I am less of a person. And I see it when I'm at an event where I can count the number of black males on one hand, [and I say males] because there will be no black females. That's amazing to me.

And what I've always done-- I'm not saying that I am super pro-black, but I'm not anti anything. What I'm trying to do is show that we should not use the situations that were handed to us, whether it be our race, or ethnicity, or something else as our defining focus, out there. You can be black and go do these things, even if you don't see the examples.

In The Darker Side of Tech, really, what I'm focusing on is that there is a lot of struggles for people who look like me to even get started-- not even be competitive, just to get started. You don't get the examples. Like my dad was not an engineer at Boeing when I was a little kid and brought home things. My dad was an enlisted person in the army, who just happened to see something. So what I'm trying to put out there is that through example, and through helping other people in many ways, be conscious of the things in the world. But don't let those things stop you.

People who don't look like me, what I'm trying to show you is that there are a lot of struggles. And I'm not telling you this because I want your sympathy. I'm telling you this because I think you're a good person, and I want to give you other things to shape your reasoning. And that's really all this comes down to is, hey, it doesn't matter what you are, who you are. As long as you have good heart, and you're diligent, you can do this stuff too. And then also, be extremely lucky. A lot of this is luck.

CRAIG BOX: So aside from that luck, what do you think we can do, as a community, to make life better for everybody in this aspect?

BRYAN LILES: I don't have an answer for that, unfortunately. Actually, I do have a small answer. The small answer is you can only directly affect people you can touch. So be a good example for the people you can touch. And then the people that you do touch, make sure that you tell them that's an example they have to set. So here's the thing that I do. I see on social media, where people are saying, like with the whole abortion thing, that we're going down to Atlanta. And everybody is giving out money and saying I'll match. And I was like, that's fun. That's cool, and I do try to give that.

But another thing I do is, just the last month, I saw someone giving away oscilloscopes on Twitter. So I went and bought a whole bunch of them. I didn't know how much an oscilloscope would even cost. By the way, it was really expensive. And what I did, I just said help me find people who either look like me or don't that could use this. And I just give them away. And the only thing that I say is that you have to tweet, when you get this thing, a picture of this. And say thank you, and make sure 5-10 years from now, you pay it forward.

So all we need to do, really, is if we can't control everyone-- and there's 330 million people in the United States alone, 7 billion people in the world-- but what you can do is, say you know a few hundred people, or you can influence a few hundred people, be good to them. And then say all you have to do to pay me back is go be good to 100 other people. And then through that, with the Kevin Bacon effect, we're only six degrees away from everyone.

CRAIG BOX: Fantastic.

BRYAN LILES: I have hope for the world, but I'm also a realist. I know it's not nice, so you got to be tough, too.

ADAM GLICK: You previously worked at Digital Ocean where you kept up with your speaking, and then you moved on to Capital One. What made you decide to shift from the vendor side of the equation into the actual corporate side?

BRYAN LILES: Me leaving Digital Ocean was not something that I wanted. I didn't get fired or anything like that, but really, I was at Digital Ocean very, very, very early. I can truly say that I helped build a cloud. And software that I wrote years ago is still a guiding light and leading projects. But the problem I have with Digital Ocean is there was no personal growth for me. Funny thing is I'm over 40. I was an old person at Digital Ocean. So when it came to looking for people to help guide my career, that wasn't there.

So I went to Capital One, because one, they paid more. That's pretty dope. But two, it was a problem that I could not solve by myself. What we were doing at Capital One, we made big forays into the cloud as a bank. And we were running a large amount of stuff in the cloud. When I say a large amount, take whatever you're thinking and multiply it by a hundred. It was large, and the spend was huge.

But what I liked about Capital One was that I got to see everything. So you want to see some Windows, they got Windows. You want to see vendor XYZ, they have four of that. But what I got to see is it was all at scale. And Digital Ocean was one kind of scale. We were operating all over the world, but Capital One was a different type of scale with regulatory compliance on top of that. And that was just something that I wanted to do.

And here's a crazy thing. My tweet about the issue is that if you don't feel challenged, you should move on in your life, or you should push yourself harder. I didn't feel super challenged at Digital Ocean in my personal capacity. And at Capital One, I got a different challenge. They made me a director. They gave me a team. And I still told them I was going to write software, and they let me. So I just wanted to do something different, and that's actually what got me to Heptio, but you didn't ask me about that yet. So I will wait.

ADAM GLICK: To close out on Capital One, did you get to meet the vikings?

BRYAN LILES: No, so the vikings are really old, by the time I was there. I didn't get to meet Samuel L. Jackson, either. So I was super disappointed about that. I said I kind of look like him, if you squint. So I was hoping to meet Samuel L. Jackson or even Jennifer Garner. I would've liked that, too. But it was a great experience. Here's a shout out to Capital One tech. For a bank, you all are pretty good. It's not perfect. It's not like VMware, or Google, or like a tech company. But those people over there get down, and they know what they're talking about. And there's some really smart people over there.

I actually loved working there, and I did not want to leave.

CRAIG BOX: Did they have Kubernetes at Capital One at this time?

BRYAN LILES: So yeah, they did. When I was leaving, actually, I was going to lead that up at Capital One. It was exploration into Kubernetes. There was a few groups running it and having some success with it. But I believe, and this is just all hearsay now, that they're all in on Kubernetes. And they're exploring ways to run many, many clusters. And I think they're having lots of success so far.

ADAM GLICK: Do you think that there's a change with many more of the companies that are actually end users of this becoming contributors and members of the community, versus just users of the software downstream?

BRYAN LILES: Yeah, it's funny you hit on this. So at KubeCon, I'm going to actually give a keynote on stage that has this tie into it. It's that we think about Kubernetes development, and we think about kubernetes/kubernetes and those things. But I want to say that five years in, it's actually something we need to start thinking different. We need to start thinking about the ecosystem more, and we need to start converting end users into contributors and owners of their own thing.

And there's so many different examples, and I think I have like eight examples of things that you can do as a developer, right now, to contribute to Kubernetes and therefore, the cloud native ecosystem. So we do need to focus on that. I don't think we're doing a great enough job, right now. But think about it. Kubernetes is five years old. I do know this fact that up until just a little while ago, Google was 80% of the contributions to Kubernetes. Now, they're like 40% and still doing a lot, increasing. And then you have Red Hat and VMware, even though I think we're beating out Red Hat, these days.

But what we need to do is we got to turn people from users into creators. And I think as Kubernetes becomes more stable, people are going to do that. But we saw that with Linux, too. A long time ago, you just downloaded your Linux. You weren't really into it. But now, everybody is contributing to Linux. And we wouldn't have gotten things like System B and all the great networking drivers if the community was not participating, as well.

CRAIG BOX: So you hinted at something, which you obviously knew we were going to ask. You moved yourself from a user to a contributor when you moved from Capital One to Heptio. Tell us about that career change.

BRYAN LILES: So I'm going to tell you this story. We all have failure moments in our life. My move to Heptio was a failure moment, but it worked out. I went to apply to another large company to be a dev advocate, because someone said that would be a good fit for me. And I went and interviewed, and they're like no. And not only were they like no, they were like no, you can't program. And I'm like, well, hold on. Someone on your team is using my software, because she told me. And this is one of the reasons I applied. She's literally using my software and said it was a great thing.

And I said all right, that's cool. And it's funny that Joe Beda at Heptio had reached out to me a year before, and he was like, you should join this thing. And I'm like no, dude. I work at a bank. It doesn't compare. So in my-- not my rage, but in my angst of failure, I was like, oh, let me go interview at Heptio just to make sure I really have that cred. Is this like a real thing?

So I just interviewed at Heptio, and I passed it. And I passed the whole process, and they gave me a project. And that's actually how I got to Heptio. It wasn't something I had set out to do, but in retrospect, it was an amazing decision. And I hold that to that as long as you try to live your life in this whole positive way and try to make every day better than the last one, even whenever you come across bad things like rejection from an interview, you just go look for a positive to offset that. And that's how I'm here, and that's why I'm at VMware, now.

CRAIG BOX: What was the project that Joe gave you?

BRYAN LILES: The project was called Ksonnet. And what Ksonnet is/was was a take on declarative management for Kubernetes. So this is actually a really hard problem, and I don't think anyone's solved it. So let's look at it. Well, I'll take it apart a little bit. So the community loves Helm. Helm just released their version 3 alpha 1, and people are going to be happy with it. I think it's going to do great things.

But the problem is that if we think Helm is going to solve all the problems, that means that we would never have any configuration manager tools like Ansible, Chef, Salt, or any of these other ones. We just would have solved all our problems with devs and RPMs, and that didn't happen. It's an important part, but we still need software out there that understands configuration at some level. And we can apply that configuration item potently, over time, to whatever we want to do.

So we started this with Ksonnet. So Ksonnet was based on Jsonnet, which is based on BCL, which is my theory that a lot of cool stuff comes out of Google. You all are great with the ideas. But really, what it was-- it was a way that we could use this Jsonnet language to define the state that we wanted our configurations to be. And we could use Ksonnet to generate a YAML that we would then apply to the cluster. And that's what Ksonnet was about. The problems with Ksonnet, though, are, as everyone knows, learning yet another programming language.

And Jsonnet is kind of lispy, but not really. But if you're a JavaScript developer or even a Java developer or a Python developer, the way that you would approach a language like Jsonnet just won't work, because it's immutable. And it's a little bit different. So what we did with that project is we didn't close it. But I wanted to turn it more into a research project, so we said that we're going to take a step back from it for a little while, so we can actually evaluate if this is even the right solution.

CRAIG BOX: Joe spoke to us in episode 12, and he compared YAML to assembly language. One of the things that, obviously, Heptio wanted to do was uplevel that, and Ksonnet was a tool for that. Do you think that there are other tools out there, today, that address that problem that helped guide the decision to transition Ksonnet to a research project?

BRYAN LILES: I think we're at the beginnings of this. So I agree with Joe 100%, and that's probably why I worked at Heptio. Because I do agree that working at the YAML level, and everyone's talking about the YAML, YAML, YAML, it is literally saying that I'm going to write this web app in Assembler. There's a reason why we've generated higher level languages. There's a reason why we have things like LLVM and spitting out IR that can be optimized separately. Because they're all good ideas.

And I think as we mature this space, we'll find more tools that will not work at the YAML level that are generating Kubernetes objects or Kubernetes manifests. We'll work at a higher level, and we'll actually have a lot more generation. And I don't know what that looks like, right now. This is actually one of my areas of research. What does this look like? But I will say there's tools out there right now that I like.

I like the idea of Kustomize from the Google team. And I was a little bit dubious about whenever it went in to kubectl itself. But we are humans, and we're elastic. And I got used to it pretty quickly. I like it so much that I wrote a version of it in TypeScript, because why not? If you want to learn something, just write it in another language. I like it, but the problem is that it solves a problem of creating and managing YAML. But what we need to do is figure out why do you need to know all these things about your pods.

If you're creating a deployment, and you know that you have some kind of pod security, and you have registry keys, and you have these other things, these things should be able to live. And you should be able to combine these together without great effort to yourself to create your actual deployment and your pod template inside of there. The problem with everything in Kubernetes, right now-- so I gave Google a compliment a second ago. Now, I'm going to go the other way.

It's a very Google solution. And what I mean by that is that it's great, technically. But when it comes to the masses, it's super opaque and hard to understand. Not impossible, there's just a barrier in getting that understanding.

CRAIG BOX: It's obvious, if people are going to be building things on top of it, there's a problem there to be solved.

BRYAN LILES: Yeah, so what I'm thinking now is that I love what Brian Grant and team did with Kustomize. I'm really friendly with all of them, and I really appreciate it. But I want to encourage people to say, all right, we started with people writing YAML by hand. We had a sidebar into Helm, and that's going to continue on. And now, we had Ksonnet, and we have Kustomize. And actually, Brian Grant-- you all should put a link to Brian Grant's declarative management thesis in the show notes.

CRAIG BOX: And his list of 45 different projects from two years ago.

BRYAN LILES: Yeah.

CRAIG BOX: It'll be a lot longer list if we did it again, today.

BRYAN LILES: Yeah, so that list-- and realize that there's definitely smoke there. So what we need to do is maybe we need to think a little bit outside the box and figure out not just solving the problem generating YAML, but figure out the problem of describing workloads that we're putting in Kubernetes. And notice, I say workloads. I'm not saying pods. I'm not saying deployments, or replica sets, or staple sets, or anything like that.

I'm saying describing workloads, and then allowing those tools, like your compiler would do whenever it generates IR or machine code, that it will figure out how to make it run inside of Kubernetes. We're not quite there, but that's something that we should be thinking about, as a community.

ADAM GLICK: How was your transition? You went from Heptio, which is a small company, very dedicated to Kubernetes and the Open Source world, into VMware, which is big, and there's lots of research. And it's a very different organization. How did that feel? What's that like?

BRYAN LILES: Overwhelming. Yeah, that would be the one word. So here's a crazy thing. I just realized this week that I've been at VMware for six months, now. And I know how VMware makes money. I know all the groups, but I don't really know how we make the sausage. There is so much going on, and there's so many people. There's tens of thousands of people that work at VMware.

So it's been a little bit of a transition, but also a little bit of a culture shock from going from this scrappy startup to this 20-year-old tech monstrosity. People are set in their ways on both sides. And it's not been hard, and there's really been no problems. But it's definitely a shock whenever you think about how we used to write software and how we write it now. Like little things, like you have in all organizations like I want to open source this thing I wrote last night before I went to bed. Now, you're going to go talk to four or five people at a big company, as opposed to, well, I put it on GitHub, last night. And it's got 20 stars, now. So somebody used it.

So that's a little bit of a difference, but none of it's been bad. It's just different. It's not bad versus good. I wouldn't even put it that way. It's just been different, but it's been a good different. And I think that this shows that we grew this energy and this feeling at Heptio and now at VMware. I went to the VMware conference last week. So I could actually talk about the Heptio way to the greater VMware company, and how we can apply some of the lessons we learned as a scrappy startup to a very well-funded tech company.

And all I can say is that it's been really good. I can say that, but hard at the same time.

ADAM GLICK: That's great to hear. So how did you get involved in KubeCon?

BRYAN LILES: I have some theories. Dan, over at CNCF, will probably deny all of this. But for years, when I saw Dan, I would always say to him, I don't get the CNCF. And he's like, what do you mean? I said, well, you're not picking winners. If a project gets into the CNCF, you've picked the winner. And he's like, no. We haven't picked the winner. I'm like, no. I think you have. And he's like, no.

And this debate lasted for, I think, a couple years. But I think what he saw is that even though I can have an opinion, I still believe in the vision of what the CNCF is doing. The day to day is whatever, but I believe in the vision of companies, and end users, and people creating software coming together and creating this huge community. So I guess he saw in all the juju I was putting out in the world about creating good communities and being good to people, but still being able to go and have a great tech talk. Like I can talk about something soft like The Darker Side of Tech, but I've also given talks on machine learning. And I can talk about the things that I'm passionate about, and I think he saw that.

And also, I think I'm pretty good on stage. So he liked that, too. So it all worked out. And I never really asked him the reason why. I just took it as, well, that's how it's supposed to be, dammit.

CRAIG BOX: Of course.

BRYAN LILES: That's where it is.

CRAIG BOX: Back in episode 29, we talked to Janet Kuo, who's your co-chair for the Europe event.

BRYAN LILES: Yes.

CRAIG BOX: And we asked her what she'd learned from her co-chair of the past, which was Liz Rice. What have you learned from Janet?

BRYAN LILES: There is a certain amount of pragmatism that is required when looking at 1,000 talks to curate a program. And what I've learned from Janet is just watching how she responds to situations, and looking at how she understands what a co-chair should do, and what the program should look like.

So I want to put this out there to the world. Yeah, it sucks when you don't get picked for KubeCon. It sucks when I say no to talks. It's actually kind of painful. But realize that in certain categories, we would literally see 150 plus submissions. And we have many, many categories. And for a particular track, we could get like 17, 18 talks in this track. And your talk could be phenomenal, but if there was 20 other phenomenal talks that were seen before yours, luck of the draw, unfortunately. It might not get picked.

So what have I learned from Janet? Actually, I've been following Janet for years. She doesn't know this. And so she'll hear this, and I will never say this to her in person. But she'll hear this when she listens to this podcast. I'm a fan. I'm a 6 foot 2 tall dude, and I think I've got almost a foot on her in height. But when she sits down, and she writes code, and I watch her on issues and watch what she's done for Kubernetes, she's a force. And I really appreciate that about her.

And then also, they keep me on my toes, too, because I always have my hands in 50 different things. And they keep me attentive to the things I'm supposed to be. So I want to give a little shout out to Janet and all the good things she's doing. This is her last KubeCon, actually.

ADAM GLICK: What do you think she's learned from you?

BRYAN LILES: Oh, that's interesting. One thing she probably realized is that I solve problems no matter what. So here's a crazy thing about conference organization that people don't realize. When it comes down to brass tacks in a lot of conferences, they're organized on spreadsheets. So imagine a conference where you get 1,000 plus talks. Someone is organizing that on a spreadsheet. And now, you take those 1,000 plus talks, and you have four to five reviewers, and we keep every single review separate.

So now, you have this speadsheet, this Google Sheet now-- it's even crazier, because it's a Google Sheet that has 5,000 rows, not all on the same sheet. But there's 5,000 rows through here. I just told them I wouldn't stand for that, so I wrote an app using the Google Sheets API to actually manage that. So what she probably saw for me is that we don't accept the status quo. The status quo is what it is, but it's only that because no one has changed it. So I always show her that we try to push the boundaries and always in a positive way.

So hopefully, she saw that from me and that she sees my enthusiasm for everything, like a little kid, sometimes.

ADAM GLICK: You've reviewed a ton of sessions, putting together KubeCon. If you were to give one inside tip to people who want to get their session submitted, who want to become a speaker like you, what would that tip be to make their session stand out?

BRYAN LILES: So the response to a CFP will make or break your talk. You have to realize that this is how we do it, and a lot of conferences do this, as well. So there's no way that Janet and I were going to read 1,000 plus talks, right off the bat. So what we do is we get a program committee. In the program committee, 100 plus people, we break it down into tracks. So you have to realize that people are reading anywhere between 90 and 150 talks over a couple of week period or a few week period.

So whenever you have space for words to describe your talk, make sure you talk about who the audience is, what you're going to talk about, and what the people are going to leave with. As a matter of fact, if you don't follow that formula, unless you're super well-known in some particular space or area, you will be skipped over. And it doesn't matter if your talk was going to be good or not, but the reviewers basically only have this evidence of what's written here.

And when I go through reviews-- this is the reason I wrote this tool-- I actually turned off who the submitter was and tried to remove gender stuff, too. So I didn't even know. I was just reading text. And I noticed that all the talks that were towards the top were, this is what I'm going to talk about. This should be the audience. This is what they're going to take away. And those talks are always rated higher.

And here's the most important thing. If you're going to an open source conference, no one cares about your software. No one's going to buy it. Do not sell to me. As a matter of fact, if I think you're selling to me, no. And here's the crazy thing about that. We all work for companies who are trying to sell something. There are ways to talk about that. We make more money by making the community understand that our passion for the projects that we are working on has benefits to them. And we can show that without saying here's the software that we charge money for, and we're going to talk about it. No, this is not your free thing. Have your own conference.

CRAIG BOX: Finally, your bio says that when you're not working, you build and race cars and drones. Which is more fun?

BRYAN LILES: So I like racing cars in a straight line. Like I like quarter mile. I do love--

CRAIG BOX: Not so fond of corners?

BRYAN LILES: No. So I was going to go through that. I do like quarter mile. It's easier to get that. I don't get to do it as much as I used to, but I do love going to road circuits and racing cars around there. It's an expensive hobby, so I don't do it as much as I used to. But I also like RC cars, too, because I just like things on wheels that go fast. And I have quite a few of those, and I have a few drones.

But my current project, now, is kind of neat. I see that Google, and Uber, and a few others, and Apple, I guess, are trying to build an autonomous car. And me, in my perfect world, am like, well, how hard can that be?

CRAIG BOX: George Hotz did it. He's just one guy.

BRYAN LILES: Yes! But I'm doing it on a smaller level. I've been working on autonomous RC cars for a little while. And now that I see that Amazon is now selling one, I bought that thing. It keeps me going, being able to do things that are still tech adjacent but not my day job. So I love writing software that makes things happen, and then I love cars. So writing software to make cars go around circuits by themselves is kind of like a nirvana for me.

CRAIG BOX: All right, Bryan. Thank you so much for joining us, today.

BRYAN LILES: Oh, thank you for having me. This was amazing.

CRAIG BOX: If you missed Bryan on the KubeCon stage, you can find him on Twitter at @BryanL, with a Y, or on the web at http://blil.es.

[MUSIC PLAYING]

Thank you for listening to this bumper show. If you've heard the show while we're still at KubeCon, please ping us on Twitter at @KubernetesPod. And find us, and come and say hello. If it's a little later, please feel free to tweet us, or drop us an email at kubernetespodcast@google.com.

ADAM GLICK: You can also check out our website, kubernetespodcast.com, where you can always find the show notes and transcripts of each episode. Until next time, take care.

CRAIG BOX: See you next week.

[MUSIC PLAYING]