Made by
Made by
Ryan Jarvinen
The Kubernetes project uses special interest groups to channel and focus planning and contributions. Red Hat’s Ryan Jarvinen explains how those SIGs are streamlining open source collaboration in this talk from DevXCon San Francisco 2018.
All right. So I have collected some of my experiences as someone who’s worked on Kubernetes and worked with the community. And so hopefully, you all find this insightful and useful and hopefully, I convince you all to join us and work with the Kubernetes community as well. So, thank you for the introduction. If you encounter me online, this is what my avatar frequently looks like on most places. I’m known as Ryan J on GitHub, IRC and Twitter. And today, I am brought to you by Red Hat. And so for folks who aren’t already up to speed on Kubernetes and why I like working with this community, I’ll give you a brief introduction as far as what’s been going on in this particular space.
So Kubernetes primarily is an operations tool. It’s something that kind of came out of Google as their kind of almost their secret sauce or their best practices around managing distributed systems at a very large Google size scale. So, I like to think of it primarily as almost a distributed systems modeling language. There’s a lot of terminology to learn. It’s kind of a heady topic. But it really gives you a lot of power when you are building distributed solutions.
I think another really interesting aspect of Kubernetes, I like to think of it almost this way, it’s almost like a protest as software. There’s a bunch of people that are all collaborating across company lines, sometimes with their competitors in the same space, and they’re doing it for a particular reason. I think, for me, it’s almost about accessibility and digital rights issues. We wanna make sure that, kind of, the means of production and the means of achieving staging as well. But the means of production is in the hands of the users. And you’re not always going to be in a situation where you need to do work, well, you need to pay Amazon for their specialized database that is proprietary close source and something that only they know how to host. Which kind of keeps the knowledge and the expertise in the hands of the few and potentially in the hands of the corporate monopolies.
So hopefully, Kubernetes is achieving this goal and making sure that what’s available in the industry is expertise and tooling. And so it does have kind of a steep ramp up and a steep learning curve because you’re kind of adopting a new set of skills and a new set of expertise around site reliability engineering. And it’s kind of a different style of work that you may not have encountered in the past especially if you’re generally dealing with developers, which most of us are.
I have a couple notes throughout this talk to folks that have really inspired me. I wanna try to share this platform as much as possible, very lucky to be here, and so I have a bunch of notes on who else has helped me get here and people that have really inspired me. And Tim Hockin from Google has definitely been very active on helping make sure that the Kubernetes community is…really kind of the early founding of it was put together in a really good way to help achieve some of these goals.
Kubernetes right from the start has been architected to be a multi-vendor, multi-corporate open source effort, which is really powerful. It’s not just…sometimes I’ll see with certain open source efforts. It’s open source, but it’s open source and read-only. At least you can audit the code and review it for security purposes, but is it even possible to get your commits landed upstream? Sometimes there’s absolutely zero contributor story despite the fact that the project is open source. So I’ve definitely seen this in some of the container space.
But Kubernetes really has an approach where they try to establish open governance that’s going to work across company lines and really kind of set a standard where your ability to succeed is kind of based on your ability to collaborate with people who are potentially your competitors in the industry and hopefully you learn to get over that feeling and you say, “Hey, they’re not just our competitors. They’re our peers and we need to work together to achieve standards that are industry wide accepted and enable our users with a real portability of the services that they’re offering.”
Sarah Novotny is another really influential person in this open governance space within Kubernetes. So if you’re not already following her, another great person to follow. Kubernetes, as it’s trying to achieve all of these goals, also tries to stay focused. If you’re re-implementing the world for the open source community, you gotta start somewhere. You can’t hit all goals all at once. And so we try to focus on small reusable distributed solutions building blocks that higher order solutions can be built from. We try to focus on supporting primarily container-based workloads, although a lot of work for adding virtual machines and other different types of workloads is kind of on the way.
If you’re using containers, that’s one potential way to own the libs. You have basically all of your static libraries. Thank you. Thank you. All of your static libraries are all compiled into that container image and essentially you’re sharing the host machine’s kernel for scheduling memory management, those type of aspects. So there’s a lot of reasons why you might want to move to containers. And if you’re convincing people to adopt Kubernetes, you’re going to need some good rationale that aligns well with whatever they’re doing. And one of my main struggles with Kubernetes… Oh, also you wanna know more about container-based workloads and really the top of the industry performing, I think, in that space, definitely follow Jessie Frazelle. She does a great job with education around container security.
So another thing that is part of the focus of Kubernetes, if you go to the Kubernetes About page, there’s a big section that says what Kubernetes is not. So, since Kubernetes is trying to focus on small reusable building blocks, they’ve kind of made…one of their goals is not to be a platform as a service. Honestly, this is what I think most developers would like to see. If you’re offering services to developers, having something Heroku-like is kind of the state of the art, I think, for meeting their needs and offering it in a clean, easy-to-use, easy-to-understand way. So I work on the OpenShift project in addition to Kubernetes. And that does try to bundle a couple of other open-source solutions in addition to Kubernetes to give you more PaaS-like features.
So, when I first started looking at Kubernetes and trying to educate developers about why they might wanna use it and find good stories that really resonate with them and try to motivate them, I had a really tough time, and partially it’s because of the nature of Kubernetes. It’s primarily an operations tool. You’re telling people about all the great features and it’s things like high availability, auto scaling, auto healing, failover, all of these kind of distributed systems use cases that front-end developers kind of really don’t care about, to be totally honest. And so you’re giving them all of these like, “Hey, you could solve this problem you don’t have, and this other problem you don’t have, and this thing you don’t care about.” And after a while of doing this education and having people sit through a typical introduction, people just…their eyes glaze over. They’re just like, “No, don’t tell me anymore.” And I definitely heard speakers yesterday saying you could definitely do more harm than good if you just drown people in terminology and turn them off to a topic entirely.
Eventually, I was like, “Hey, maybe it’s not just my presentation style.” As the white guy on stage, I’m like, “Well, it can’t be me. It must be the content.” It is challenging content. So I’ve been focusing on trying to build hands-on training experiences that get people to using Kubernetes, getting their hands on with kind of learning by doing right out of the gate. That’s been working pretty well for me. So I’ve been trying to share as much of that material as possible. My slides right now are actually hosted on a Kubernetes server on GKE. And the sources for the slides are stored in a GitHub gist.
So if you end up going to the slides and clicking on this link in the corner, it’ll send you right to gist.github.com with the presentation sources. I built this slide site for DockerCon, the first DockerCon hackathon, and I’ve still been using it ever since. And that makes all my slides forkable, shareable, easy for people to rip off and then reuse at meetups. So if you’re interested in doing any education around Kubernetes, definitely ping me, I’ll show you how to use this site. Other training content, Kubernetes by Example is another good one, popular one to go for Kubernetes the HardWay by Kelsey Hightower, super interesting. And we’ve added a lot of interactive training scenarios both in the tutorial section of the Kubernetes dock site and on learn.openshift.com.
So SIGs and working groups are really what I wanna talk to you about. This is the main mechanism this community has been using for organizing. So here’s kind of what you can see currently on the Kubernetes SIG and working group listing. This is auto-generated based on some scripts on a periodic basis. But there are different groups that you can go and try to specialize with. If you’re particularly working with something like artificial intelligence and machine learning, there are working groups, 10 of them in fact. Resource management working group is doing work around making GPUs available for GPU-based workloads. There’s a machine learning working group, DevTools working group. There’s an app definition working group. They’re still kind of struggling with the definition of what is an app, which makes this really hard to go to app developers and say, “Hey developer experience, come on in. It’s easy to learn but we’re not quite sure what an app is yet.” That’s a really tough workaround to do on stage.
Special interest groups. There’s 30 of them for you to join. I find SIG-Apps to be the most relevant for developer relations folks. Michelle Noorali was a leader in this group, and I think she has moved on up to the contributor experience SIG, as far as I know, steering committee even higher up, yeah, another excellent person to follow in the space. If you’re looking at extending the platform and building on top, I’d look into the topic of custom resource definitions. I’ve seen a great post from Nikita recently on that topic. Service Catalog is another way to get your API services bundled and offered, made available to developers within a Kubernetes environment so you could look at building a service broker for your particular API if that meets your needs. The terminology is still confusing. When I hear the word operator, I think it’s a human that’s doing a job. Kubernetes operator doesn’t necessarily clarify things anymore for me, but there’s a topic called Kubernetes Operators that if you have a database or other type of service and want to host it, you could look into that topic as well. That might be relevant for making your services available to Kubernetes users.
SIG-ContribEx, another really important group. They help provide standardization across all of these different special interest groups to make sure that things like signing the contributor license agreement is something that’s pretty standard and easy to do. Ownership and operation of these SIG groups are all pretty standard. You could definitely follow Paris here. She’s a great resource in this particular group. And if you’re interested in really gory details about how the test automation, chat ops, label automation, standardization, mentorship, and more happens, @spiffxp – Aaron Crickenberger – is really a good resource too…if you could get his time.
So in my experience, the Kubernetes community has a lot of really awesome caring people, a lot of good solid mentor program for you to reach out to. We need your help. Recently, Gwen made some progress on a new contributor guide. I had offered to do a developer guide, which I have done a terrible job of following up on. I think there’s a lot of room for an extend the platform guide as well. So a couple months back at Scale, I ran into Gwen and she did a follow-along-on-stage, become-a-contributor type of talk, hands-on, challenged everyone to get out their laptops and start contributing right away. It was an amazing talk. I was incredibly inspired. I was like, “I’m gonna help with this. I’m gonna make a new developer guide.”
And I immediately ran into a roadblock because I had left one company and lost access to my Linux Foundation account, couldn’t login to Linux Foundation and couldn’t make my commits. So I should have just made an alternate Linux Foundation account to work around it, but I didn’t wanna be trying to sneak in kind of contributions. So don’t be like me. Don’t be a blocker. If you don’t have time for something, don’t claim it and then sit on it. Hand off ownership as needed to people in your community. Please help on the new developer guide if you have time. I’m gonna try to get to it after this. Well, in another two weeks maybe. I posted an update earlier today, plenty of valid ways to contribute. I’ll wrap it up here.
We also need blog authors. You could talk about how your technology works really well with Kubernetes. Blog editors are needed. I wrote a blog post recently about how the Kubernetes community has some of the metrics…well, some of GitHub’s metrics. GitHub did a Octoverse report. And out of all the repos on GitHub, not a single one had more issue comments than Kubernetes/Kubernetes. So these SIG groups, I know this is kind of anecdotal evidence, but have been a significant factor in helping them scale up this community to the highest levels of community engagement and interaction on GitHub.
So I think that in some ways helps prove that this organization structure and open governance is really working and really getting a lot of traction and really helping make Kubernetes a big success. So we’d love to see you as part of the community as well. Here’s my call to actions for you. There’s an easy Slack channel to join. I would definitely recommend that. You can attend the main Kubernetes Community Meetings and SIG apps. Those are my top two favourite ones to attend. Most of those you can get involved by joining a Google group, and that will add you to the calendar invites.
As far as I know, your ability to watch on YouTube. These are all published to YouTube. So that’s another great resource, and you don’t have to sign the CLA to watch channels on YouTube. So that’s the easy way to get started. Make the experiences awesome for your community and whenever possible, distribute knowledge and training and skills across company lines and welcome everyone in to working in open source. I never get to post this, but we have an open spot on our team. So if you’re interested in doing more work at Red Hat in the open source community, definitely hit me up. I’m Ryan J. Thanks for your time.