Nagivating the interface between open and closed source software
•Download as PPTX, PDF•
0 likes•72 views
Lachie Evenson and Craig Peters talk about two open-source case studies and a framework for making decisions about open-sourcing projects at the Open Source Summit August 21, 2019, in San Diego California
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Nagivating the interface between open and closed source software
Similar to Nagivating the interface between open and closed source software (20)
Recently uploaded
Recently uploaded (20)
Nagivating the interface between open and closed source software
- 1. Navigating the Interface between Open and Closed source software
- 2. Lachlan Evenson @LachlanEvenson • Program Manager in Azure Container Compute • Our team is responsible for building and supporting upstream open source projects • Active in the Kubernetes community • Kubernetes 1.16 release lead • CNCF Ambassador • Prior to Microsoft - worked at Deis where he assisted in workload migration to Kubernetes • Using and contributing to open source software for 8 years
- 3. Craig Peters @peterscraig • Program Manager in Azure Container Compute • Responsible for open source container dependencies like Kubernetes • Geologist by training, developer by practice • Systems integrator and sales engineer • Product manager 15+ years • Bicyclist, hiker, beer lover
- 6. When considering open source… Who are you in this context? What are you trying to accomplish? Is it a core asset or differentiator?
- 7. What does it mean to be open? Closed Open to view and file issues Merge 3rd party commits Foundation
- 8. What does open mean in composed systems? Closed Open
- 9. Windows and Kubernetes Mixed OS Kubernetes Cluster Kubernetes APIs Linux control plane Linux node Windows node Windows Host OS Docker runtime kublet & kubeproxy Closed Open
- 10. Dimensions to consider • Speed • New capabilities • React to issues, vulnerabilities • Cost • Initial development • Maintenance • Support • Risk • Organizational/cultural • Contractual • Operational
- 11. Strategic options, at each level Speed, cost, risk Closed Open source Open to commits Open foundation Build • Fast • Expensive • Long term engineering & support • Moderate • Expensive • Long term engineering & support • Fast • Moderate • Organizational & cultural challenges • Fast • Moderate to inexpensive • Organizational & cultural challenges Adopt/Partner • Slow • Moderate • Complex relationship • Moderate • Moderate • Organizational challenge • Fast • Inexpensive • Legal, business, and cultural challenges • Fast • Moderate to inexpensive • Legal & cultural challenges Buy • Quick, then slow • Expensive • Commercial dependency • Fast • Moderate • Support dependency • Fast • Moderate • Support dependency • Fast • Moderate to inexpensive • Support dependency Windows Kubelet & kubeproxy
- 12. Case Study: Kubernetes Policy
- 13. Case Study: Kubernetes Policy • Open sourced an Azure specific policy controller for Kubernetes • Utilized Open Policy Agent (OPA) • But why is this policy controller Azure specific? • Community had similar interests Open to view and file issues
- 14. Case Study: Kubernetes Policy • Open sourced an Azure specific policy controller for Kubernetes • Utilized Open Policy Agent (OPA) • But why is this policy controller Azure specific? • Community had similar interests Open to view and file issues • Renamed to Kubernetes Policy Controller • Updated docs to be more generic • Project governance and onboarded contributors Merge 3rd party commits
- 15. Case Study: Kubernetes Policy • Open sourced an Azure specific policy controller for Kubernetes • Utilized Open Policy Agent (OPA) • But why is this policy controller Azure specific? • Community had similar interests Open to view and file issues • Renamed to Kubernetes Policy Controller • Updated docs to be more generic • Project governance and onboarded contributors Merge 3rd party commits • Community asking for a neutral home • Moved to Open Policy Agent org under CNCF • Renamed to Gatekeeper • Gatekeeper is a community-driven approach to policy on any Kubernetes cluster Foundation
- 16. Case Study: Kubernetes Policy Customers wanted a supported solution Azure policy for AKS Uses Gatekeeper project under the hood Continued upstream and downstream Product contains open and closed source components
- 17. Gatekeeper Speed, cost, risk Closed Open source Open to commits Open foundation Build • Fast • Expensive • Long term engineering & support • Moderate • Expensive • Long term engineering & support • Fast • Moderate • Organizational & cultural challenges • Fast • Moderate to inexpensive • Organizational & cultural challenges Adopt/Partner • Slow • Moderate • Complex relationship • Moderate • Moderate • Organizational challenge • Fast • Inexpensive • Legal, business, and cultural challenges • Fast • Moderate to inexpensive • Legal & cultural challenges Buy • Quick, then slow • Expensive • Commercial dependency • Fast • Moderate • Support dependency • Fast • Moderate • Support dependency • Fast • Moderate to inexpensive • Support dependency
- 18. Hopefully we’ve helped you think about… • What are your goals? • What kind of open do you want? • How do you make decisions? Are you interested in collaborating on the framework?
Editor's Notes
- PM working on open source container tech at Microsoft Trained as a scientist, working on tech my whole career First got involved in open source as a PM at EMC getting approval for my dev teams to even use open source components Then dove into multiple open source roles like Hadoop at Yahoo! Open Stack and Kubernetes at Mirantis Love being active and talking to people
- Lachie hired me to help manage our contributions to Kubernetes and related projects. You can imagine my reaction when the first thing I was asked to do was help land Windows containers in Kubernetes But why would you even want to do that? Windows shops have apps that could benefit from the resilience and operational model of Kubernetes. They’ve been demanding it How do we handle the situation that Kubernetes, and the Linux world on which it is built is open source, and Windows is not?
- The delivered solution looks like this – adding Windows nodes into a Kubernetes cluster enables Windows containers to be scheduled on Windows nodes through the Kubernetes API just like Linux containers But it isn’t quite that simple. For Windows nodes, you need to deliver the closed source Windows operating system together with open source Kubernetes components kubelet &kubeproxy together with the Docker runtime What does this mean from a service agreement or licensing standpoint? How does a closed source company deliver support for the services? Who is this hard for, and who is it easy for? How do you get all the pieces to line up from a strategic, cost, and operational standpoint? How do you handle the fact that the Kubernetes community is built from the Linux world view, with all the assumptions built in. You might even say it has a Linux foundation (badum-bum) In this talk we’ll present a working model we’re using to figure out how to navigate these questions. But first we need to agree about some nuances of open source. And Lachie will walk us through that. Why? Enterprises building Kubernetes apps want to consolidate operational models for legacy apps too Hard questions? Windows is not Linux Windows is closed source Windows APIs are different from Linux syscalls, security model is different Legacy apps are not 12-factor Microsoft customers expect full stack support Lessons learned Community Difficult to open both technical and operational thinking of cluster management beyond Linux principles New node type is a huge change, and community is optimized for incremental changes, so a bigger community investment is required up front than initially expected Microsoft culture Lack of understanding of community process (Incorrect) assumption that community won’t welcome Microsoft inputs Investment needed in support organizations for open source technologies
- It's important to ask when considering whether or not to open source software. * Consumer/Producer/Both What are your motivations - hiring, mind share, development velocity, exposure, adoption, in the case of a specification, industry adoption The core asset or differentiators are different depending on the business
- Not all open source is created equal. We use the decisions made on the last slide to influence how open we want to be. We think of open source as a spectrum So when we think about open sourcing or even using open source it's important to understand that being open is a spectrum
- Now that we’ve talked about your goals, and the types of open source, we consider that most significant systems are composed, and that there’s actual an open vs. closed question for each component that has its own trajectory
- For example let’s look at Windows and Kubernetes The Linux control plane and nodes are open source. However a Windows node is mixed. Is this an open or closed system? Can it innovate quickly? Is it supportable? Is it cost effective?
- Photo credit: Craig Peters To answer that question, let’s consider several important dimensions Speed: deliver to the market as well as react to internal and external events Cost: up front, and ongoing Risk: often overlooked organizational and cultural
- This chart summarizes the framework we’re developing for thinking about the choices we make at each level of our systems. The framework is emerging from our experiences on the many open source projects, and is a work in progress Let’s look at where Windows and Kubernetes sit Kubelet and kubeproxy are NOT differentiators, so open make sense. Open to commits or Open Foundation? Delivering as a supported service under AKS and enable customers to work with it through the open source
- Motivation – Provide an enterprise ready solution for Kubernetes policy based on customer feedback In mid 2018 we built and open sourced an Azure specific policy controller for Kubernetes Built on top of Open Policy Agent We started asking ourselves why is this policy controller Azure specific? Through open source we discovered that many other people were trying to solve the same problem
- This chart summarizes the framework we’re developing for thinking about the choices we make at each level of our systems. The framework is emerging from our experiences on the many open source projects, and is a work in progress Let’s look at where Windows and Kubernetes sit Kubelet and kubeproxy are NOT differentiators, so open make sense. Open to commits or Open Foundation? Delivering as a supported service under AKS and enable customers to work with it through the open source