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
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
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
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?
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