 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
In the popular book “Working in Public: The Making and Maintenance of Open Source Software,” author Nadia Eghbal created the following new taxonomy for open source projects based on user growth and contributor growth:
The low user-growth solutions are often niche. The high user-growth open source solutions often invite competition if it isn’t already there. Federations like Linux Foundation and the Cloud Native Computing Foundation are the pinnacle of open source that support an entire ecosystem — like Linux and Kubernetes themselves.
Stadiums are projects where a large community enthusiastically watches a few contributors do their thing — much like how you watch your favorite sports team in your favorite stadium. These stadiums are often part of the ecosystem built by federations.
It is heartening that these high-growth categories are no longer exclusive to commercial solutions alone. For many years, Microsoft protected its turf from Linux by making its most popular products incompatible with Linux. Apple built a similar ecosystem by not playing nice with the alternatives. Of course, this strategy is only effective if the commercial solution is the market leader.
In the world of cloud native and Kubernetes, open source solutions are the incumbent, the default choice for the customer. Here, the tables have turned, and the commercial solutions now carry the obligation to be compatible with open source projects or face many perils.
Let’s examine why enterprises make the switch from open source and what they must consider in an open source-dominated ecosystem like Kubernetes. Open source adoption has long been a “time vs. money” decision for enterprises. You can choose to spend money to save time or spend time to save money. With flourishing open source communities, does this primary hypothesis still hold? Do people pick open source based on time savings alone?
Here are a few other important factors that enterprises consider:
The most common reason to pick a commercial solution need not be technology but its relationships. Very successful large vendors offer a portfolio of products and build relationships with their customers and emerge as the “one throat to choke,” which is essentially based on dependability.
This is a factor that the Linux Foundation, several cloud vendors and Day 2 Kubernetes management platforms are looking to overcome by building a cohesive ecosystem. When you choose based on vendor relationships, it is key to either look for larger companies with a relevant portfolio or smaller vendors with a strong partnering track record.
Not everyone buys the most cost-efficient car on the market. There are those who prefer comfort, performance, reliability, safety, maintenance and fuel type/efficiency. Open source software tends to have crowdsourced benefits when dealing with objective items such as performance and security, which applies to everyone. But the highly subjective challenges on usability and manageability mostly remain a challenge.
The community often ends up building good commuter car engines and fitting them with a cockpit that requires hundreds of hours of experience. If better fit and usability is one of your top concerns, you’ll get better bang for your buck if you buy into commercial open source solutions that build on top of the most popular open source solution to address enterprise requirements.
A commercial solution often treats its larger customers with care. In open source projects with high user growth, there is no differentiating between small and large customers. This creates an incentive to focus on features that affect the most users and thus roadmaps become popularity contests.
An enterprise with more complex needs may feel left behind, forcing it to contribute or seek alternatives — either creating the necessary tooling or moving to a commercial solution. When selecting a solution, one must always begin with the end in mind. How big do you expect to get, and can your solution grow seamlessly?
An often overlooked and underappreciated challenge is documentation. While we are making significant progress to set standards for security with good adherence, documentation standards have been all over the place. Some of the most successful open source technologies have grown adoption through solid documentation because it is not code that people read to understand and adopt technology.
Promoting understanding is the key value of documentation. You can’t fix this problem overnight, but you can look for a commercial vendor that has a deep understanding of the open source technology in use. What is their experience in using and supporting that technology? Do they participate in the community and help?
Now, let’s consider the case of the smooth-sailing Velero — an unchallenged open source backup tool for Kubernetes. Velero has over 50 million Docker Hub pulls — if you use a 1% conversion to real workloads, it implies over 500,000 clusters are being backed up.
In terms of community activity, there are over 2,500 issues closed and roughly 400 issues open with barely 10 active contributors. There are over 3,000 users in the Kubernetes #velero-users Slack workspace, and yet less than 10 people participate on community calls each week. This is a clear case of a stadium project; lots of users but a fairly centralized and small contributor community.
Velero is popular and serves an essential need, but why do people switch to a different Kubernetes backup product? This GigaOm Radar for Kubernetes Data Protection implies that there are at least 13 other solutions available.
VMware is the community sponsor for Velero, but VMware only includes commercial support for it if you have enterprise Tanzu licenses. If you have no need for Tanzu, then you need to look elsewhere to get support, hence the 3000 #velero-users in Slack.
Velero is functionally on par or superior to any other backup solution in terms of protecting Kubernetes workloads, but usability and scalability remain a challenge. Lack of policy-driven templates, user interface, monitoring and alerting, and guided recoveries are all key requirements of users that remain unaddressed.
Velero is also designed as a single cluster offering. It works great for backing up one Kubernetes cluster, but managing a multicluster estate is an issue. If you combine multiclusters with a multicloud strategy, managing backups becomes even more tricky and time-consuming.
Despite these unmet needs, Velero today maintains almost two orders of magnitude advantage over its nearest commercial competitor. This is a sign that Velero is becoming a standard, something its maintainers have also observed. Standardization increases the risk that any competing commercial data-protection solution you choose may end up as a niche solution or, worse as abandonware.
The popularity and sustainability of Velero may feel contradictory to its suitability at scale, or lack thereof. Enterprises that are dealing with this quandary must ask themselves if there is a way to have their cake and eat it too. Are there solutions that solve the scale and usability challenges on top of the open source Velero engine? Can one subscribe to an enterprise service that uses Velero? Can I adopt such a solution without having to migrate? Are there exit/egress costs?
It is clear that commercial vendors in the Kubernetes and cloud native communities must embrace and extend open source solutions such as Velero or they will be “toying” with their future and sacrificing a seat at the table when solutions are being considered by enterprises. It is, however, great that open source communities like Velero are building a longer table rather than taller fences.
