I have to admit, that’s I’ve been brooding about this for two days now. Yesterday, July 9, 2020, Google announced the creation of the Open Usage Commons organization. On the
The Emergence of Kubernetes Control Planes
This blog was also published on the Amalgam Insights website. As is the case with all new technology, container cluster deployments began small. There were some companies, Google for example,
How Are You?
It’s the first of April here in Western New York where I live. The sun is shining, days are getting a little longer, and the trees are budding. It would
Open Usage Commons is Just Wrong
I have to admit, that’s I’ve been brooding about this for two days now. Yesterday, July 9, 2020, Google announced the creation of the Open Usage Commons organization. On the surface, the OUC (pronounced “uc”? Ooc?) seems like just another one of the many not-for-profits formed to assist an open source community to develop and license software created by many companies together. They announced three projects would be part of OUC, Istio, Angular, and Gerrit. So far pretty normal for moving open core to real open source with independent governance.
Except it’s not. What seemed redundant at best is much more nefarious. The OUC (oh you cee? It’s a bad name…) only holds the trademarks of these open source projects. The copyrights and potentially patents are held elsewhere. It’s like owning a car but someone else owns the paint. Why would anyone want this?
To get to why this is so odd, we need to talk about intellectual property. There are three main types of intellectual property (IP) in the US system, trademarks, copyrights, and patents. All three are meant to protect a different form of intellectual output or ‘art”. A software product may be protected by a patent but it’s not that common. Patents need to be unique inventions and are typically physical products. There is a type of patent, a process patent, that applies to some software, but it is not how the majority of software is protected. This has been an ongoing issue with software for 30+ years. Patents don’t’ really work for software.
Copyrights protect artistic works such as art and writing. Software is typically protected by copyrights since it is an ephemeral “written” work. The ability to use a copyrighted work, including open source software, is controlled by licenses. In fact, what differentiates open source from proprietary software is the license, which grants the right to use and modify the software for free as long as you follow the license. A typical component of an open source license is the requirement to submit changes made to the software to the community to see if they can benefit everyone.
Finally, trademark protections are for the outward identification of an entity or product within a domain. Logos, names, graphics that identify something, these are trademarks. This blog is protected by copyright, as a written work, and the site name and logos via trademarks.
Software as a product is protected primarily by copyrights and trademarks. The code is protected by copyright and the name and accompanying identifying graphics via trademarks.
Now this is where things get weird. The OUC (Oh oo cay? I really hate the name…) exists to manage only the trademarks of open source projects. This means that the copyrights for Istio, Gerrit, and Angular are held by some other organization or company, and the trademarks by OUC (I’ve run out of jokes about the name.) Separating the IP into multiple organizations, and hence multiple licenses, seems confusing at best. This is like financial derivatives where mortgage interest and principle are stripped apart from each other and sold separately. We remember how well that worked in the 2000s.
At worst, this is a way to control who can actually use open source software without actually saying so publicly. You may have the right to use and productize software such as Istio, as Red Hat, Rancher, and others have done, but not be given the rights to use the name without a second license. That has two effects. First it requires separate licenses and hence negotiations for different parts of the total IP. The open source license will give the licensee rights to the copyright but the OUC can refuse the trademark license. Second, it creates a situation where license may not always agree and could hinder the ability to market the software. You could then have your open source ducks in a row but be stuck in negotiations with OUG. While all of that is possible, that’s not even the worst part. What’s worse is that it allows Google through the OUC to claim independent governance for the projects when it’s really only the trademarks.
Istio is a prime example of this problem. The cloud native community has, for some time, been expecting that the Istio software would be given to the CNCF, just like Kubernetes. The fact that this hasn’t happened yet has been a drag on Istio’s adoption and called into question it’s future viability. Needless to say, the cloud native community is perplexed and annoyed by this move. CNCF is very much capable of managing both the copyrights and trademarks of Istio, along with the project itself. Even if the copyrights for Istio eventually end up with the CNCF or Apache Software Foundation or some other established foundation, the OUG will have the trademarks. That means two licenses for anyone trying to productize Istio, something CNCF can accomplish with one. At best, it’s needless complexity.
So, here’s my advice to the communities that have been working on these projects. If at all possible, immediately fork the software into another project and join an established not-for-profit. If that’s not possible then abandon it. Vendors will have to create new distributions. While that’s lousy, it’s worse to be a part of something as suspicious and with such a monumentally bad name as OUC. You know, maybe the name is code for Owned Universally by Corporations.
The Emergence of Kubernetes Control Planes
This blog was also published on the Amalgam Insights website.
As is the case with all new technology, container cluster deployments began small. There were some companies, Google for example, that were deploying sizable clusters, but these were not the norm. Instead, there were some test beds and small, greenfield applications. As the technology proved itself and matured, more organizations adopted containers and the market favorite container orchestrator, Kubernetes. The emergence of Kubernetes was, in fact, a leading indicator that containers were starting to see more widespread adoption in real applications. The more containers deployed, the greater the need for software to automate their lifecycle. Even so, it was unusual to find organizations standing up many Kubernetes clusters, especially geographically dispersed clusters.
That is beginning to change. Organizations that have adopted containers and Kubernetes are starting to struggle with managing multiple clusters spread throughout an enterprise. Just as managing large amounts of containers in a cluster was the impetus for orchestrators such as Kubernetes, new software is needed to manage large scale multi-cluster environments. At the same time, Kubernetes clusters have been getting more complex internally. From humble beginnings of a handful of containers with a microservice or two, clusters now include containers for networking including service mesh sidecars and data planes, logging, app performance monitoring, database connectivity, and storage. All that is in addition to the growing number of microservices being deployed.
In a nutshell, there are now a greater number of larger and more complex Kubernetes containers clusters being deployed. It is no longer enough to manage the lifecycle of the containers. It is now necessary to manage the lifecycle of the cluster itself. This is the purpose of a Kubernetes control plane.
Kubernetes control planes comprise of a series of functions that manage the health and well-being of the cluster. Common features are:
- Cluster lifecycle management including provisioning of clusters, often from templates for common types of clusters.
- Versioning including updates to Kubernetes itself.
- Security and Auditing
- Visibility, Monitoring, and Logging
Kubernetes control planes are policy driven and automated. This allows operators to focus on governance while the control plane software does the rest. Not only does this reduce errors but allows for faster responses to changes or problems that may arise. This automation is necessary since managing many large multi-site clusters by hand would require large amounts of manpower and, hence, cost.
Software vendors have stepped with products to meet this emerging need. In the past year, products that implement a Kubernetes control plane have been announced or deployed by Rancher, Platform9, IBM’s Red Hat division (Advanced Cluster Management) , and VMware (Tanzu Mission Control) and more. All of these Kubernetes control planes are designed for multi-cloud, hybrid clusters and are packaged either as part of to a Kubernetes distribution or an aftermarket addition to a company’s Kubernetes product.
Kubernetes control planes are a sign of the normalization of container clusters. The growth both in complexity and scale of container clusters necessitates a management layer that helps DevOps teams to more quickly standup and manage clusters. This is the only way that platform operations can match the speed of Agile development and automated CI/CD toolchains. It is yet another piece of the emerging platform that will be where our modern cloud native applications will live.
