Originally sourced from information-age.com (April 2020). Expanded and rewritten for a DevOps engineering audience.
Why Kubernetes Has Become Impossible to Ignore
Every generation of enterprise IT produces a handful of technologies that cut through complexity and shift what’s possible. Kubernetes is one of them. At its core, Kubernetes is an open-source platform that automates the deployment, scaling, and operation of containerised applications across clusters of hosts. What began as an internal Google project became one of the fastest-growing open-source ecosystems on record after it was donated to the Cloud Native Computing Foundation (CNCF).
The trajectory of container adoption makes the relevance of Kubernetes hard to overstate. A Red Hat survey cited in the original source found that a large majority of organisations had minimal container use at the time, but expected adoption to grow dramatically within two years — including a near-tripling of the proportion running more than half their workloads in containers. Regardless of the precise figures, the directional trend is clear and widely corroborated by industry data: containers are moving from experimental to mission-critical.
From Packaging Format to Innovation Platform
Early conversations about containers centred on cost optimisation — running more workloads per host, reducing VM sprawl, and improving density. That framing has largely been superseded. Enterprise architects now treat container platforms primarily as enablers of developer velocity and organisational agility, with infrastructure efficiency as a welcome side-effect.
This shift has boardroom implications. A viable container orchestration strategy — and Kubernetes in particular — belongs on every CIO’s technology roadmap, not as an infrastructure footnote but as a prerequisite for competitive software delivery.
What Kubernetes Actually Does
Kubernetes is a vendor-agnostic cluster and container management system. In practical terms, it handles:
- Scheduling: Placing containers on appropriate nodes based on resource availability and defined constraints.
- Self-healing: Automatically restarting failed containers, replacing unhealthy nodes, and rescheduling workloads.
- Scaling: Scaling applications horizontally in response to load, either manually or automatically via the Horizontal Pod Autoscaler.
- Service discovery and load balancing: Exposing containers using DNS names or IP addresses and distributing traffic across them.
- Rollouts and rollbacks: Managing controlled updates to application deployments without downtime.
- Configuration and secret management: Storing and injecting sensitive configuration data without baking it into container images.
Crucially, Kubernetes clusters can span public cloud providers, private data centres, and hybrid combinations of both. This makes it a natural fit for organisations operating in a hybrid cloud model — which, as of the early 2020s, represents the dominant enterprise cloud strategy.
The Container Orchestration Wars Are Over
In the mid-2010s, multiple competing orchestration platforms vied for dominance: Docker Swarm, Apache Mesos, and Kubernetes were all serious contenders. By the late 2010s, the industry had converged decisively on Kubernetes. The CNCF KubeCon + CloudNativeCon conference grew from a small gathering to one of the largest open-source events in the world, and the ecosystem of certified Kubernetes distributions and tooling expanded rapidly.
The practical consequence for engineering teams is straightforward: choosing Kubernetes is no longer a differentiating architectural decision. It is the baseline. The decisions that matter now are how you manage, secure, and extend it.
What Kubernetes Is Not
This is where many organisations run into trouble. Kubernetes is an orchestration engine, not a complete production platform. A production-ready container environment requires a great deal more:
- Container registry: Storing, versioning, and scanning container images.
- Networking: A Container Network Interface (CNI) plugin (e.g., Calico, Cilium, Flannel) to handle pod networking and network policy enforcement.
- Storage: Persistent volume provisioning and a storage class strategy for stateful workloads.
- Observability: Metrics collection (e.g., Prometheus), log aggregation (e.g., Fluentd, Loki), distributed tracing (e.g., Jaeger, OpenTelemetry), and alerting.
- Ingress: An ingress controller (e.g., NGINX, Traefik, HAProxy) and, increasingly, a service mesh (e.g., Istio, Linkerd) for east-west traffic management.
- Security: Role-Based Access Control (RBAC), Pod Security Standards or Admission Controllers, image scanning, secrets management (e.g., HashiCorp Vault), and network policies.
- CI/CD integration: Pipelines that build, test, and deliver changes into the cluster reliably.
Each of these components must be selected, configured, integrated, tested, and maintained. When a problem occurs at any layer, upstream Kubernetes — as a community open-source project — does not provide formalised enterprise support. Your team, or your chosen distribution vendor, owns that responsibility.
The “Vanilla Kubernetes” Problem
There is a widely repeated phrase in the Kubernetes community: there is no such thing as vanilla Kubernetes. It captures a real operational hazard. Organisations that start with a minimal Kubernetes install and incrementally bolt on components often find themselves maintaining what amounts to a bespoke platform — assembled from open-source projects at different lifecycle stages, with complex interdependencies and no single support owner.
Scaling such a platform to run mission-critical workloads requires sustained investment in platform engineering skills that are currently in high demand and short supply. The operational overhead — version upgrades, compatibility testing, security patching across the stack — compounds as the platform grows.
This is the primary argument for adopting a curated Kubernetes distribution (such as Red Hat OpenShift, Rancher, VMware Tanzu, or a managed cloud service like EKS, GKE, or AKS) rather than assembling a stack from scratch. The trade-off is reduced flexibility in exchange for a tested, supported, integrated platform.
When to Consider Moving to Kubernetes
Kubernetes adds real value when one or more of the following conditions are true:
- You operate multiple services that need coordinated deployment and scaling.
- Your teams are spending significant time on manual deployment and environment management tasks.
- You need to run workloads portably across on-premises and cloud environments.
- Your application architecture is moving toward microservices and you need robust service discovery and traffic management.
- You require high availability and automated failure recovery for production workloads.
- Your release cadence demands frequent, low-risk deployments.
Kubernetes is a poor fit for small teams running a handful of long-lived monolithic applications with infrequent deployments. The operational overhead is unlikely to be justified.
How the Ecosystem Is Reducing Complexity
The Kubernetes ecosystem has matured considerably in its tooling for developer experience. Several categories of capability now exist to reduce the expertise required to work productively on Kubernetes:
- Service meshes (e.g., Istio, Linkerd) abstract away mTLS, observability, and traffic control at the platform level, removing the need for application-level implementation.
- Serverless frameworks on Kubernetes (e.g., Knative) allow teams to deploy event-driven workloads without managing pod lifecycle directly.
- Operators extend the Kubernetes API to manage complex stateful applications — databases, message brokers, monitoring stacks — using the same declarative model as native Kubernetes resources.
- Cloud-native CI/CD tools (e.g., Tekton, Argo CD, Flux) bring GitOps and pipeline orchestration natively into the Kubernetes control plane.
- Developer platforms built on Kubernetes (e.g., Backstage, Crossplane) give application teams self-service access to infrastructure without exposing raw Kubernetes complexity.
Enterprise Adoption in Practice
Two case studies from the original source illustrate the operational gains achievable with a well-implemented Kubernetes platform:
Deutsche Bank: From 6–9 Months to 2–3 Weeks
Deutsche Bank built an internal platform-as-a-service called Fabric — a containerised, microservices-based development platform powered by open-source tooling. The platform standardised and streamlined developer access to compute resources across the organisation. The reported outcome was a reduction in time-to-production for new applications from 6–9 months to 2–3 weeks.
Cathay Pacific: 200 Deployments Per Day
Cathay Pacific adopted an enterprise-grade Kubernetes platform in an open hybrid-cloud environment. Beyond the scalability and portability gains, the airline reported a dramatic improvement in deployment frequency — from approximately one deployment per week to 200 per day — along with increased collaboration between engineering teams and the ability to move applications across environments without rewriting them.
These outcomes are consistent with the broader DevOps research body (e.g., the DORA State of DevOps reports), which consistently finds that high-performing organisations deploy more frequently and recover from failures faster than low performers.
Open Platforms vs. Proprietary Lock-In
As organisations build out their hybrid Kubernetes environments, a critical architectural decision is the degree of openness they require. Proprietary managed Kubernetes services from cloud providers offer convenience but can create dependency on provider-specific APIs, tooling, and pricing models. Open distributions and standards-compliant platforms offer greater portability but require more internal expertise to operate.
Emerging technologies like Quarkus (a Kubernetes-native Java framework optimised for low memory footprint and fast startup) and the Operator pattern are expanding what’s possible on open Kubernetes platforms. Teams planning a multi-cloud or hybrid strategy should evaluate toolchain choices against their portability requirements before committing to provider-specific abstractions.
Key Takeaways for Engineering Teams
- Kubernetes has won the orchestration market. The decision is no longer whether to use it but how to operate it responsibly.
- A raw Kubernetes install is not a production platform. Budget for the full stack: networking, storage, observability, security, and CI/CD.
- The “vanilla Kubernetes” trap is real. Assess early whether your team has the capacity to own a self-assembled stack, or whether a curated distribution makes more sense.
- Developer experience matters. The organisations extracting the most value from Kubernetes are those that abstract its complexity away from application developers through internal platforms and self-service tooling.
- Security is not a bolt-on. Plan security across every layer of the stack — image scanning, RBAC, network policy, secrets management, and runtime controls — before workloads go to production.
- Hybrid portability is valuable but has a cost. Design for it deliberately, and validate that your toolchain supports it before assuming it.
For teams at the beginning of their Kubernetes journey, the most important question is not technical — it is organisational. What do you want your engineers to focus on? If the answer is building and shipping software that serves customers, then the investment in a solid, managed Kubernetes platform is justified. If the answer is maintaining platform infrastructure, building your own stack from scratch might be the right choice. Most organisations will find the former more strategically valuable.