Kubernetes continues to gain steam in enterprises, and for good reason: It tames the complexity that arises as you begin to use containers at scale. It automates and orchestrates Linux container operations, eliminating many manual tasks involved in deploying and scaling containerized applications.
[ Why do containers and Kubernetes pair so well? See our related story: How enterprise IT uses Kubernetes. ]
Where is Kubernetes headed next? I got a good look at last week’s KubeCon conference in Copenhagen. Consider these three trends:
1. Continuous integration is key
Continuous integration was the central topic of the opening keynote by Dan Kohn, executive director of the Cloud Native Computing Foundation (CNCF). The fact that he used his high-profile airtime to highlight what is usually thought of as “just” a development technology is telling.
His context: Code quality remains relatively poor overall. One fix is highly automated testing and quality checks throughout the development pipeline. This includes both unit and integration testing as well as scans for security vulnerabilities. (See our related story: DevOps success: Why continuous is a key word.)
Test cases are also a great way for new contributors to get involved with an open source project, as Heather Kirsey, who heads Community and Ecosystem for the Linux Foundation OPNFV told me in an interview at the event. “We don’t need any more help with testing or documentation,” said no community manager ever.
If anything, I’d argue that continuous integration is too narrow a framing, in that it focuses specifically on the developer pipeline. In fact, the software supply chain also needs to be secured. Where did that container come from? And instances that have passed into production also need to be monitored for failures and to determine if any newly discovered vulnerabilities are relevant to them.
Furthermore, continuous integration is part of a broader story of rapid, iterative software development under the DevOps or DevSecOps rubric. Tools are important, but so is a mindset around automated process and, however touchy-feely it may sometimes seem, a culture that allows for community, collaboration, and experimentation.
2. Kubernetes intersects with more technologies
Analyst James Governor of RedMonk told me that he’s seeing more explicit intersections between Kubernetes and other projects and trends. For example, Google’s Kelsey Hightower gave a keynote at KubeCon about a proof of concept for using a broker to implement an event-driven serverless application in a way that didn’t lock a workload into a specific cloud.
The < id="docs-internal-guid-7138ccb7-2692-9020-e595-a80eacef95e2">CNCF landscape has cataloged an increasingly vast number of potentially connected projects in the cloud-native space for a while now. Many of these – such as Prometheus, Fluentd, and Jenkins – are already widely used in conjunction with Kubernetes, either in DIY manner or in the form of integrated products like Red Hat OpenShift.
But I agree with Governor that this conference saw an increased effort to make the deliberately autonomous projects within the CNCF explicitly integrate in various ways.
3. It’s about OCI containers
The Open Container Initiative (OCI) first established a runtime specification and an image specification for containers based on the existing de facto industry standard backed by most of the major vendors in the space. It’s provided a way for projects to work with and innovate on top of standardized containers in a manner that makes sense for them. For example, the Buildah project is a command-line tool that facilitates building OCI container images without running the heavyweight daemon, which increases complexity and attack surface.
Although the OCI specs have been around since June 2015, many people tended to still refer to them as Docker containers. However, this created ambiguity: Are you referring to the standardized container image and runtime? Or are you talking about tools associated with those standard containers that may be specific to a single vendor and may not even be open source?
At KubeCon, I saw a concerted effort, at least on the main stage, to use “OCI container” terminology. From my perspective, this is a welcome shift as it provides more precision in an area that’s seen a lot of confusion-inducing overloaded terminology. While these low-level details are hidden from most users of container platforms, it nonetheless helps to clarify the relationships between different projects and products in the container ecosystem.
[ Kubernetes terminology, demystified: Get our Kubernetes glossary cheat sheet for IT and business leaders. ]
