 because she's a very famous software engineer. And my daughter looked at me, like 10-year-old daughters do, and said, dad, duh, I know that. She's famous. So I'm very, very honored to welcome Michelle Nourali to stage. Welcome. How is everyone doing today? I hope you're well. Yeah, round of applause. Getting through this. My name is Michelle Nourali. Thank you so much for having me here in China. I'm so excited to be here for the very first time. I'm an engineer on the Azure Containers team. Throughout my career, I've had the good fortune to experience different types of development. I started off as a full-stack web developer. Then I became a platform developer for a platform as a service company. And now I have the pleasure to build open-source tools that make people more productive with containers and Kubernetes. So many of you I saw earlier have already heard of Kubernetes or have some experience with Kubernetes. But for those of you who are not familiar, Kubernetes is software that helps you manage your containerized applications in the cloud, on bare metal, or both. Three years ago, my company was evaluating Kubernetes to solve some of our own problems. And even then, even though Kubernetes was so young, we really loved what we saw. Because it was a good solution for the problems that we were having. We really needed a way to reliably scale a large number of containerized applications. And even then, the community was very welcoming. And we knew exactly where to go to ask for help when we needed it. And after Kubernetes was donated to the Cloud Native Computing Foundation, we had even more confidence that this piece of technology would grow sustainably and be stable. In the process of deploying lots of microservices to Kubernetes, we found that we wanted some additional tooling to make it easier to share and configure applications to run in our cluster. And if you're not already familiar, you can deploy and scale your containerized applications by giving Kubernetes some declarative declaration of what you want it to do in the form of Kubernetes manifest. And those look like something that's on the screen right now. But in reality, to deploy just one application to your cluster, you may need to write several Kubernetes manifests. And these manifests deploy multiple Kubernetes resources or objects. And they can be hundreds of lines long. And you may want to tweak your manifest just slightly to adjust for different environments. Once you have a set of Kubernetes manifest that work for you, you may want to package that up and version it so that you can share it with the rest of your teammates and know, be confident that your set of manifests will run. Your application will run exactly the same as it did for you for your teammates as well. So to satisfy those needs, we started a project called Helm. And with Helm, you can define your Kubernetes manifest in a package format we call a chart. And inside of the chart, which is really just a set of files, you can template your manifest to make it easy to define default configuration but also override that configuration for different environments. And the chart format actually also makes it easier to share your set of manifests as well. So I want to invite to the stage Rhea Bhatia. She is a program manager at Microsoft. And she uses Helm regularly. So I'd really love for her to show us a little example of how Helm works and how you can use it. Cool. Thanks, Michelle. So today, I'm going to be showing you guys in a TensorFlow application, which I've basically packaged up with Helm. So all I have to do is a Helm install. And then I find the charts. I have my name. And then I can give it a name. So I'll just call it demo. And then when I hit Enter, what it's going to do, it's going to spit out all of this, I guess it's a gamble, little application deployment stuff. I don't really need to know, which is great. And it spits out my deployments, my services, my ingress, my pods. And these were already created. And all I have to do is a Helm install. This makes Kubernetes so easy. And this makes it easy for me to deploy applications to Kubernetes. So what did I actually just deploy? Let's go and hit the UI. And there we go. It's a TensorFlow fruit classifier. And it's just going to find a bunch of pictures of fruits. And it's going to match it to its different emojis, basically. So this is pretty awesome. It came up in seconds. And Helm just did it all for me. Thank you so much, Rhea. Let's give her a round of applause. Thank you. So the spirit of openness and collaboration in the Kubernetes community really opened the door for us to work with people from other organizations to build the solution together. And we heard a little bit about this from Jim Zemlin earlier today, how people come together to build solutions. And this is no longer a zero sum game. And we actually, on the Helm team, lived that example and got to work on an awesome project that gained a lot of traction and success by collaborating with other people in the community, people who would normally be our competitors. And Helm has grown quite a bit since the project started in 2015. We've seen over 345 contributors to the project in just the last 2 and 1 half years and over 4,800 people in our Slack channel. But with a lot of growth comes some growing pains as well. For example, we were scaling the code base and our team, as well as addressing people in the community who were also building tooling on top of Helm. And on top of that, we were having conversations and still are about the future of Helm and what the community wants to see with the next major version release. And we heard from Linus today about the maintenance shifts and the responsibilities that go with maintenance shift. We also, I agree with everything he said, and we also experienced that with the Helm project. So this in itself was challenging enough. But what proved to be equally challenging was meeting the non-technical needs of the community. The community was asking for mailing lists and Slack channels to discuss and ask questions. And more people were starting to show up to our weekly developer calls. We even had our first two-day conference with almost close to 400 people who showed up. And no one on our team actually had any experience running conferences. So this was just a bunch of us trying to figure it out while we were scaling our community and trying to meet those needs. We've also been doing a lot lately around hardening roles and responsibilities and decision-making processes on our team. Helm really grew up, though, as a Kubernetes sub-project. And over the past two and a half years, it's gained its own community, its own ecosystem that has its own needs. We were already leaning on the CNCF for quite a bit of help and support managing our community and its needs. And we were finding ourselves needing more and more support more and more frequently. Something would come up on our team and someone would say, well, can the CNCF help us with that? And the answer was generally yes. At the same time, the Kubernetes project was becoming more focused on just the artifacts that were actually released with Kubernetes. And we in the Kubernetes community are trying to make sure that the Kubernetes GitHub org is as slim as possible right now because that community is growing as well and scaling as well. With all of this in mind, the core maintainers had a call to discuss whether we wanted to be a top-level CNCF incubating project. And because it seems like a natural fit, we wrote up a proposal. We presented it to the Technical Oversight Committee, or the TOC. And the TOC is the committee in the CNCF that does the due diligence for the projects, the technical projects that are in the foundation. So we had a discussion with them. They did some due diligence. They had a vote. The vote was successful. So now we're a CNCF project and are in the transition to doing all the things that the CNCF requires of our project. And we're really excited about this opportunity to support our community and ecosystem to the fullest and gain access to even more people to make Helm even a stronger project. So, so far, we've talked about Kubernetes and earlier I mentioned that as an end user, it was really important to us that Kubernetes was vendor-neutral because we had trust that no big company could come in and make a decision and really steer the project in a completely different direction. We knew that it would grow sustainability, that the stakeholders would have some stay in the decision-making process. And this would just be a better situation for everyone that was involved. It's also really great for project maintainers, like the Helm project maintainers, for example, for a project to be vendor-neutral because this lowers the barrier for people who want to contribute to our project. They don't have to go through as many loopholes and all of that. So it's just a better and a smoother process. It also helps the maintainers focus on the community's needs instead of one particular company's needs. Then we, so in all transparency, Helm going into the CNCF was like a really natural and smooth process. But now I want to switch gears a little bit and talk to you about a project from the perspective of someone who is just starting out. Someone who has created their own open-source project, it's new, it's gaining traction, it's useful. So let's talk about that a little bit. Helm solved a big problem for our team in the process of developing applications that would run in Kubernetes. But while we were doing that, we had some other challenges that we wanted to focus on as well. One of the tools that we started working on was, it's called draft. So the idea is, when you're developing containerized applications, you may find yourself repeating yourself with the steps that you take over and over again. For example, you'll want to build your application container by writing a Docker file and maybe doing a Docker build or using a different builder. You'll want to push that image that you just created to a container registry, write a Helm chart or some Kubernetes configuration, reference the image that you just built in that configuration that you just wrote, and then deploy your application to Kubernetes and test it out. And all the while, you're using a lot of different tools and having to understand a lot of different layers of abstraction, a lot of different technologies. Draft is a tool that helps those people be productive who really just care about building their application and developing and debugging it against Kubernetes rather than understanding and working on Kubernetes itself. We live in a world where we can't always run all of our microsarfs.