If your organization is ready to go all in on the Kubernetes orchestration manager and you’re looking for a way to package applications for easy deployment, you’ll probably gravitate to Helm, an open-source project incubating within the Cloud Native Computing Foundation.

But you may also want to check out Docker Compose from the company that popularized containers. Or Draft, a project born at Microsoft Corp. by the same people who developed Helm. Or the Open Service Broker API, or Habitat, or any of 17 different open-source options for package management. The CNCF lists them all on its Landscape page, along with 272 other cloud-native open-source projects. And the list grows longer every week.

Some people might call this profusion of choice chaos. Others say it’s a bounty born of innovation. Either way, the ecosystem that has developed around Kubernetes has become at once one of its defining strengths but also a source of confusion. For organizations ready to place big bets on Kubernetes, simply choosing wisely among the many available extensions and application programming interfaces is becoming one of their biggest challenges.

IBM’s Jason McGee: “I don’t envy the average enterprise trying to assemble all of this stuff.”

“It’s amazing how much activity there is around this space, but I don’t envy the average enterprise trying to assemble all of this stuff,” said Jason McGee, chief technology officer of IBM Corp.’s Cloud Platform. McGee delivered a keynote address at the sold-out KubeCon conference in Seattle this week, where 8,000 enthusiasts assembled to learn more about the hottest technology to hit the data center since virtualization.

Kubernetes is the cloud-native platform that is upending the way applications are developed. The software, which was built by Google LLC and released to open source four years ago, has quickly become the dominant platform for deploying and managing large numbers of software containers, which are self-contained package of software that include all the code and dependencies an application needs to run across multiple environments.

Kubernetes has been adopted in its native form by nearly every computer and cloud infrastructure company, an almost unprecedented feat. A big reason is that the existence of a single reference platform has spawned a huge large community of developers who are extending Kubernetes’ core capabilities kinds in areas such as monitoring, logging, security and storage.

The CNCF’s Landscape is like an app store for cloud developers. The existence of a robust third-party ecosystem was a big part of the reason Bloomberg L.P. has chosen to shift much of its massive development operation to Kubernetes, said Steven Bower, data analytics and infrastructure lead at the financial news and analytics firm. “Instead of everything being in Kubernetes, you can use the [Container Network Interface] to mix and match pieces from different projects,” he said, referring to Kubernetes’ native specification for enabling network plug-ins to work with containers.

“The ecosystem for Kubernetes has been incredibly strong because the market recognized just how powerful Kubernetes would be,” said Dan Garfield, chief evangelist at Codefresh Inc., which sells continuous delivery platform for Kubernetes. “A universal API for cloud? Yes, please.”

Wild West scenario

But some experts warn that the ecosystem is a bit of a Wild West scenario at the moment, with many projects vying for attention and few clear leaders. Making the wrong choice may force organizations into a time-consuming migration process a couple of years down the road.

Wikibon’s Kobielus: Kubernetes ecosystem is “a minefield of evolving open-source projects.”

“Enterprises that adopt Kubernetes now are treading in a minefield of evolving open-source projects,” said James Kobielus, lead analyst at SiliconANGLE sister market research company Wikibon. “They still don’t add up to a mature, vendor-agnostic stack that addresses a comprehensive range of production-grade enterprise application use cases.”

One reason the ecosystem has developed so quickly is the way Kubernetes moved from Google’s ownership into the hands of the community. Google leaders knew from experience that trying to control the project would repel competitors from contributing and prevent the platform from reaching escape velocity. They wanted to avoid the fragmentation that has undermined other promising open-source projects. One prime example: OpenStack, an infrastructure-as-a-service platform that some people say has failed to live up to its promise because of infighting between members of its supporting foundation and too many derivative versions of its code.

“To win in the wider world, we had to let go of control and trust that whatever gaps we left are clean, so others can fit in,” said Tim Hockin, senior software staff engineer at Google and one of Kubernetes’ principal developers. “The surface area had to be finite and the ecosystem had to thrive.”

If Kubernetes were only open source from Google, said Gregg Siegfried, a Gartner Inc. research director, “it would have nowhere near the traction it has today.”

Linux emulation

Thus the CNCF was born. When Google was preparing to release Kubernetes to open source in 2014, it chose to bypass the Apache Foundation, which was already nurturing a competing project called Mesos, and instead partner with the Linux Foundation to create the CNCF as a new governing body for cloud-native software. The Linux Foundation’s track record at championing a single Linux kernel was a model for how Google hoped Kubernetes would develop.

Open-source governing bodies constantly struggle with the often conflicting interests of contributors, particularly those that sell related products and services. “There’s a tension between innovation and stability,” said Dave Bartoletti, vice president and principal analyst at Forrester Research Inc. “Those companies have to monetize. To monetize something, it has to be stable.”

Kubernetes’ developers wanted to stabilize the core and foster innovation in the ecosystem. The CNCF’s task was to pull an entire industry of ardent competitors together around a single Kubernetes code base. It borrowed from the Linux playbook by developing a Certified Kubernetes Conformance Program to verify that Kubernetes distributions were consistent with each other.

So far, 90 packaged and hosted Kubernetes distributions have earned certification, all but guaranteeing that variances called “forks” won’t emerge. The CNCF also requires members to submit any patches they create back to the community for consideration, thereby limiting the risk of inadvertent forks.

The CNCF then broke from the pack in the way it approached adoption and nurturing of ecosystem open-source projects. One of the functions of open-source foundations is to pick winners by designating certain projects to receive services such as project management, support, documentation promotion and other resources that help move them along to fruition. Such projects are said to be “incubating” until mature enough to be “graduated.”

Get Cloud Native’s O’Reilly: “The CNCF has been able to get people who wouldn’t normally talk to talk.”

The CNCF founders thought the Apache policies were restrictive and too focused on developers. They wanted a more inclusive approach. “We wanted to start fresh without all the policies and procedures of an Apache project,” said Patrick O’Reilly, one of the founding members of the CNCF and now chief executive officer of Get Cloud Native Inc., a company that helps enterprises migrate to cloud platforms.

The foundation lowered the barriers to moving projects into incubation and pushed much of the decision-making down to the project owners. “The CNCF has been able to get people who wouldn’t normally talk to talk,” O’Reilly said. “I’m not saying it’s the best approach, but it’s the best we have now.”

Now the CNCF’s technical oversight committee is the sole arbiter of decisions about incubating new projects. It’s kept separate from the governing board, whose members include vendors and others with commercial interests. The foundation also requires each project to have a neutral governance process to minimize pressure from the industry.

“The Apache community process is a little heavy-handed and doesn’t allow for rapid evolution and diverse points of view,” said Gartner’s Siegfried. The CNCF “has been more nurturing in managing the community process.”

In fact, some people think the CNCF is a model for how open-source projects will be handled in the future. “Basically, it’s reinventing the app development platform for a new world of microservices,” said Wikibon’s Kobielus. “It’s a very ambitious effort that’s unprecedented in the history of computing.”

The downside of fewer rules, though, is greater uncertainty. And the jury is still out on whether the CNCF approach is superior to others at balancing innovation and stability. So far, only two projects other than Kubernetes have reached graduated status: Envoy, a proxy server that simplifies network service provisioning, and the Prometheus monitoring platform.

But it’s still early, and projects can take years to incubate. At the moment, “the Kubernetes ecosystem has become a bewildering field of dozens of vendor-tweaked distributions and hosted cloud implementations,” said Kobielus. “The deepening stack of open-source projects that build on and supplement the Google-spawned Kubernetes is twice as confusing.”

Order from disorder

The profusion of choices is at least in part intentional. One of Google’s objectives in releasing Kubernetes to the community was to pare down the core code base over time and move more features into extensions. Kubernetes itself is already “radically different than it was when we released it,” Hocking said. “We would like to eject more things from the core.”

Chris Aniszczyk, chief technology officer at the CNCF, said the foundation is trying to stay true to that principle. “Kubernetes has been very focused on moving things out of the core and making it as extensible as possible,” he said this week in an interview on theCUBE, SiliconANGLE’s livestreaming platform (below).

For organizations that want to deepen their commitment to Kubernetes, though, the diversity can create some uncomfortable choices. The issue is particularly worrisome for large enterprises that “may have either legal regulatory compliance requirements or internal standards that they need to adhere to,” said Brian Johnson, CEO of DivvyCloud Corp., a policy-driven automation of cloud security and compliance company. For most ecosystem projects, he said, “there aren’t clear technical controls or best practice processes for addressing these concerns yet.”

Picking winning projects can put an organization in a better position to leverage the communities that develop around them, since successful projects spawn further innovation. “In the open-source world there’s a river of momentum that flows and captures all the energy,” said IBM’s McGee. “You want to align with that river.”

As some of the currently incubating projects graduate and others fall by the wayside, the Kubernetes ecosystem will become less of “a basket of tools that you’ve got to make into your own,” said Siegfried. “It’ll become a more integrated whole.”

There’s evidence that the Kubernetes ecosystem is beginning to consolidate. “The velocity of commits for the core Kubernetes project seems to be slowing down,” Sourced Technologies S.L. said this week based upon an analysis of activity in the GitHub repository.

Forrester’s Bartoletti: “Enterprises need to ask if they’re a platform builder, a platform operator or a platform consumer.”

“I already see the first round of consolidation happening,” said IBM’s McGee, “but we’re still in the phase of building the ecosystem agreeing on how those pieces come together.”

The cycle isn’t new. There were more than 20 varieties of Unix at one point before the industry settled on Linux. The Hadoop big-data ecosystem was dauntingly complex in its early days until software vendors and cloud companies stepped in to simplify the deployment and integration process. “The most likely outcome is that there will be five to 10 mainstream Kubernetes frameworks that will have been battle-tested and vetted by early-adopter enterprises,” said Johnson.

To a large extent, the speed with which Kubernetes has been adopted has hastened the maturation process, O’Reilly said. “Once you get banks coming in, people don’t want major changes.”

The choice for IT

So how should information technology managers make decisions in the meantime? Forrester’s Bartoletti said for most companies, that won’t even be an issue.

“Enterprises need to ask first if they’re a platform builder, a platform operator or a platform consumer,” he said. “That choice dictates how you assign resources.”

Bartoletti defined platform builders as companies whose businesses depend upon creating applications on top of the Kubernetes platform. They have the most at stake in making the right ecosystem choices. Operators will prefer to host their own Kubernetes instances but don’t see the platform as strategic. Consumers just want a platform that works and don’t particularly care where it comes from.

“If you build travel reservation systems, it might be important to you to be on the cutting edge because you use the platform to differentiate,” Bartoletti said. “But the average enterprise probably doesn’t need to join all these communities.”

Operators can avoid getting bogged down in choices by aligning themselves with commercial Kubernetes providers that are already active contributors to the ecosystem, such as IBM, Red Hat Inc. or Pivotal Software Inc. “If Pivotal is working beautifully for you, there’s no reason to change,” he said. “It’s Pivotal’s job to make it all work.”

For platform consumers, the best bet is probably to choose one of the major public cloud providers that offer fully managed services and are responsible for keeping customers current.

Despite the current confusion, customers shouldn’t wait on the sidelines, experts said. One of the virtues of open-source projects is that they’re based on standardized toolsets and can adapt to changes in the landscape. For example, Docker Inc.’s initial choice of its own Swarm orchestrator over Kubernetes didn’t prevent it from integrating with Kubernetes later, and Swarm continues to be a viable alternative.

Responsible open-source providers don’t make dead-end decisions. “There’s a chance [Amazon Web Services Inc.] will shift from Lambda to another serverless platform in the future, but will people regret using Lambda?” Bartoletti asked. “None of my clients do.”

It’s this fact that should calm the concerns of IT managers about the decisions they have to make: In an open-source world, even the wrong choices can turn out all right.

Featured photo: Max Pixel; others: SiliconANGLE