By 
As engineers, we tend to rely on numbers, datapoints, and dashboards to give us the lay of the land. What’s the current CPU and memory utilization, how many pods and containers are running? How many lines of code written, changed, merged? How many developers contribute to a project or deploy open-source solutions? The data is important, no mistake, but data alone doesn’t tell the whole story. Developers are the biggest driving force behind cloud native innovation. Give the open-source community a problem, a software platform, and the freedom to innovate and watch as cloud native infrastructure is transformed. The developers, more than the data their solutions generate are the real story of the cloud native evolution. At Intel, we collaborate with the cloud native open-source community every day. Let’s meet one of the developers making an impact.
Patrick Ohly is a Cloud Native Architect at Intel, working on open-source projects and primarily working in cloud native. He’s authored several KEPs for Kubernetes, initially focusing on work for the Storage SIG. For example, he’s been working on storage capacity tracking, which graduated to GA in Kubernetes 1.24. Storage capacity tracking allows a CSI driver to publish information about remaining capacity, to help the kube-scheduler pick suitable nodes when a Pod needs to provision volumes. Patrick realized that the problem for cluster administrators was configuring the scheduler extender when installing PMEM-CSI, and then dealing with the remaining race conditions. His current focus is on improving device support with a feature called “dynamic resource allocation”. The goal is to have a native API for network-attached devices, that have complex attributes, or that need additional parameters when preparing a device for a certain workload. Sharing a resource between pods and multiple containers inside a pod also becomes possible. Come talk to us about this at the Intel booth At KubeCon + CloudNative North America, or attend the “Improving User Experience For Device Consumption In Kubernetes” session!
When describing his approach to solving problems like these, Patrick said that he “might study previous proposals and design documents, investigate how the current code works and perhaps do some prototyping. Then when I engage with other developers, I typically have a fairly solid
understanding of what the problem is and how it could be solved, which helps address questions and comments in the following discussions. There’s a certain risk that time and effort will get invested in something that can’t work or won’t get accepted, but luckily that hasn’t happened to me yet.” He notes that the collaborative approach to developing a KEP through repeating meetings dedicated to the topic is also a “valid and useful approach.” The downside of having a well thought out solution to a problem and then engaging with the community is that other developers need to catch up, which takes time.
Collaborating with the Kubernetes community has confirmed his appreciation for the transparency found in open source development. Not just the source code, but the history of the commits, keeping the meeting minutes, and keeping communication in public mailing lists and public chat channels. “All of that enables others to catch up at a later time, which is important when people from different time zones collaborate, or they don’t have the time to attend all meetings in person.”
What he has learned from the community is that sometimes “…less is more: when a solution or source code is too complex, it becomes harder to review and maintain,” he says. “This is particularly important in open source projects where the original authors are often not the ones maintaining the code in the long run, but the same is also true for internal projects when developers get reassigned or perhaps even leave the company.” And keeping the history of a project alive, through code, comments and documentation is a key to keeping the project alive into the future. “What Kubernetes does well is insisting that there is well-written full documentation for features (the KEPs). A set of slides with some boxes just cannot replace such a written document. The community also makes sure that such documents are easy to review and maintain by using plain text with Markdown annotations. Those texts are stored in git repos, just like source code, so the full history is preserved.” This is something that Patrick is an advocate of inside Intel as well as in his open source contributions.
The satisfaction in solving problems through collaborating with open source communities is a reward that goes beyond just solving the problems. For Patrick, it is an “opportunity to work directly with the experts for different technologies. Because everything is done in the open, it is possible to follow what is going on elsewhere and, if something appears to be interesting, to dive deeper into a new area.” That excitement about diving into something new and interesting is what drives developers like Patrick to explore, innovate and create new solutions to problems.
In An Open Letter to an Open Ecosystem, Intel CEO Pat Gelsinger made a pledge to openness, and in the opening keynote for Intel Innovation 2022, he reconfirmed Intel’s commitment to open source and his belief that our “collective potential as an industry is unleashed when we enable openness, choice and trust.” Patrick’s observations about working in open source projects at Intel exemplify that commitment. He says, “there is a good understanding at Intel that entire industries are built on collaboration in open source projects. For our own products to be successful and useful to customers, we need to find ways to make them work with such projects. Therefore, engaging open source communities like the ones from the CNCF and contributing to projects like Kubernetes is encouraged and supported. This does not even have to be limited strictly to work that benefits our own hardware platforms. Taking on work simply because it needs to be done is okay. It keeps projects healthy, which is important for our customers, and it opens doors when it comes to discussing new proposals for features that Intel is interested in.”
Intel’s commitment to open source goes deeper than a commitment to sharing source code. It’s a belief in the collective power of developers – the people behind the code who are collaborating to create new platforms, new solutions, new approaches to problems that may seem unsolvable. That commitment is demonstrated by the data, the inevitable return to the data, which shows that Intel is consistently in the top of the Open Source Contributor Index. The data does tell a story, but it’s the people behind the data who make the story interesting.
