Increased spending to scale-up of Kubernetes deployments has created excitement about what’s next at the heart of the cloud native universe, but there is considerable confusion and low adoption in many areas of this Infrastructure as Code universe. For now, the promise of service catalogs full of operators seems far in the future. To understand why, we looked at Canonical’s Kubernetes and Cloud Native Operations Report 2021, which surveyed 1,200 IT professionals, many of whom came from Canonical’s Ubuntu-using customer base.
Although Kubernetes has long ago passed its peak of expectations and trough of disillusionment, only 46% were of enterprises are actually using Kubernetes in production, according to this report. However, almost everyone else is considering moving more applications over to Kubernetes. How quickly these workloads will scale up will determine which technologies gain favor over the next few years.
One interesting note to the report: Only 17% of respondents with Kubernetes in production are using operators for applications in production. In contrast, 72% say their team has used or modified a Helm chart in the last 90 days. Our own exploration into this topic, Mary Branscombe’s “Kubernetes: When to Use, and When to Avoid, the Operator Pattern” explains why operators are not for everyone, and shows that companies haven’t gotten ahead of themselves.
Canonical is keenly interested in people’s understanding of Kubernetes operators because it provides Juju, which is an open source application modeling tool that is part of a larger “Charmed Operator Framework” that company positions versus other operators, Helm, Ansible, Terraform and Kustomize.
When users were asked about their preferred method of operating, upgrading or maintaining software on Kubernetes, Helm came out on top with 28% of the vote, compared to 17% for configuration management tools like Ansible, 10% and for operators (including KUDO). Helm does even better, going up to 38% among organizations that running Kubernetes in production. As organizations move into production, they become less likely to use scripts and legacy configuration management tools but no more likely to use a product like the one Canonical offers.
There is a lot of confusion about what operators are but if everyone knew the correct definition they still would not be widely adopted, yet. The Kubernetes official documentation says that operator patterns are software extensions that make use of custom resources to manage applications and their components.
When presented with six different options, only 31% agreed that this definition most accurately describes what an operator is. But, half (50%) of the people using operators in production use cases got the definition “correct.” Almost half (46%) of them also think they’re the “answer” to too many Helm charts. Perhaps they do have a future, but it isn’t now.
Alexis Richardson, Founder and CEO of Weaveworks believes operators are necessary in order to really use data in Kubernetes. He was quoted in the report saying, “Platform teams are going to be sophisticated users of operators and then app dev teams will consider them basically as add-ons.” In his view, Helm, Juju, and operators are just things to select in an enterprise app store.
What does this all mean for you? A lack of skills is the top challenge people are facing with Kubernetes. It doesn’t matter if you look at it from the angle of CI/CD, GitOps, cloud, whatever, James Strachan, a distinguished engineer at CloudBees and creator of Groovy and Apache Camel, believes that the only solution is to learn by doing; pick a path and try the new tech.
Actually understanding what a technology is a big first step. After a decade of discussion, at least four-fifths of this survey believe a hybrid cloud includes at least one private and one public cloud. We can use that as a baseline for how much agreement we can get among the community.
The questionnaire also asked, “in the infrastructure space, what does the term ‘substrate’ mean to you?” Huh? That’s what 35% of people said to themselves because they had no idea what it meant. Twenty-seven percent believe a substrate is a base infrastructure that you build everything upon, but “VM/container,” “abstraction layer,” “bare metal” and “physical layer” got votes as well. Kelsey Hightower, principal developer and Google Cloud Platform advocate at Google, believes “platform” is a more appropriate term to use in this context.
“Kubernetes is the control plane for the most part (in K8s-only environments),” but one that operators can extend across substrates, said Ken Sipe, a Senior Enterprise Architect at Edward Jones, in the Canonical report.
Someone Else’s Terms
Substrate is also a popular framework, one for blockchain development, built by Parity Technologies, the same company behind Polkadot. After the latest crypto craze cools down, there is going to be a real batch of Web 3.0 infrastructure that enterprises will use. If Big Tech isn’t careful, they will be selling into a market defined on someone else’s terms. This Substrate may be a keeper because it lets developers write logic using WebAssembly.
“Reality is what the majority of people perceive it to be,” Sipe said. He probably correct. Perceptions of technology definitions and market categories can have broad implications because investments are often made based on them. Observability, cloud native, data science, Jamstack, you name it and debate continues about some buzzwords. Which do you think The New Stack should challenge next?
- Operator Framework
- The Charmed Operator Collection
- CNCF Operator White Paper – Review Version
The Cloud Native Computing Foundation, Cloudbees and Weaveworks are sponsors of The New Stack.
Feature image is a photo by Rex Sorgatz of Brughel’s Tower of Babel.