#168 February 16, 2022

Rancher Desktop, with Matt Farina

Hosts: Craig Box

We’re back for 2022 with a look at Rancher Desktop, which recently hit 1.0. Its creator, Matt Farina, is today’s guest. Matt is a Distinguished Engineer at SUSE, was a founding chair of Kubernetes SIG Apps, and was recently appointed to the CNCF TOC.

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

News of the week

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


CRAIG BOX: We're back with our first episode for 2022. If you're a regular listener-- and I sure hope you are-- you'll know we've been on a hiatus while I get set up down under, or set down up under, whichever it is.

I'm mixing things up a little. and we'll be saying goodbye to guest hosts for a while. I'd like to thank all the previous guests who joined to host an episode last year, our producer Jimmy Moore, who sat in with me for several months, and of course, my good friend Adam Glick, who started the show with me, who is still sending recommendations of games and TV shows, even if he's not sharing them directly with you. If you listen to a podcast of Adam and Craig shooting the breeze about non-Kubernetes topics, do please let us on Twitter, @kubernetespod.

My mum might stop listening to the show if I stop talking to people about what I've been up to each week, but that's OK, because now she can drive over and ask me herself.

With that, let's get to the news.


CRAIG BOX: European developer jobs platform Honeypot has published a documentary on the history of Kubernetes. The hour-long, two-part documentary features interviews with people like Tim Hockin, Dawn Chen, Brian Grant, and Eric Brewer, and if you enjoy it, you should immediately go and check out the podcast episodes where we spoke with all of them.

Sysdig has published their "2022 Cloud Native Security and Usage Report." Their insights gathered from customer clusters include that 75% of images contain patchable vulnerabilities of either high or critical severity, and that you're almost certainly paying more to run your cluster than you need to. Tune into the show next week to hear more about the Sysdig report.

SUSE has lifted the lid on Rancher Desktop version 1.0. First announced at KubeCon EU last May, changes in Docker's business model in August saw the project get a lot more attention. The project uses Rancher's K3s distribution to provide Kubernetes on Windows, Mac, or Linux desktops. Listen to today's interview to learn more.

If you're a fan of the small, all-in-one binary Kubernetes experience, Red Hat has announced MicroShift, a 160-megabyte executable that runs the entire Kubernetes stack designed for OpenShift edge use cases. An early version is available to download and play with while they build out features like multi-node support.

If you're a fan of Docker's new business model, you'll be pleased to know the company has reported 4x annual revenue growth, and CEO Scott Johnston considers the new Docker a lasting, sustainable business.

In January, Solo.io announced Bumblebee, an open source project focused on simplifying the user experience for building eBPF tools. Bumblebee helps manage eBPF programs using OCI images, promising a Docker-like experience for automating their packaging and distribution.

Istio 1.13 has been released. This is mostly a maintenance release, but has a few new APIs for easier configuration of proxies and telemetry features. A call for papers for the second IstioCon is also underway. The event is to be held at the end of April.

Google Cloud Deploy, a CD product announced back in September, is now Generally Available. Deploy is a managed service that doesn't require care and feeding with delivery pipelines and targets defined declaratively and retained with each release. Security and audit features allow fine-grained control of releases, including to private clusters. Also now GA is GKE's Cost Optimisation Insights console, and Anthos Service Mesh is now supported in GKE's Autopilot mode.

The OpenMetrics project has been voted into the incubation stage in the CNCF. We talked about OpenMetrics with its founder Richard Hartmann all the way back in episode 37, three years ago, if you can believe. Since then, the project has published a stable spec and is currently going through the RFC process to become an IETF standard. Congratulations to Richard and the OpenMetrics team.

As one door opens, another closes. After the successful merger of OpenTracing into the OpenTelemetry project, the former has been archived in the CNCF. This step was planned as part of OpenTelemetry reaching the incubation stage last August. The CNCF have also recently announced a new whitepaper on Kubernetes policy management, and last week announced results from its 2021 survey, in which they somewhat shockingly suggest that containers in Kubernetes are quite popular with their audience.

And that's the news.


CRAIG BOX: Matt Farina is a distinguished engineer at SUSE and the initial creator of Rancher Desktop. He is a long-time member of the Cloud Native community, a maintainer of Helm, and was recently selected as a member of the CNCF Technical Oversight Committee. Welcome to the show, Matt.

MATT FARINA: Hello. Thanks for having me.

CRAIG BOX: Your bio says, "Matt has been developing software for over 30 years." What was the first piece of software that Matt remembers developing?

MATT FARINA: I started writing software back in elementary school. And my dad brought home this old Apple II. So that's what I first started writing software on. Out of the gate, I'm this elementary school kid who didn't want his parents to mess with what he was developing.

And I don't remember what I was developing. And it probably wasn't that interesting. But in order to stop them from messing with it, I wrote password software. So all of my code was password-protected so they couldn't go play around with or see what I was doing. That's the first thing I remember writing. I even remember that first password.

CRAIG BOX: Do you care to share it with many thousands of people?


CRAIG BOX: Fair enough. That's actually just triggered a memory for me, which is a little bit the inverse of that. We had, I think, a BBC Micro computer at the school I was at, and it had some password for some menu system. I remember figuring out that you could basically break out of that basic program and print the program, and then just see what the password was.

MATT FARINA: Ooh! Crafty.

CRAIG BOX: Do you think your parents could have figured that out?

MATT FARINA: My parents would not have figured that out.

CRAIG BOX: You say it was an old Apple II that they bought home. What was state of the art at the time?

MATT FARINA: They were just coming out with the early Macintoshes after the Apple IIs. And this was an Apple II Plus, so it was that second generation Apple II. After that, they had the C, and E, and those other ones that had color displays. And this was pre the color displays.

CRAIG BOX: Do you think there's going to be a big disconnect between people who were brought up with a computer that started at a basic prompt and encouraged programming from the beginning to today where you have to go to a lot of effort to get to that kind of environment?

MATT FARINA: I don't know. I'm an engineer at heart. And so I started as a kid playing with LEGOs and always wanting to figure out problems and construct things. My brain was always wrapped around, how do you create? How do you solve problems? How do you do this? I think today if I had the same environment, I would probably do the same things because there's so many more things you can build and create with than there was when I was a kid.

So it might have to do with your mindset. Are you into that kind of thing? Are you not? How approachable is it? I know those old Apple IIs you basically had to get into programming to do anything interesting. Today you can do a lot of interesting things without doing that at all. So I don't know.

CRAIG BOX: That passion for problem solving that you described there led you to Michigan State University, where you studied electrical engineering. Where did you go after that?

MATT FARINA: I got into electrical engineering because I had written software for all those years by that point. And I wanted to know how software ran on chips. I wanted to know how it worked in the hardware. It was that thirst to understand-- know how things worked.

When I got out of there, I was actually going to go work in chip design. Unfortunately, the company I was going to go work for-- I was going to enjoy my last summer in a college town. And right before school got out, the company I was in the hiring process to go work for closed down the office that I was going to go work in. Oh, that hurt!

I had plans to move to Chicagoland and all kinds of stuff. So I had to go find something new. And I ended up at General Dynamics Land Systems. This is a division of General Dynamics that works on ground vehicles, building military-type vehicle things. And I ended up in a division that did testability engineering, something that I knew nothing about before summer, and then after summer, I'm doing it. And so that was a really neat environment to be a part of.

CRAIG BOX: Was that predominantly a software job?

MATT FARINA: It was actually a hardware job to start. So when I started in this company, it was a hardware job. And that first job doing hardware working in diagnostics engineering was probably one of the most valuable jobs I've had in my life, because here I am this new guy who doesn't know anything about this. They had to teach me, and I got a chance to work with people who had been in the field for 20 years teaching me all kinds of stuff that I needed to know.

The other important thing was I got on to the vehicles with the end users. This was a job where there were military people who had to fix things. And I got on the job with these military mechanics. And they told me straight how things were. They didn't sugarcoat it. They were very honest.

CRAIG BOX: One can imagine.

MATT FARINA: And I got to see real end users who are dealing with real troubleshooting being totally honest with you and up front with you. And it was a great learning experience to see that difference between theory and reality.

CRAIG BOX: Had troubleshooting military vehicles moved on from the "hit it with a spanner" approach?

MATT FARINA: A little bit, but not much. Then after that, I did move into a couple of other positions there. And I ended up in a software job. Because I'd done so many years of software, I ended up gravitating back towards it, because I like regular releases. And when you're talking about other stuff in that space, it might be a 5- to 10-year design cycle before you see a release. I couldn't handle that wait. I needed regular releases for my sanity.

So I ended up in a software job there. And that's where I ended up gravitating more towards open source software. And then other jobs since then.

CRAIG BOX: Tell me about your first experiences with open source then. You were working with the Drupal CMS, I understand.

MATT FARINA: I was. My first experience as a user actually go back to the '90s, well before that, when I just picked up and I used Linux, and I ran open source software. But then I got into contributing to it, because there were two things going on at that time. And I was working at General Dynamics at the time. I had a friend who was not a software guy. He needed some software.

And this is at the point where WordPress had only been around for a year or two. It was really fresh, and it was only for blogging. You weren't going to do anything else with it. The extensibility wasn't there.

Drupal was a dorm room project that was growing in popularity. He needed some stuff for his job, and things like that. And he was a good buddy of mine. And so I wanted to see him get those features in some kind of system. And we started off pre-Drupal with some libraries, then we ended up getting into Drupal.

At the same time, I'd also written a couple of software frameworks along the way and software libraries, and they were always proprietary. So often when I needed something, I'd go look in open source land, and it wasn't there. There was a lot of low level stuff. You get like the GNU applications that have been around for years. But that higher level stuff that we're trying to go for just didn't exist.

And I didn't want to keep rewriting each of these myself. I wanted to see an environment where there were lots of things. I decided to start contributing where it made sense to try to build some of that up, both for my own consuming uses, and to help a buddy of mine out.

CRAIG BOX: Were you looking at things like the GNOME and the KDE Project at that time?

MATT FARINA: I was. But a lot of the stuff we dealt with at the time was web-based, so that didn't really fit. And we were looking at a lot just in the web space because it was marketing or just different platforms, dynamic content. Static content wasn't too hard in HTML, and just the tools at the time.

But dynamic content was so often proprietary. You had to fork over a lot of money. And for a small independent business owner or somebody dealing with nonprofits, they really wanted something that was more cost effective for them.

CRAIG BOX: Later on you ended up working for large enterprise IT companies, but in their open source divisions. How did you see that change as those companies went from fully proprietary to adopting, and then evangelizing open source software?

MATT FARINA: Some of those companies actually did a fair amount in open source that people may not have realized. So I ended up going to a couple of small consulting shops. First one of them, palantir.net is still around. Then I ended up at Hewlett-Packard before it split into HP Inc and Hewlett Packard Enterprise.

HP did a lot with open source. In fact, there was a point where there were patent disputes around Linux. And they actually donated their patent portfolio to support that. They said, we'll back Linux with our patent portfolio here, because they were doing so much with open source. I just don't think it got a lot of voice.

In my time there, I worked in a couple of different divisions. Everything we did was really targeted around open source software and building and doing business things around that. I just kept seeing that open source stuff rolling, and that has continued to today.

CRAIG BOX: Was that an alignment that really went well with your personal beliefs, as well as the practicalities that you were talking about of being able to help out your friends?

MATT FARINA: It did. I'm really somebody who likes open source software. I like sharing those solutions. Quite frankly, I like being able to put something out there, and then reuse it for so many different purposes. And just seeing how people can pick this up, and use it in different ways. That's something that just delights me. I've actually targeted working for companies that let you do that and prioritize it just so that I have a personal synergy with the companies that I'm working for.

CRAIG BOX: Where did cloud native start becoming a thing that you were involved with?

MATT FARINA: I started doing cloud native stuff in what we modernly call it probably before Docker was a thing. Back when I was at HP, we picked up a Cloud Foundry distribution called Stackato and were using it. It was a Cloud Foundry distribution, which is very similar to a Heroku style platform.

You have a container engine. You've got container orchestration. And then you just have that front-- a lot of people do it in CI now where you take your application and turn it into containers, which is what the front end of most PaaSes are. And we were doing this in cloud native ways across multiple regions very early on.

That's really when I got bit by cloud native, and just the potential for density of your workloads running there, and just all the different things you can do dynamically with spinning up more containers, spinning them down, and doing that kind of thing. That began my road of looking for other places that it could apply, which ultimately when Kubernetes came out, I just was like, ooh, this is the next evolution of the engine that was already there that we were used to, and I jumped on board.

CRAIG BOX: You mentioned the Cloud Foundry and Heroku. Was there a perception that Cloud Foundry was more a commercial technology, and when Heroku came out it was what all the cool hipster web kids were using? Do you think that the technology existed somewhere, but it was really the publication and the promotion of it that helped cement Heroku in people's minds as the tool for this task?

MATT FARINA: When I look at Heroku-- and granted, this is just my random guy on the internet's opinion-- it's that they solved a problem. People want to take their code, and just make it easily accessible, and just have it run. People who are interested in their own code don't necessarily want to spend a lot of time dealing with the operations. It takes away from that time of just dealing with that thing that they care about. And Heroku just made that easy.

Cloud Foundry originally built on a lot of the same technologies, LXC containers and things like that that Heroku uses. And so they kind of created this other offering. And it was open source. When I was using it, I tried to pick it up and build it myself, but I didn't want to have to deal with the operational aspect, which is how we ended up where we did. How do we make that easier so we could, again, focus on our code?

And I think that's the problem it solved. I know Heroku really picked up with certain crowds. And they ran wild with it because it just made their lives easier. And that's something that I appreciated.

CRAIG BOX: You mentioned there a focus on making code accessible and running. That's not something that Kubernetes did out of the box. Kubernetes could take containers and keep them up and scale them and so on. But the part from the code to the actual container was either the domain of Docker or the tooling that came along later. What did you see as the path to get Kubernetes to be as easy to use as some of those other platforms that you've used before?

MATT FARINA: So I don't think Kubernetes is as easy to use, and I don't think it's meant to be. If we take something like Cloud Foundry and compare it, Cloud Foundry has an engine behind it called Diego, and it has a container runtime called Garden. And then they have something in front of it that converts it into that. And Kubernetes is sort of like that garden. It's that engine under the hood.

As far as that ease of experience, that's something that we're hopeful that people will build as an add-on on top of Kubernetes. You've seen more libraries come on top of it or application stacks to help with that, some things like Knative, and then you can build upon those. We're kind of hopeful that people will build on top of it to build those better experiences.

But Kubernetes itself is kind of like the Linux kernel, or something like that. And so how do you build those experiences? People had the GNU Linux. And that got people so far, and they were somewhat happy with it. And some people like the low level. But then you pick up something like Android, or you pick up something like Chrome OS. Those are both very easy environments with good GUIs and desktops.

And so now we've got all these different kinds of environments on top of it, whether it's KDE, or GNOME, or Chrome OS. And different people can pick it up and run with it. And they've built on top of it by extending it. I think that the powerful thing about Kubernetes is under the hood– they all have that similar engine. And that's where Kubernetes sits in the stack.

CRAIG BOX: But I do think people use the word Kubernetes in the same way that they use the word Linux, which is sort of interchangeable with the kernel and the ecosystem of things that all come on the plastic disk, or however it is people get their Linux these days. There is a concept that people want to run Kubernetes, but that's not enough. They need all those pieces that are on top, like you mentioned.

MATT FARINA: Yeah. I think Kelsey Hightower is the one who pointed out that people say, I just want to use Kubernetes, and then they build a platform on top of it. And there's a lot of people who've built their own platforms using CI toolkits, some of their own custom software. So you see a lot of people building their own platforms on top of it in order to get to that easy, "it just runs" environment with Kubernetes underneath, because, as most people have found, Kubernetes isn't enough. And there's a whole ecosystem. Go look at the CNCF landscape--

CRAIG BOX: Oh, please don't.

MATT FARINA: --You're going to see so many different things.

CRAIG BOX: Please, save yourself.

MATT FARINA: [LAUGHING] Part of that is, because people have created so many of their own platforms and tools to be on top of that in order to solve that space. Because where you had things like Heroku and Cloud Foundry before, you don't have that one champ or that couple of champs who are everybody's going for. People are creating their own platforms to solve those same problems.

CRAIG BOX: One thing that you could almost call a champ in this space is the Helm project. You're a maintainer of Helm. How did you get involved with that project?

MATT FARINA: I had been following Helm for a while. I was co-chair of Kubernetes SIG Apps. Helm was a project at the time that was under SIG Apps. It was part of the Kubernetes project as a whole. It hadn't yet spun out to be its own CNCF project. I'd gone to work at a new company. And my boss said, hey, you should start contributing.

As part of contributing to it, I said, OK, what can I go pick up? I know most of the maintainers. Where can I get in? And I ended up just with the easy thing. I went into the charts. Before there was Artifact Hub where you could go search for distributed charts or packages to go install with Helm, there was the charts repository, where the Helm project kind of maintained this growing sprawl. It grew from like a dozen to hundreds, which was just a maintenance burden. And most of it was manual.

So I decided to come in and just start automating a lot of the repetitive manual tasks. And I got involved with Helm then. And I ended up as a Helm maintainer just for the charts area. And then eventually I said, OK, I'm doing this. I'm going to go get involved with the Helm client, the main Helm project. And I started contributing there.

Of course, I was pulled in with some friends of mine. Matt Butcher twisted my arm. He's twisted my arm on a lot of things over the years. And he twisted my arm to get more involved there. And so I got involved and became a maintainer there. And then it just kind of continued.

And I'm still a Helm maintainer involved in the day to day because that's a fun project that for so many people, it makes their life easier, right? They don't have to know how something like Postgres works in order to get it running Kubernetes. They don't need to know the Postgres business logic and the Kubernetes business logic to get it to work well. They can just install a package and have it up and running as easy as you might with zipper or apt on your Linux distro.

CRAIG BOX: One of the things about those Linux tools which allow you to install software is they do it from a central repository. It was the chart's library, as you mentioned. But you also mentioned the Artifact Hub, which is a project that you had a big hand in as well, I understand.

MATT FARINA: We had the Helm Hub, which is where you could search for charts. But the software it was built on was designed to mostly be run on premise and for a handful of repositories for people who ran their own Helm chart repositories. And we tried to scale that up to handle lots and lots and lots of repositories. The scaling failed. It wasn't designed for it. And we knew we had to redesign it.

And when we started to look at redesigning this in Helm, there were other things that were happening-- the operator hub. There were other hubs starting to pop up. Dan Kohn, who had started the CNCF-- he was the head of that for a long time. He had this idea of people shouldn't go to a lot of different hubs. We should have one place people can come, and they can search for things, and they can see related things. Let's make discovery of this stuff easy without you having to discover all the hubs.

And that born out the idea of Artifact Hub. He twisted my arm and got me involved in it then to try to help build that experience out to be able to just discover things. And since then, it started with Helm charts, but operators. And we recently added support for container images. So people can get their container images listed at all these distributed repositories-- GHCR for GitHub, or if you've got something in Amazon or in Azure somewhere that's public, you can get it listed there. And then people can search and discover these distributed things because we're just trying to do that.

CRAIG BOX: I know there is WebAssembly Hub, a different project. Do you see WebAssembly modules as being something that would eventually become an artifact?

MATT FARINA: I can see that. I have been talking with some of the folks in the WebAssembly community. Some of this is going to depend on where they land in nonprofits and how it goes. But that is one of those things that I personally would like to see just to help make that stuff more discoverable, especially since there are now projects where you can have Kubernetes schedule and run your WebAssembly. So there's neat things or there's synergies between this stuff.

CRAIG BOX: You then went on to work for Rancher Labs. And you were there for four months before it was acquired by SUSE. Did you know it was coming?

MATT FARINA: It was already public that it was coming.

CRAIG BOX: There we go.

MATT FARINA: And so, yes, I knew. I had been a fan of Rancher. And I knew about SUSE. And I knew people there. The deal was already announced. And so I came into Rancher full well knowing that the merger was going to happen.

CRAIG BOX: Tell us a little bit then about SUSE for people who are familiar with it as being a Linux distribution from Europe in the '90s through to the enterprise company that it is today. Obviously, by acquiring companies like Rancher, there's a big stake in the ground and the place in cloud native. What can you tell us about SUSE's offering and ambition in this space?

MATT FARINA: I hadn't been following SUSE for a while. And so when I knew about the acquisition, I had to go out and learn. There's a lot going on there, right? SUSE is innovative, reliable, and secure enterprise open source solutions. And you'll see SUSE is an open source company to its core. We're relied upon by more than 60% of the Fortune 500 to power the mission critical workloads.

I've learned about things in places that I didn't even know about that are mission critical and useful. It's been an enlightening experience. We specialize in business for critical Linux. Where do you really need that? Enterprise container management, you can think of Rancher and all the stuff around that, and edge solutions. And we collaborate with partners and Kubernetes to empower our customers and to innovate everywhere.

So that's kind of what we're into at this point. You'll kind of see Linux, especially when you really need to rely on it, container management and edge are kind of the big areas we're going at. That's really a lot of what I know about SUSE now.

CRAIG BOX: We spoke with Darren Shepherd who was CEO of Rancher as an independent company a couple of years ago now. What has changed in the Rancher product lines since SUSE's acquisition of them? Perhaps aside from changing the underlying Linux distribution, has there been anything substantial change in the way that Rancher as a division of SUSE operates?

MATT FARINA: So when I look at Rancher as a division of SUSE, I think one of the things that we're actually seeing is a lot of innovation. So Rancher, when it was an independent company, did some things like Rio, and Longhorn, and a number of different projects as it tried to grow in that space. I see more of that innovation happening now.

In fact, if you go to opensource.SUSE.com, you can see there's a bunch of open source projects that we're working on. In the container space, there's Rancher desktop. There's Epinio. There's Kubewarden. We've got a bunch of new projects popping up as we try to figure out what are the issues people are seeing, what are the roadblocks, what kind of business problems do they have, and then what in open source can help try to solve those? And so we're doing a number of really interesting things in that space. I think more so now that Rancher has come under SUSE than it was able to do on its own before.

CRAIG BOX: One project that Rancher has been working on is the Rancher Desktop, which recently launched 1.0. Congratulations on that launch.

MATT FARINA: Thank you.

CRAIG BOX: Is it fair to say that the impetus for this project was the change in Docker's business model?

MATT FARINA: No, actually. The reason for that is, if you go back, Rancher Desktop started before Rancher formally became part of SUSE. When I came into Rancher, not long afterwards, maybe a month and a half, that's when the idea started for Rancher Desktop. We wanted to make Kubernetes on the desktop as easy as container management on the desktop.

And so that's where we started with-- how do you make Kubernetes easy as a desktop app? Because most of the tools out there that people pick up are terminal apps, right? You've got to drop into the terminal. You're dealing with lots of switches. There's just a lot of cognitive knowledge you need to learn in order to work with those effectively. The features and everything, it's not that discoverable.

And some people love jumping into the terminal and working through those things and pick them up. And that's wonderful. But as I've learned, more than half of developers have been in their professional careers less than 10 years-- a majority of that less than five. So they're in this world of learning. They're in this world of writing lots of code. And could we make that experience easy to discover and work with with Rancher Desktop and Kubernetes on your desktop in your local environment? That's really where it started before any of the changes with Docker Desktop had come to light in any way.

CRAIG BOX: When you say the goal is to make Kubernetes as easy as container management on the desktop, I would say that's not a very high bar. Container management was still very much tooling in the command line that you had to run. Are we looking here at just meeting that bar or are we looking at a full desktop experience?

MATT FARINA: We started with the low bar of going out, because we had to figure out how do you make it run on Windows, Mac, and Linux, and deal with all the little quirks of each platform. Networking is different. The way you have to run the virtual machine is different.

CRAIG BOX: The slashes go the wrong way.

MATT FARINA: The slashes go the different ways. So we started there. But we do have aims to make it better. And we don't even fully know where all those aims are going to be, because we're getting feedback constantly from people as they pick up and use Rancher Desktop. And they say, ooh, we could use this. And then other people come in and say, ooh, we could use this, too. And so listening to people as they're using it and understanding how are they using it, how are they doing things maybe a little differently than I originally had expected, or I would have done it-- making those changes, incorporating features.

In fact, that's where originally it was just Kubernetes, and you couldn't build containers. But then people said, ooh, we want to build containers without pushing or pulling them to a registry. We want to just run them in Kubernetes. How can we do that? And so then we had to start figuring out, how do you build containers? And then some people say, hey, we want to also run these containers before we integrate them with all these Kubernetes manifests in order to see what it looks like. Does it come up on the port? Are things working right? And so running containers.

And that's where it led us to expose more of containerd. And then there was nerdctl, which is a Docker-compatible CLI. And then because that didn't have quite all the features that people needed when building and running containers, we ended up bringing in the Docker CLI and dockerd via Moby. And we made it an option to switch back and forth.

And so it was really listening to people to try to figure out how do we enhance the experience. But again, right now, I'm talking all about command line tools. And so we do have aims to make a lot of this experience easier and more discoverable.

CRAIG BOX: You've mentioned there are a few things that come about through discussion with customers and the feeling that you need to add features on that maybe you didn't come up with yourself. What did you think coming into this the table stakes were for this kind of product?

MATT FARINA: When I originally started, I thought the table stakes were along the lines of something like kube-solo, which was a project years ago for Mac that lets you run Kubernetes on your desktop. And it gave you a nice UI to configure it and the ability to get to some dashboards. I thought kube-solo would be a good model to go with, just that idea. I think it was only Mac back in the day. And so for me that was the original table stakes.

But I think there are a lot more people involved in Kubernetes who aren't so into the Kubernetes community. That small fraction, we see all these contribution numbers for Kubernetes, and these people involved. And that's just a small fraction of the people who interact with Kubernetes now. They have different expectations than people did maybe five years ago when they were using the other project, because their job is different. The way they interact with it is different. Now, instead of being a community they're invested in, it's part of their tool chain, and they're not going to get so invested because they're working on their stuff.

CRAIG BOX: Of course.

MATT FARINA: I think Kubernetes and container management was that table stakes.

CRAIG BOX: When a developer sits down to write code, they're doing it in some kind of editor or an IDE. Is there a place for something that goes between that and deployment, or do you think that ultimately a developer, as opposed to an operations person, wants to be able to just hit buttons in their IDE and have the process work for them?

MATT FARINA: I think you're going to get some of each. There's such a diverse culture out there. Some people are going to want some of each. I've been using Visual Studio Code recently as my editor because I want to be in that same experience that most other people are so I can experience the same tools and environment that they use.

There's add-ons to VS Code that will let you interact with the Docker runtime. And that was one of the other reasons we wanted to have dockerd there, because it talks directly to the socket. Having those tools now work with Rancher Desktop lets people code inside of Visual Studio Code and yet still be able to build their containers, and compile their code, and work inside of that environment. And so there's that flow.

But then there's also people want something in front of it, right? That's why Heroku and Cloud Foundry, they want that tooling that does stuff for you. We've done some experimentation and some work in that area. For example, there's another project we're working on called Epinio. And Epinio is working to fit in front of Kubernetes to try to help you do those kinds of things.

CRAIG BOX: Do you think that the implementation that you use for that interaction will remain the Docker API and socket and executable? Or do you see a world where the container ecosystem or the Rancher Desktop ecosystem implements all of that stuff natively and you have a Rancher plug-in for VS Code, for example?

MATT FARINA: Maybe. That's a little further off. We haven't planned that far ahead. To re-implement so many of those Docker tools, to do that, that's a lot of work. People have put a lot of time into creating those tools. To try to re-implement those for containerd or for our environment is a lot of work. And you can see that nerdctl, the Docker compatible CLI, it's taking them a long time to build out all those same features that the Docker CLI has.

I expect someday we're going to see more and more and more of that, especially the most useful ones. I'm just not exactly sure when all these things are going to meet, or what that will mean for changes in Rancher Desktop. For now, though, I think we're going to keep dockerd around.

CRAIG BOX: I'm impressed at the effort you go to not to call it "nerd"-C-T-L.

MATT FARINA: [LAUGHING] So I called it nerd-C-T-L in the beginning, because that's how it reads. I'm like, nerd-C-T-L.

CRAIG BOX: Exactly.

MATT FARINA: But I was corrected. They go, "with container, it's container-D. Take the end of that, and so it's ner-D, just like the end of containerd, control." And it took me about a month to make that change myself.

CRAIG BOX: This will, of course, end up with a debate about where exactly we put the syllable breaks in the word Kubernetes. But let's not go there today. [CHUCKLES] What choices have you made in Rancher Desktop not to do something?

MATT FARINA: One of the biggest ones that people have asked about is we didn't put Rancher in Rancher Desktop. There's Rancher, which is your multi-cluster Kubernetes manager, and Rancher Desktop is a local Kubernetes environment, which are mostly entirely separate code bases and functionality. Lots of people ask, why don't you put Rancher in it? Isn't Rancher in it? That was one of those intentional things we decided not to do.

CRAIG BOX: There is a lot of brand equity in K3s, which is the engine the powers the Kubernetes in Rancher Desktop. Was there consideration given to it being K3s Desktop?

MATT FARINA: No. Because, really, when you look at it, K3s is a distribution of Kubernetes. It's API-compliant, just like so many other distributions. And so the idea was is if you build something that works with compliant Kubernetes and it happens to be K3s here, you could take that to one of the public clouds and their Kubernetes environments and run it there. You could take it to RKE, or any of these other kinds of Kubernetes engines that are API-compliant. And it should run anywhere. So we really wanted to call out the fact that this is Kubernetes in general.

CRAIG BOX: Darren Shepherd didn't try and name it something like r12p?

MATT FARINA: No, he didn't.

CRAIG BOX: We kept him away from that? That's good to hear.


CRAIG BOX: Where would you like to see Rancher Desktop go? What use cases now after your 1.0 are you perhaps looking to take off the backlog or what would you like to learn from people about how they are using it?

MATT FARINA: We really just want to make it work in more environments. When you deal with Mac, Linux, and Windows and all these different Linux distributions, there's a lot of quirks and nuances. And so we want to try to help things work better in all of those places around some of those quirks and nuances, corporate VPNs, just little things all over the place. How do we do that better?

But we also want to expand on the use cases, right? There are some people who say, I want to turn off K3s that you include, and maybe use K3d so I can create more than one K3s cluster for my different situations. Can you make that possible? And that's something we're working on to make possible.

There are people who want to have maybe a way to peek inside and visualize what's happening in my environment. So as I'm developing, I can see some of that. And we're working on some of that, too. Our goal, really, is how do we make that developer's experience better? And of course, we're a Kubernetes company, so we keep Kubernetes in mind, but we also do containers. How do you make that experience better, and easier, and more discoverable? We're going to look for features that kind of help with that.

CRAIG BOX: You mentioned before that you were a co-chair of Kubernetes SIG Apps at one point. And you have recently been selected to be a member of the CNCF Technical Oversight Committee.

MATT FARINA: Yeah. That was a real honor to be selected for it. And I know it's going to be a fair amount of work. Back in Kubernetes, I was one of the people who started SIG Apps. And I did it for years. It was five or six or more years. And along the way in there, I also served as co-chair for SIG Architecture for a while as well. And so I got to see what it's like to chair and be involved in one of these complicated things-- the time commitment, the kinds of things people look at you for.

Sheng, our President of E&I, who was the CEO of Rancher, was on the TOC until recently, when we had this turnover, his two-year term had ended. Some people had bugged me. Hey, you've done these other things. You should run for the TOC. And I said, OK, OK, I'll think about it. And so I said, hey, Sheng, what's going on here? Some people have bugged me about this. And then he told me, you should run for the TOC. At which point I thought, OK, I'll do it.

CRAIG BOX: Twisted your arm.

MATT FARINA: My arm's twisted, and I'll run for it. And I think it's really exciting, because the CNCF has such an opportunity to try to improve the complexity and figuring that out. We talked about the landscape earlier, and just how it's-- the icons are so tiny now because there's so many things. And how do you decipher it? And there's so many projects going in this space.

There's a lot of room to encourage healthy projects. For all these different use cases and situations, people are coming in to figure out, how is it more discoverable, the kinds of things that I should look at, coming in not knowing a lot about it.

CRAIG BOX: That's interesting that you point out so many people are new to this space. And it's easy for people like you and I, who have been around for a long time, to say, hey, sure, we know how it all came about. But presenting this information to a net new user who just wants to write code and is told there's Kubernetes at the other end of it, perhaps, feels like a very different experience than perhaps what we're used to ourselves.

MATT FARINA: That realization I can credit Brian Grant for, who's over at Google, and was one of those early engineers on Kubernetes. We were chatting once. And he pulled up the technology adoption lifecycle curve. And I'm thinking, yes, Kubernetes is so far along. And he pointed out the chasm and said, this is where Kubernetes is at.

And he reality checked me at the time to say, hey, look. Look how much earlier it is than most of us who are caught up into it are at. And I think now it's much further along in that technology adoption lifecycle curve. But so many enterprises and other companies are just coming into it now that there's just so many new people.

CRAIG BOX: Talking to Brian yesterday, he's always got docs about the configuration management systems and the high level things that need to be built on top of Kubernetes. He was on the TOC and SIG Architecture like yourself in the past. And he's done a lot of work there to try and figure out, as you say, how to push Kubernetes down the stack and have people interact only with tooling that makes sense for the things they want to deal with. So I think there's a lot of very interesting work perhaps still to be done in that space.

MATT FARINA: I would definitely agree with that.

CRAIG BOX: You could definitely build a landscape with very small icons listing all of the things that Brian has analyzed in the past.

MATT FARINA: I'm sure you could.

CRAIG BOX: I think it's fair to say that this isn't your first time on a podcast?

MATT FARINA: No. I actually got on a podcast for the first time about 15 years ago. It was my very first podcast. That was probably the most popular one, actually. I remember one time it was hosted in a VPS. And I only had so much bandwidth per month. And I remember when it was at its peak, we were getting close to those bandwidth limits per month for all the outgoing people downloading it.

But that was early in the podcast days. And I did a couple of them back then. And then a few years ago, I jumped in with Matt Butcher. And we did one called the "Cloud Native Podcast," which I know you stumbled upon, where we talked about cloud native technologies for a season.

And Matt is one of those guys I've worked at two companies with. He twisted my arm and talked me into co-authoring a few books with him. He's one of the guys who started Helm. And he and I have co-maintained a number of projects together over the years. And so it was very easy for us to kind of say, hey, let's get on and talk about cloud native stuff. And so we did that for a while.

CRAIG BOX: Yeah. Matt was a guest on the show. He was obviously very easy to talk to about cloud native stuff. You could have owned the space, Matt, a whole year before Adam and I started this show. What happened?

MATT FARINA: We got busy. Life got busy, and we got distracted with different projects and things. And it just kind of fell to the wayside. That's what happens with many podcasts. And so I'm glad to see that yours has continued on and is able to keep going.

CRAIG BOX: And I'm glad to see that the things that you are doing now instead of that podcast, such as Rancher Desktop, are so successful. So thank you very much for joining me today.

MATT FARINA: Thanks for having me. This was a lot of fun.

CRAIG BOX: You can find Matt on Twitter, @mattfarina, or on the web at mattfarina.com. You can find Rancher Desktop at rancherdesktop.io.


CRAIG BOX: That brings us to the end of another episode. If you've enjoyed the show, please help us spread the word and tell a friend. If you have any feedback for us, you can find us on Twitter, @kubernetespod, or reach us by email at kubernetespodcast@google.com. You can check out the website at kubernetespodcast.com, where you will find transcripts and show notes, as well as links to subscribe.

If you've got this far into the show, you're clearly a kind and generous person. Please consider rating us in your podcast player so we can help more people find and enjoy the show. Thanks for listening, and we'll see you next week.