With the work we’re doing at Salesforce to re-imagine our architecture for deployment on the public cloud, we have folks working on Kubernetes across many different teams and product lines. While we’re organized in a traditional “org chart” structure, with workers mapping to management chains that tackle certain parts of our problem space (often aligned to products), Kubernetes concerns affect everyone horizontally across teams. We needed a way to provide a consistent body of expertise for enterprise Kubernetes use cases and requirements, all tied to an architecturally consistent vision. The Special Interest Group (SIG) model seemed like a great foundation to build on, so we recently launched an internal Kubernetes SIG with representatives from each of the different groups using Kubernetes.
Many projects in the Kubernetes community are managed by Special Interest Groups (SIGs). These groups make it much easier to manage what has become such a large project. A key point, according to the Kubernetes contributor guide, is that “the developers within each SIG have autonomy and ownership over that SIG’s part of Kubernetes.” But equally important, since Kubernetes is an open source project, is that “anybody is welcome to jump into a SIG and begin fixing issues, critique design proposals and review code.”
Like the public SIGs, our SIG has a hosting team and a Technical Oversight Committee (TOC) that meets regularly, as well as a public chat channel, documentation and recurring meetings that are open to anyone.
Our SIG charter includes the following goals:
- Drive and maintain a list of Salesforce (internal) customer requirements and issues related to K8s.
- Drive the alignment on the K8s-related company roadmap to Salesforce developers and stakeholders.
- Maintain the backlog of K8s-related work items with priorities.
- Facilitate inner source and open source K8s contributions from various teams across the company.
- Drive the collaboration and synergy with the Istio+Envoy-based service mesh.
- Educate customers about K8s products and best practices at Salesforce.
- Represent Salesforce K8s use cases in the K8s OSS community.
Many of the SIG’s founding members are working on our Kubernetes Platform as a Service (PaaS), so they have a vested interest in hearing from and supporting the folks using their platform. With such an array of tech stacks across our company, there are varying levels of comfort with Kubernetes, so the SIG can play a role in educating and onboarding folks to our tooling. Plus, we care deeply about supporting the open source tools we rely on, so the SIG can help prioritize contributing fixes and new features back to core Kubernetes.
So how does it work? The TOC meets regularly to keep a pulse on questions, concerns and new ideas. There’s an open submission form for everyone else to submit topics, and anyone can upvote ones they feel strongly about. Those ranked highly will be slotted into periodic open meetings to be discussed with the larger Salesforce K8s community. Discussion topics may yield projects that subgroups formed from SIG members will work on. The SIG has a dedicated Slack channel and is also tasked with hosting special events like meetups on occasion, along with inviting members of the broader K8s community to share their expertise with us. For example, the SIG recently hosted a member of the AWS EKS team, who shared some information about their vision and participated in a Q&A.
The kickoff meeting produced a lot of buzz and great questions that will help drive how the SIG shapes up from here. While you may be thinking, “Who needs yet another meeting?!”, we’re hoping the SIG will be more than just a recurring calendar invite and instead be a place for Kubernetes practitioners to learn from each other and build a robust community.
Let us know on Twitter at @SalesforceEng how you’re organizing around Kubernetes in your companies!
To learn more about Kubernetes and other cloud native technologies, consider coming to KubeCon+CloudNativeCon North America 2021 on Oct. 11-15.
Photo by fauxels from Pexels.