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

[MUSIC PLAYING]

This week, we celebrated the 40th anniversary of the release of the ZX Spectrum. A lot of people have an affinity for the 8-bit micros. I was a VIC-20 kid. Moving on to the Commodore 64, which is celebrating its 40th anniversary in August.

I enjoy watching people fix up old 8-bit computers on YouTube. It's either nostalgia or ASMR, depending on how you look at it. The better ones get donations from all around the world. Do you have a Commodore computer that you don't need anymore and you want to send it to me? Please do. I'll unbox it live on a podcast for you.

These things now cost substantially more, in some cases, than they did when they were new. 40 years will do that to you. I recently bought a bunch of old Commodore 64s that need repair. And later in the year, I'm looking forward to seeing how many of them I can get going again.

I don't know what I'll do with them if I do get them going. I think I'm just interested in the challenge. Perhaps I'll do an audio play-by-play. I'm not sure I have a face for YouTube. For a while there, there was a theme of conference talks explaining new concepts using old computers. If I could figure that out, I wouldn't need donations. I could just put it all on my expense account.

Back to the spectrum, though. Resurfaced in the 40th anniversary press was some work done by Mark Round in December last year, creating a backend for a network-attached Speccy. The backend runs in the Docker container on top of Kubernetes, thus bringing these two worlds together nicely. The best part is how he got unit testing working by having the spectrum print to what it thinks is a thermal printer and using a FUSE driver, which lets you read that printed output by crude OCR.

Or you could just play "Manic Miner" in an emulator. There you go, Adam. There's my game of the week recommendation.

Let's get to the news.

[MUSIC PLAYING]

CRAIG BOX: The Istio service mesh project has applied to join the Cloud Native Computing Foundation. The announcement was made by Google and the Istio steering committee alongside this week's istio Con event. In unrelated news, I can finally talk about what I've been working on for the past two months. Listen on to find out more.

VMware's Tanzu Service Mesh is powered by Istio, and the underlying functionality has now been exposed with the launch of a new Istio mode. Customers can use Tanzu to manage open-source Istio, with Tanzu tooling helping with installation and upgrades, as well as providing observability dashboards. Istio Mode is now available to all Tanzu subscribers.

If accepted, Istio will join the company of projects like KubeVirt, which became a CNCF incubating project this week. KubeVirt lets you run VMs inside of Kubernetes, including the migration of legacy applications. The project was founded at Red Hat and has picked up external contributors from over 15 different companies since joining the CNCF sandbox in 2019.

As KubeVirt leaves the sandbox, three new projects have been added. The projects are OpenFunction; a function as a service platform contributed by KubeSphere; Teller, a secret manager contributed by Spectral Ops; and Sealer, an application packaging tool contributed by Alibaba.

Secure software supply chain startup Chainguard has released its first product. Episode 47 guest Kim Lewandowski announced it, saying that the new Chainguard Enforce enables you to define, observe, distribute, and enact policies that ensure only trusted container images are deployed and run in your clusters. In this case, trusted generally means signed using six-door tools. You can reach out to them to try a pre-release version or participate in a paid 90-minute user study.

Amazon has released EKS Blueprints, a set of templates for Terraform, or their own cloud development kit, to make it easy to deploy EKS with a bunch of popular open-source software on top of it. Back in December, AWS also released a container that would mitigate the effects of the log4shell vulnerability in your pods, whereupon Unit 42 recently discovered and disclosed several security vulnerabilities in it. If you had put a process called "java" in your container, it would have been run by the Amazon DaemonSet as root, with full capabilities, thus providing a path to container breakout. Unit 42 worked with AWS to release patched versions. But you should probably just have patched log4j by now and should uninstall the hotfix anyway.

If you are still having trouble convincing your manager that this Kubernetes thing has legs, check out the latest survey results from VMware's State of Kubernetes survey. Takeaways include that single cloud and on-prem use is down, with multi-cloud and hybrid making small but measurable gains. Development cycles are actually slower with Kubernetes than in the previous two surveys, which could suggest that people are finally taking security into account, or that we've saturated all the ops people and are now hitting the laggards who have to learn a new way to work. The report will cost your email address.

An article in the Communications of the ACM lays out the story of the Go programming language, upon which the Cloud Native ecosystem largely stands. The paper calls out that Go enjoys widespread adoption despite having few technical advances over its predecessors. Instead, the creators say that Go succeeded by focusing on the overall environment for engineers and their software project. Good advice for anyone working on anything, really.

The origin section talks about how the rise of multicore machines led to the adoption of the language, with its focus on parallelism and concurrency.

Finally, it stands to reason that DevOpsDays Kyiv won't happen as usual this year. Instead, the team behind it has arranged a charity event to collect donations to support the Ukrainian people. The theme is quite rightfully DevOps During Crisis, and there are some great speakers on the bill. It will be held online on May 17 and 18, which may be in the evenings of KubeCon EU, but you should totally ignore that. Alternatively, you can make a donation ahead of time, and a link is in the show notes.

And that's the news.

[MUSIC PLAYING]

CRAIG BOX: Mitch Connors is a software engineer with Google Cloud, a Co-Lead of the Istio User Experience Working Group, and a Co-Chair of this week's IstioCon. Welcome to the show, Mitch.

MITCH CONNORS: Thanks, Craig. I'm a long-time listener, first-time caller, so I’m happy to be here.

CRAIG BOX: Big week for Istio, huh?

MITCH CONNORS: It has been an absolutely huge week for Istio. Really great.

CRAIG BOX: You and I obviously are knee deep in the Istio project. But for people who are listeners to this show and are, perhaps, not familiar with it, can you just give me a quick overview of what Istio is and does?

MITCH CONNORS: Istio is a service mesh management tool. Actually, at the first ServiceMeshCon in 2019, which was co-located with KubeCon, I think almost every talk was related to, what is a service mesh? And everyone came at it with their own definitions. Since then, I think we've settled in and gotten some more stability.

A service mesh helps you manage communication between microservices at the application layer. Not necessarily at L4 or even at L7, but you can set application level constructs for security, authorization, traffic shifting, telemetry. And they'll be enforced throughout your application, regardless of whether your microservice is implemented in Python, or Java, or, heaven forbid, Golang.

CRAIG BOX: Got to get those generics.

MITCH CONNORS: They're coming. Any day now, right?

CRAIG BOX: Let's dig into how you came to the Istio project and, perhaps, what it has to do with this podcast.

MITCH CONNORS: Yeah, that's a fun story. So back in the summer of 2018, I was working at F5 Networks. I had really learned the value at F5 of controlling the network via an API.

That's what F5's bread and butter has been for many years. They've been great at doing it. But they were doing it in a way that was very tied to hardware. And I was ready to pursue a software-only solution.

I knew that the cloud-native movement was sort of where I wanted to be and where I wanted to get to, but I had no idea how to get there. So I started listening to the Kubernetes Podcast. At the time, you were talking about technologies like Helm, Kustomize, Knative, Istio.

I knew that Google was a place where a lot of those exciting things were happening. I did an interview loop at Google. And if you've ever interviewed there, you're not interviewing for a particular job. The people who interview you are just random people in your role from around the company.

Well, it just so happened that one of the people interviewing me was Matt Williamson, who was working on Istio at the time. In the two minutes at the end of the interview loop, where he says, do you have any questions for me, I was able to say, yeah, what do you work on? And as he told me, I said, oh, this is weird. But if you decide to hire me, can I work for you? I want that team. Fortunately, for me, Matt agreed. And the rest is history.

CRAIG BOX: You left F5 at that point. Was it time for a refresh?

MITCH CONNORS: It was time for a refresh. That's correct. I pressed on F5.

CRAIG BOX: That joke doesn't work so well with Mac users these days. They'd be like, what do you mean? Command-R, come on.

MITCH CONNORS: You can do it with the 5 key as well. It's like Command-Shift-Option-5, I think, right? [LAUGHTER]

CRAIG BOX: I would have thought that took a screenshot?. But let's not get too deep into keyboard shortcuts. My keyboard doesn't even have function keys. Thank you, Apple.

Your profile says that you once built a sparse Merkle tree in Golang. Here's a whiteboard. Can you draw one for me?

MITCH CONNORS: I cannot. And actually, that's a really big problem with complex algorithms like Merkle trees. It's really hard to reason about a data structure that you can't visualize. One of the first features that I ended up having to add to my Merkle tree implementation was a utility that dumped the entire contents of the tree to a dot file for visualization so that I could actually see on the screen what's going on inside the Merkle tree.

CRAIG BOX: I did see a bunch of tweets passed by last week discussing whether or not anyone has actually had to implement a linked list as part of the programming job. Do you find that the baseline you have in algorithms has helped you in the work that you do on Istio?

MITCH CONNORS: You know, I find that algorithms are helpful generically, but this is definitely the first and probably the last time in my career that I'll find Merkle tree to be an algorithm I need to dust off the shelf.

CRAIG BOX: Why that one, explicitly? Why not the red black tree, for example?

MITCH CONNORS: In Istio, we had a big problem in that we were distributing config to Envoys, sometimes to thousands or tens of thousands of Envoys in one single cluster. Each Envoy, depending on when it got the config, it might have gotten slightly different resources — if you're busy creating virtual services or destination rules — and we needed a way to know which Envoys have which versions of which resources, and be able to state that globally.

Well, if you just record, oh, well, here's the 72 resources that we just sent to that Envoy. And then, oh, we changed one, so here's 72 resources that we went to the other Envoy. Very quickly, you will run out of memory. A sparse Merkle tree was a great way to track the history of what we had sent where, so that we could understand when things had propagated all the way out to all the Envoys.

We actually used it in a command called Istio control weight that we use extensively in our own test infrastructure to break race conditions. We would have tests that we were running before the config had finished distributing. And the Merkle tree helped us to fix that.

I will point out, though, there are still at least two lurking bugs in the Envoy implementation that crop up once every 10,000 executions or something along those lines. So if you have any experts on Merkle trees in the audience, I've linked the code in the notes. I would love some help there.

CRAIG BOX: I was going to ask, is that a challenge that you're setting out? There are bugs. Go and find them. But you've said no, you've actually pointed out where it is. You're looking more for a solution.

MITCH CONNORS: Well, I won't bore your audience with the details, but I'd be happy to help anybody who reaches out with the ins and outs of what's going on.

CRAIG BOX: Perhaps we'll help the next podcast listener get a job on the Istio team at Google.

MITCH CONNORS: There we go.

CRAIG BOX: You've been working largely in the area of user experience at Istio. You are Co-Lead of the User Experience working group. What is the scope of that group? What does it mean to look after the user experience of a product which is largely APIs?

MITCH CONNORS: There's really nothing that is completely out of scope for user experience. Envoy has a crashing bug in it. That affects our user's experience of Istio. So we really needed to look specifically at areas where we felt that the user experience was suffering, where that problem was maybe falling between the cracks of the other working groups, which, at the time, were very much focused on the verticals of Istio — networking, security, telemetry. User experience was sort of a catchall for the things that fell through the cracks.

CRAIG BOX: What are some of the projects that you worked on as part of that group?

MITCH CONNORS: The Merkle trees were actually part of the User Experience working group. That's why the implementation landed in the Istio control CLI. But more recently, I've really been focused on the user's experience of upgrades. We started running some surveys about two years ago.

And we were alarmed to find that many of our users were running out-of-date versions of Istio — not just out of date as in not supported, but out of date as in multiple known high-severity vulnerabilities in these versions — particularly problematic for a security product. I launched a series of efforts around understanding why users weren't upgrading and coming up with hypotheses to address those problems and try to encourage our users to keep their Istio installations up to date.

CRAIG BOX: How do you go about surveying a user base of an open-source project where you don't necessarily know who the users are?

MITCH CONNORS: That's another huge problem that we have faced. It's very easy for you to pick up an open-source project and for the author of that project to never know that you used it in any way. This is open-source technology. It doesn't have any phone-home features or any telemetry that I collect on your service. It's entirely your own.

So what we did in this case was we dropped a link to the survey in the install command. It would just drop a little nice note on your command line, saying, hey, thanks for upgrading. Please let us know how we did.

We also had a pretty aggressive Twitter campaign trying to get people to fill that out as well. And we've had over 200 people fill out the survey to date. So I'd say, that's been fairly successful.

CRAIG BOX: Do you change that survey as new releases come out? Are you finding new feedback is coming in as you've made these improvements?

MITCH CONNORS: We do change the survey. Though, I'm trying to be very careful with how we change the survey. We want to make sure that we get an apples-to-apples comparison from one release to the next, so that we know that we're improving and not just that our survey questions are changing.

However, I do add in information about new features that we've made available, new improvements. And I also ask for different types of feedback. Like, for instance, what types of upgrade are you doing? Are you using Helm? Are you using Istioctl, the Istio operator? That was a new one that was just added to the survey recently so that we can get a little bit more introspection into what our users are doing, what's going well, and what's not.

CRAIG BOX: Istio has long had a reputation for being hard, where hard sometimes means hard to install an upgrade. Do you think that's fair today?

MITCH CONNORS: Hard is such a difficult word to quantify. It is much harder than I would like it to be, still today. It is also much easier than it was two years ago. Our upgrade surveys have shown consistently that users rate each release as easier to upgrade than the last. That's the good news.

The bad news is, in terms of actual utilization in the wild of Istio, when we look at GKE users, we don't actually see a change in running up-to-date versions of Istio. There's still just as many vulnerable versions of Istio in the wild today as there were two years ago when we started those efforts. So we do still have a ways to go.

CRAIG BOX: What are the things that you think are holding back those users who are running old versions of Istio from upgrading? Do they just think it's part of the infrastructure? Do you believe those users are upgrading the Kubernetes environments as well? Or are they just dealing with something that was set up once and has never been touched?

MITCH CONNORS: Over the years, we've had a series of hypotheses as to why users aren't upgrading, and we've tested them both with surveys and with actual investment on the development side to see how it changes user behavior. We started with a theory that users didn't know they were vulnerable. They didn't know there were CVEs in their Istio installation.

We found that that was true for some subset of users. And we fixed our documentation, so that's mostly fixed now. I think it's highly visible. But we found there was an even larger subset who knew they had vulnerabilities but just didn't feel like they had time to do it, didn't feel like they had the time that they needed to invest in an upgrade for Istio. It wasn't broken as it was, so they weren't ready to fix it.

So we invested a lot in ease of use. We've seen ease of use has also not substantially moved the needle. We invested substantially in extending the support window. Today, in Istio, you only have to upgrade two times a year. You can upgrade directly from, say, release 1.11 to release 1.13. And those two releases will have six weeks of overlap where they're both supported, they both are patched for CVEs.

That didn't used to be the case. It used to be that you had to do it four times a year. So we've decreased the frequency and the amount of work that they need to do every year to keep this up to date, but the needle still really hasn't moved substantially. So we're working on a new hypothesis this year. And this one, I'm a little bit more confident in than the rest. The new hypothesis is that humans are bad at repetitive labor—

CRAIG BOX: No.

MITCH CONNORS: —and you shouldn't rely on them to do it. I know, right? It's a groundbreaking hypothesis. We're investing heavily in helping our users understand how to tie their Istio infrastructure in with CI/CD, and GetOps, and DevOps automation tooling so that their installation of Istio just stays up to date by default.

CRAIG BOX: Do you have any evidence to suggest that people treat Istio differently to their other applications? Or is all open-source software this far out of date?

MITCH CONNORS: I wish I had better data on this overall state of open-source security software. But I can tell you this. When I've talked to users who are running a two-year-old version of Istio for their ingress gateway, I asked them if they had any two-year-old Apache servers on the front end, and they laughed at me. So I do think that, at least to some degree — that's a long ways from quantitative data and results — but I do suspect that Istio is a little bit harder to operate for our users. One of the key reasons is the division between the data plane and control plane. A control plane, everybody knows how to update. It's just a service in Kubernetes like any other. You go and update the deployment, and it rolls out.

The data plane runs absolutely everywhere. How do you do a progressive rollout to everything in your Kubernetes cluster? It really is a big problem and one that we're trying to tackle. We're not leaving it to the users anymore. We're going to tackle it as a project.

CRAIG BOX: I've always thought that that was a problem with Kubernetes and not a problem with the software that runs on it. There is no real way to say, take all of these things and then please rolling-update all of them. The idea is you'll delete a workload. And if you want to upgrade one of the containers in the pod, you effectively have to remove the pod and recreate it in order to do that update. And a lot of people might think that's too much like hard work. Is that something that Kubernetes should fix?

MITCH CONNORS: It is a weakness in the current sidecar model, and I know there have been some heroic efforts within the Kubernetes community to address better sidecar lifecycle and, actually, to quantify the sidecar API, which, today, is not an API. It's sort of just an implicit use. I haven't seen those yield fruit. I think the saying goes, a poor craftsman blames his tools. I don't want to blame Kubernetes. I want to take responsibility for this problem myself and make it work amazingly for our users.

CRAIG BOX: You also work on Google's hosted version of Istio, the Anthos Service Mesh. How is it the same, and how is it different from open-source Istio?

MITCH CONNORS: That's a great question. Anthos Service Mesh is built on top of Istio. And that means that you should be able to go into your cluster that's using ASM and use any Istio API, and it will work the same way that it works in open source.

There's a few asterisks to that “any”. We don't support Envoy filters today in ASM. But for the most part, you can do anything with ASM that you can do with Istio using exactly the same APIs. If you're on Istio today, migrating to ASM is a very easy, even approaching one-click, operation.

CRAIG BOX: Now, a lot of people have solved the, how do I deal with Kubernetes upgrades problem by using a service like GKE, which abstracts that away. Does ASM have a similar approach?

MITCH CONNORS: It does. We have a managed ASM offering that keeps your installation up to date. My particular role within ASM is to drive the managed data plane. So I spend a lot of time thinking about that data plane problem. How do we keep our customers' data planes — which don't live in a Google 3 service, right? They live in the user's cluster, in the user's pod. How do we keep that up to date? It's a complicated question. But today, we do have managed data plane available as a public preview. We're hoping to make it generally available later this year. If the problem of keeping your Istio installation up to date is overwhelming, come talk to me.

CRAIG BOX: What are the things that you needed to drive in the open-source version of Istio to enable those Google management features?

MITCH CONNORS: What's great about the work we've done in open source is good architecture is good architecture. A lot of the improvements that we made to the upgrade process, such as revisions, and tags, gateway injection — all of these were done without really any thought to the managed data plane. The managed data plane came afterwards. But it turns out that those concepts worked extremely well in building the managed data plane internal to Google.

CRAIG BOX: You are also the co-chair for this week's IstioCon. I understand that you're following in some pretty big footsteps.

MITCH CONNORS: Yeah, I am, Craig. And I've had a great mentor.

CRAIG BOX: I'm allowed to say that because I was in that position last year before handing off to Mitch. You've done a great job, I should say. It's been a good event so far. And I'm looking forward to seeing what else comes through the rest of the week. What was the process that you went through in order to put the program together?

MITCH CONNORS: Step one happened back in January when someone made the terrible decision to ask me to co-chair a conference program committee. I've never served on a program committee before. I really didn't have any idea what was involved. But I love trying new things, so I said yes. And they've been stuck with me ever since.

CRAIG BOX: We had faith in you.

MITCH CONNORS: [LAUGHING] Thanks, Craig. I appreciate it. The next task was to craft the call for papers. This is really just a small web forum that invites people to submit proposals for talks to the conference. But we put a lot of time and effort into making sure that we crafted it in such a way that made our end users feel very welcome telling their stories at the conference.

I've heard from a lot of end users who, frankly, are on the cutting edge of Istio or ASM adoption. And they'll tell me, well, we haven't really done anything that interesting. We use the tool, and it works.

What we wanted to say loud and clear with this CFP is that “Istio is boring” is exactly the message that we want to be hearing at IstioCon. We want to hear about companies who very easily derived a lot of value from our tools very quickly. That shouldn't take a genius to do. We carefully crafted the CFP, and I'm really happy with the response that we got from the community.

CRAIG BOX: You offered some coaching sessions to some newer speakers. What were the speakers able to gain out of that process?

MITCH CONNORS: The key thing that I hope those speakers gained — I'd let them speak for themselves — I hope they gained confidence to know that their stories were interesting, that their stories were valuable to others in the community, to sort of feel confidence in their voice. I wanted them to know that this was the right place for them.

CRAIG BOX: When it then came to the process of taking the papers that were submitted and putting the program together, what were your thoughts and the thoughts of the program committee members alongside you in terms of how to put together a well-balanced diverse conference portfolio?

MITCH CONNORS: The emphasis was definitely towards end user stories. We selected very heavily from the submitted end user stories who were not coming from an Istio contributor or an Istio vendor, but instead were coming from a company who is just an end user of Istio that wants to tell us how it went. That, in my mind, is top-tier content. We want to hear a lot of that.

But of course, we had a lot of participation also from the vendors, from the contributors to Istio about amazing new things that they are building, have built, or that are coming down the pipeline in the next year. So balancing amongst all that was incredibly difficult. We had to cut pretty deep into some of the talks.

I think maybe next year, it's time for an IstioCon Rejects conference. I would attend, for sure. Even if I'm the one doing the rejection, I would love to hear some of those talks move forward.

CRAIG BOX: It's a virtual conference. There's no rooms that you have to pay for. Why didn't we just make it three weeks long?

MITCH CONNORS: Virtual conferences, in my experience, tend to wear on you a little bit more than an in-person conference. I'm not sure why that is.

CRAIG BOX: Feeling that you're at an event, but you don't get to leave your house, and you have to still drink the same coffee. I think that's a problem. For some people, at least, the coffee can be better.

MITCH CONNORS: It is. I am very thankful that I'll be able to be in… Valencia, in person, for this upcoming KubeCon. I didn't say Venice.

CRAIG BOX: Many times, Mitch and I have spoken. Like, are you sure you meant that you were going to go to Venice? You could try booking a plane flight to a different location. Perhaps, you might want to think about that.

MITCH CONNORS: I would have been very surprised when I landed in the wrong country come May 14.

CRAIG BOX: What are all these canals?

MITCH CONNORS: Exactly.

CRAIG BOX: One of the things as the conference host that you get to do is summarize the state of the community and, specifically, developments and changes over the last 12 months since the last conference. What are some of the things that have changed in the Istio community over that time?

MITCH CONNORS: We've grown. It's been great to see a huge influx of new contributors from Asia and the Pacific. We've actually been scheduling particular meetings for these contributors so that they're not having to always be the ones awake in the middle of the night. We now share that responsibility among the continents.

CRAIG BOX: Thank you.

MITCH CONNORS: Yeah. [LAUGHING] That's been a great development in the project. We've got 51 new project members, year over year, I think 13 new maintainers to the project. Each of them brings their own new insights and perspectives. So just super happy to welcome them to see what they bring to the project, what happens next.

CRAIG BOX: And what about in terms of new features and developments with Istio itself?

MITCH CONNORS: On the product side, we've had a number of improvements to our upgrades. We already talked about revisions and tags. We've added default tags and gateway injection. We've added a Helm repository. Of course, as we discussed, we've expanded the lifecycle of each Istio release, so you can upgrade twice a year.

But on top of that, we've added the WasmPlugin, Telemetry API, ProxyConfig API, as well as discovery selectors. There's so much happening in this project that half of those things I just listed, I still need to go read up on to really understand. It's great to see so much momentum.

CRAIG BOX: Of course, the other news from this week is that Istio has proposed itself to join the CNCF. Let's talk a little about that.

MITCH CONNORS: Yeah, you know, Craig, I'm a big fan of going to primary sources for conversations. And I understand you had a pretty big role to play in that process. So shouldn't I be the one interviewing you?

CRAIG BOX: If you like.

MITCH CONNORS: All right. Hi, and welcome to this section of the Kubernetes podcast from Google. I'm your host, Mitch Connors.

[SHOW INTRO MUSIC PLAYING]

[RECORD SCRATCH]

CRAIG BOX: Enough of that!

MITCH CONNORS: [CHUCKLES] Yeah, that felt wrong. Craig, what's been announced this week with Istio and the CNCF?

CRAIG BOX: I have sent a proposal to the CNCF that the Istio project should join. We have set out what the project does, how it's aligned with the CNCF, and the next step now is for it to be evaluated by the community, including the technical oversight committee itself, who will go through the process. Based on previous history, it'll be a few months before the CNCF have made the decision. But right now, we're very pleased to get that out for people to consider.

MITCH CONNORS: That's fantastic news, Craig. Why is joining the CNCF important for Istio?

CRAIG BOX: Istio has been a very mature product. It came out of the gate very fully formed, as we talked before about what a service mesh is. It's fair to say that many of the things people now consider to be a service mesh were there right at the beginning of Istio. So the question sort of says, where does the project go from here? We've really seen development alongside Kubernetes.

We've seen things like the Gateway API, where a lot of the Istio community have been working on how to bring the concepts from mesh to the broader clouds native ecosystem. And we're really looking to how we can grow — not just people talking about which service mesh to use — but how we can get people using service mesh everywhere.

We want to be closely aligned to Kubernetes. And of course, we're closely aligned with the Envoy proxy, and SPIFFE framework, and all of the things that are other CNCF projects. So it felt natural that now be the time that we bring Istio to the CNCF and join those projects all up together under one banner.

MITCH CONNORS: That sounds like a huge win for the community.

CRAIG BOX: Indeed.

MITCH CONNORS: So as a result of this donation, what changes can our users and contributors expect to see to Istio?

CRAIG BOX: Ultimately, none. The project doesn't need to change in terms of its governance or the way that it's managed. All of that was in place and will continue as it is. There's a little bit of administrative change behind the scenes. But ultimately, we have a great community and that will continue as is.

All our vendors, all our steering committee members are very supportive of this change. We hope to see more contribution from more people and maybe exposure of the software to more people over time. The community we have at the moment is great, and we expect everything to continue on as it was.

MITCH CONNORS: All right, Craig. Well, thanks for joining my podcast. But if it's alright with you, I'd like the guest seat back.

CRAIG BOX: Let's turn the interview back around the regular direction and ask you a little bit about your history with 3D printing.

MITCH CONNORS: Back in 2016, I really wanted to get my hands on a 3D printer. I still am, but I was then a big fan of open-source. I really love the idea that you could access and modify others' ideas from the internet and then take those ideas and turn them into physical reality in the safety of your garage.

I didn't want just any printer. I didn't want to go and get some off-the-shelf thing that you could just assemble, and it is what it is. I wanted to embrace the spirit of open-source and find one that is truly open-source, where I'm not buying it from the person who invented it– I actually get the instructions to build it from scratch.

I was in luck because Joseph Prusa of Prusa Printers had just published fully open-source all of the designs for the Prusa i3 Mark 2. I was able to source materials from friends with 3D printers, could print some of the parts, some of the local hardware stores had parts, and eBay. What I put together is this hideous Frankenstein of a 3D printer, but it actually produces gorgeous prints. So it was fun to have my hobbies combine that way.

CRAIG BOX: Can you have your Frankenstein printer print a nicer printer?

MITCH CONNORS: No, unfortunately, the way that tolerances work in manufacturing, you can never get better from worse. It doesn't work like computers. You know in computers, you can get highly-available from not highly-available. That's the beauty of horizontal scale. But I don't think anybody's figured that out for manufacturing yet.

CRAIG BOX: I do remember a project from a few years ago called the RepRap. Did you ever come across that one?

MITCH CONNORS: I have seen the RepRap. They are very impressive.

CRAIG BOX: I think the idea with that is that the printer is designed to be able to print its own parts and spawn its own offspring, if you will.

MITCH CONNORS: Yeah, it's a very impressive feat that they've pulled off with RepRap.

CRAIG BOX: What do you use your 3D printer to print?

MITCH CONNORS: Hobby stuff. I love to print puzzles of all types. Every time I find a new file for a puzzle online, I'll rush over to the printer. Also, conversation pieces for the desk. I like to have things at my desk at work that people can walk up to and fiddle with and sort of have a reason to chat.

CRAIG BOX: Have you seen your desk at work a lot lately?

MITCH CONNORS: I've seen it twice this week.

CRAIG BOX: Gosh.

MITCH CONNORS: It's really been unprecedented for me.

CRAIG BOX: That's the idea of a conference. It'll make you go places you wouldn't normally go.

MITCH CONNORS: [CHUCKLES] Exactly, that's right.

CRAIG BOX: Your GitHub handle is therealmitchconnors. Are all the other Mitch Connors just imitating?

MITCH CONNORS: If I could go back 20 years and give advice to my younger self, it would be that the user names you pick that are silly today will stick with you into your professional career and haunt you for the rest of your life. The story behind therealmitchconnors is that I forgot the login for Mitch Connors. Then, I assumed that someone else had taken the account. It was only about six months after creating therealmitchconnors that I realized I was also Mitch Connors.

CRAIG BOX: You never thought that was the right time to revert, or remove one and rename the other?

MITCH CONNORS: I think the account that had happened on was a Steam account. And once you've bought the game, you're keeping the game.

CRAIG BOX: Have you ever watched the TV show "South Park?"

MITCH CONNORS: I have. I am so un-Googleable because of that show.

CRAIG BOX: For people who are not familiar with obscure trivia from possibly 20 years ago now, there was a character in a couple of "South Park" episodes named Mitch Conner — no S.

MITCH CONNORS: No resemblance at all. Without the S, it's just totally different.

CRAIG BOX: A completely different thing. Thank you very much for joining us today, Mitch.

MITCH CONNORS: Thanks, Craig. I had a great time.

CRAIG BOX: You can find Mitch on Twitter at @mitchashimself, on GitHub, of course, as therealmitchconnors, and you can find IstioCon at events.istio.io.

[MUSIC PLAYING]

CRAIG BOX: Thanks, as always, for listening. 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 also find our website at kubernetespodcast.com, and on there, you will find transcripts and show notes as well as links to subscribe. Please consider rating us on your podcast player, so we can help more people find and enjoy the show.

Thanks for listening, and we'll see you next week.

[MUSIC PLAYING]