freshidea - Fotolia
SAN DIEGO -- Kubernetes releases were noteworthy events as recently as March, but at the container orchestration platform's conference here this week, the next version of Kubernetes was the last thing anyone talked about.
Make no mistake, KubeCon + CloudNativeCon North America 2019 is booming: its growth from a 500-person event in its first iteration seven years ago to a 12,200-person behemoth this year has been dramatic, and shows no signs of slowing. However, presentations and conversations here reflected a shift in focus away from the features of the core Kubernetes platform itself, and toward the higher-level problems container orchestration and cloud-native applications can address for enterprises, such as more fluid management of stateful workloads and GitOps application delivery patterns.
"We're reaching the point where Kubernetes could become 'the usual,'" said Tom Petrocelli, an analyst at Amalgam Insights in Arlington, Mass. "It's not exciting anymore, but without the stuff that sounds boring --monitoring and observability, security, networking and storage -- [containers] aren't going to be useful to most enterprises."
Kubernetes' stability -- its "boringness" -- is reflected in the most recent Kubernetes releases. The last Kubernetes release to make a real splash was 1.14, which added GA Windows node support. Version 1.15, released in July, focused on extensibility and improved cluster lifecycle functions; Version 1.16 in September contained the first stable release of custom resource definitions, the primary method of extending core Kubernetes. The second beta version of Kubernetes 1.17 was released this week as KubeCon kicked off, in anticipation of general availability Dec 9 but barely warranted a passing mention on the keynote stage here. Contrast this with last year's show, where the beta version of Kubernetes 1.13 and its storage improvements, as well as the delay of Windows node support until 1.14, were major topics of discussion.
There's still work to do on Kubernetes releases, of course. The market must also winnow down the dozens of Kubernetes distributions and vendor platforms available. A lack of solid Kubernetes documentation is a well-known problem in the community. But for the most part, the cloud-native community is no longer focused on anticipated updates to the core platform.
Multi-cloud dreams fuel stateful Kubernetes apps
Now that Kubernetes has stabilized and become common in production environments, enterprise IT pros have begun to puzzle out how to use it for applications that once seemed beyond the reach of containers, from sensitive workloads that require multi-tenant security to stateful apps such as databases.
Tom PetrocelliAnalyst, Amalgam Insights
In the year following the 1.0 Kubernetes release in 2015, some IT pros argued that stateful apps had no place in containers. But more than one presentation here this week was given by IT pros who don't share that opinion, and a market has developed for open source and vendor tools that support containerized databases.
In part, stateful apps have found a home in Kubernetes among companies that want full multi-cloud portability. Nozzle Corp., an enterprise search rank tracking firm, moved a 20 terabyte MySQL database from Azure to Google Cloud Platform in just under an hour this year using a Cloud Native Computing Foundation (CNCF) MySQL database clustering system project called Vitess, according to a presentation here.
"The whole transition experience was night and day" compared to an earlier move from Google App Engine to Azure, said Derek Perkins, founder and CEO of Nozzle, based in Lehi, Utah. "It was almost scarily easy -- I was prepared for things to go wrong, and they didn't."
Vitess, which graduated from incubation in the CNCF and found commercial backing in a new company, PlanetScale, which launched here this week, is not alone in the market. PlanetScale competitor NuoDB announced a partnership with Rancher Labs, and Lyft showed off its open source big data pipeline tool, called Flyte. Larger firms such as D2iQ have also recently launched projects to manage stateful big data apps on Kubernetes.
Kubernetes platforms underpin GitOps at major financial firms
At blue-chip financial firms such as Fidelity Investments and Intuit, Kubernetes releases are old news, and GitOps workflows are now en vogue. Reps from both companies presented here about how they use Kubernetes-based container platforms to perform version-controlled, automated releases of both applications and software-defined infrastructure with tools such as Weaveworks' Flux.
"When you have thousands of developers working at a very fast pace, with a constant push for innovation, [a Kubernetes platform] becomes… valuable," said Rajarajan Pudupatti, director of cloud platform architecture for Fidelity, a Boston-based financial services company. "Rolling out an update to an existing process when you have a complex workflow and many security gates is very difficult, so packaging an application's context as part of an [automated] platform is of immense value to us."
GitOps tools in the CNCF universe have begun to mature, and even merge, as Flux did this week with Argo CD, a homegrown open source tool created by financial software maker Intuit, forming an integrated project called Argo Flux.
"We needed a system that could manage multiple AWS accounts and Kubernetes clusters [that underlay] applications, with a very simple, low-friction developer experience," said Edward Lee, a distinguished engineer at Intuit, based in Mountain View, Calif. "GitOps is a great way to do that [because] it's very easy to understand what should be running in production -- if there's anything running on a cluster that shouldn't be, it's very easy to detect it."
GitOps also allows Intuit to describe with declarative programming the desired end state of blue/green deployments without having to script all the necessary steps, Lee said.
All quiet on the Knative front
Knative, a topic of interest in the months that followed KubeCon North America 2018, was relatively quiet at this year's conference. Analysts chalked this up to the chilling effect of an announcement last month that Google would not donate the project to CNCF.
"Everyone was expecting Google to hand over the reins of Knative and Istio, and they refused," Amalgam's Petrocelli said. This froze the market, at least temporarily, and created room for competitors to sow doubts about the project in the weeks leading up to KubeCon. "The timing [of the governance announcement] was unfortunate -- it kind of sucked the air right out of that room."
Knative maintainers have since more clearly articulated an open governance model for the project, but the damage may have already been done, at least in the short term, Petrocelli said.
CNCF officials are quite deliberately staying away from Knative controversy, and have no plans to introduce a CNCF competitor to Knative for event-driven compute automation. Instead, the foundation's Serverless Working Group will focus on projects such as CloudEvents, which reached version 1.0 this week. CloudEvents creates a specification for describing event data used by utilities such as Knative, Azure Functions and OpenFaaS, among others.