Key Takeaways from KubeCon 2022
In this blog
Current trends: Kubernetes today
The "State of Kubernetes" is a topic that is revisited yearly through a myriad of industry reports drawing conclusions from user surveys and usage data. Despite each of these reports having its own focus and target audience, in 2022 we have seen convergence on some key points in the reports generated by the Cloud Native Computing Foundation and two key WWT partners in VMware and RedHat.
Kubernetes has "crossed the chasm" into the mainstream
This year's surveys received the largest number of responses ever and Kubernetes' market domination continues. 96% of organizations are using or evaluating Kubernetes today and 93% of them use or plan to use containers in production, according to the CNCF. This train isn't slowing down either. The industry is witnessing exponential growth in these environments, with 48% of VMware's respondents expecting their cluster count to grow by at least 50% this year.
Large companies leading the charge for adoption and maturation
Each of these surveys received a significant number of responses from large companies of at least 5,000 employees, and these companies are setting the tone for the industry. Large companies are far more likely to use Kubernetes in production, and the pursuit of a hybrid or multi-cloud deployment model is strongly correlated to larger companies. Furthermore, a strong uptick in those pursuing a multi-cloud-only strategy was seen this year.
Kubernetes talent is in high demand
This landscape is evolving as quickly as it's growing, and key challenges around personnel continue to be top of mind. Organizations consistently report a lack of existing internal experience with Kubernetes, and an inability to in-source that expertise through hiring compounds the issue. Keeping resources up to speed on the latest and greatest is a similar struggle.
At KubeCon, it was very apparent that organizations adopting cloud-native technologies are struggling to find resources as the demand for their solutions internally grows. Not only did we see the typical "We're Hiring" PowerPoint slides in presentations, but we also saw companies purchasing booth floor space and handing out swag to attract resources to their company.
Kubernetes security remains challenging
Security is the other chief concern. Almost every organization (96%) reported having concerns about Kubernetes security to VMware and almost every respondent to RedHat (93%) experienced at least one Kubernetes security incident in the last year, with over half experiencing a delayed or slowed application deployment due to a security concern.
KubeCon 2022 addressed this concern head-on, with many sessions focused on securing software supply chains, enforcing compliance through policies, and embracing a security-first approach to development.
KubeCon 2022 takeaways
The platform team is the new infrastructure team
A trend we noticed at KubeCon was moving from focusing on individual infrastructure teams to platform teams. In some cases, this was a deliberate move and, in some cases, an unintended consequence. Delivering Kubernetes as a service successfully involves a high-performing team of experts in all areas of infrastructure, focusing on providing an experience to the developer or application analyst in mind. Such a focus requires a change in mindset that leads to treating the outcome of the Kubernetes deployment to be a platform. As a result, we saw a trend of teams referring to themselves as a platform team, not an infrastructure team.
GitOps has arrived
While it may sound like yet another buzzword to learn and understand, GitOps carries the promise of applying DevOps best practices used for application development and deployment to infrastructure. This relatively new term was heard frequently around the conference, both in sessions and from various vendors on the exposition floor. But what does it mean, and why is it important?
An easy way to think of GitOps is as an evolution of infrastructure automation, and in many ways, GitOps is a branch of DevOps. From a historical standpoint, infrastructure provisioning and maintenance have been manual in nature. With infrastructure-as-code, a Git repository becomes your source of truth for the infrastructure which supports one or more applications. GitOps takes that a step further and applies pipelining concepts like what is used for application code today. However, the real promise of GitOps is that it links application deployment to the deployment of the infrastructure which supports it. That means developers are no longer forced to wait for infrastructure teams to go through manual processes to provision infrastructure, further streamlining the process of development to delivery. At WWT, we intend to keep a close watch on this trend and anticipate it may further accelerate infrastructure automation initiatives.
Project or product? Open-source vs. commercialized software
After a decade of countless industries being disrupted by software-first approaches, every company is a software company. While cloud-native technologies have been widely embraced, an ongoing debate is about projects vs. products: Should a company buy a commercialized piece of software or leverage open-source software created by the community?
Buying productized pieces of software has long been the norm for most companies, due to a need for enterprise support. 97% of VMware's survey respondents would pay for enterprise support for important Kubernetes tools. Products also address the building, testing and integration of a tool into a solution that drives a business outcome. Finally, buying a product makes you a customer of a software vendor who is keen on keeping you happy by adding features and functionality relevant to your business.
The product approach still sounds great, so why are over 77% of organizations reporting an increase in the use of open-source software? The top reason is access to innovation and the latest technology. Companies must modernize their entire technology stack to effectively implement a cloud-native approach, and open-source is leading the way. When speed is the name of the game, the open-source's tendency to patch and release software more frequently is compelling.
The answer to "project or Product?" is going to be different for every company, and it will likely be some mixture of both. Having an open-source strategy is an increasingly valuable business proposition and the time to formulate one is now.
Emerging concepts: Kubernetes tomorrow
Sidecar-less service mesh
A service mesh is a layer of infrastructure that can be used to control and observe service-to-service communication within a Kubernetes environment. Implemented as a system of proxies, a common implementation of a service mesh is using a "sidecar" container. This container sits within the same pod as your application container and intercepts all communication to and from the application.
While this model does provide a significant level of control, there are some potential disadvantages to sidecars that some organizations may find unappealing. To address this, some service mesh implementations are moving to a sidecar-less model, with no need to modify or intrude on the application pods themselves. At WWT, we welcome this emerging concept not because one implementation model is better than the other, but simply because it provides more choices to platform teams. Every organization has its own set of requirements and having a choice of more than one implementation method allows those organizations to choose the service mesh which will best serve their needs.
Kubernetes as the global API catalog
At the heart of all Kubernetes clusters, there is an API Server. The Kubernetes API Server is well-known for being a scalable declarative API. Further, the API Server is quickly extensible via Custom Resource Definitions (CRDs). Imagine if you could take all the tooling used to manage your Kubernetes applications today and enable those tools to manage resources that do not live in Kubernetes. Projects like kcp.io are looking to help solve that problem by introducing the capability of running API servers that only use CRDs. This enables organizations to implement a Kubernetes API Server that acts as a global API catalog.
Remote control planes
A Kubernetes Remote control plane runs the control plane functions of a Kubernetes cluster (etcd, API-server, etc.) separate from the nodes participating in the cluster. The Hyperscalers have been running their managed Kubernetes deployments in this manner. However, we are seeing Kubernetes distributions and open-source projects starting to expose this capability as more of a turnkey feature. Red Hat's upstream project, HyperShift, is one example. This design helps organizations consolidate compute resource requirements, segment the responsibilities of those managing the platform from those consuming the platform's resources, and provide an accelerated way of deploying clusters. Adel Zaalouk wrote an excellent article on why and how to use Hosted Control Planes in an OpenShift environment.