when relevant content is
added and updated.
As more IT organizations adopt open source technologies, it’s useful to understand that community releases are somewhat different than proprietary software from a single vendor. Let’s take a look at the most recent release of the popular Kubernetes project, version 1.8.
What’s Included with Kubernetes?
Last week on PodCTL (@PodCTL) we discussed a topic that often comes up with companies that want to build a DIY platform using Kubernetes. How much is included in the Kubernetes open source project, and how many other things have to be integrated to create a functional platform for deploying applications into production?
- What’s included?
- What’s not included?
- How to manage integrations.
- What standards exist to make it simpler?
- What’s the difference between DIY, a Kubernetes distribution, a Kubernetes platform, or a Kubernetes cloud service?
Anatomy of a Release
The first thing you’ll probably notice that’s different between OSS and proprietary “releases” is that OSS often contains individual features marked as “alpha” or “beta’. In the Kubernetes 1.8 release, they are broken down between alpha, beta and “stable”. These relate to the levels of maturity of each feature, as determined by the project’s steering committee. Since OSS project software is DIY support, via mailing lists, Slack groups, IRC, etc., it’s up to companies to decide if they want to enable certain features.
If companies decide to use a commercial offering based on OSS, or a public cloud service based on OSS, then it’s important to understand what they will fully support vs. make available as “alpha or beta” support.
For example, from Google’s GKE service:
Who Built the Features?
Often times, after a release is published, people will attempt to analyze who developed certain features. Some vendors publish blogs highlighting their involvement (e.g. here, here, here). Other vendors highlight projects that add value outside the core project, as they focus more on training or services. You can always dig into the details through sites like Stackalytics or GitHub. You can also dig into the details of individual features or functional areas by reading the notes from the Special Interest Groups (SIG).
There are lots of opinions on how to interpret stats around OSS commits. Some believe they include too much vanity, or can be gamed. Others believe that they are a good indicator of how much an individual company (or person) is investing in a project, and how much they could help customers that want official support of an OSS project.
Updates Come More Frequently
The last thing to keep in mind is that OSS releases tend to come out much more frequently that proprietary releases. In the case of Kubernetes, it’s consistently been every 3 months. This means that if a company is running the software (vs. using a public cloud service), they need to make sure they are prepared to stay up-to-date with infrastructure/platform updates. They need to have skills around CI/CD and config management tools like Ansible, Chef, Puppet. . This is a skill that development teams have been evolving for the past few years, but it’s a skill that operations teams will have to improve quickly.