This article is based on analysis originally published on Computer Weekly, authored by practitioners at NearForm. The views represent practitioner perspectives on Kubernetes trends as of mid-2020.
Kubernetes Is Evolving — and the Changes Are Fundamental
Kubernetes has become the de facto standard for container orchestration, but the platform is far from finished. Several converging trends — serverless compute, tightening security requirements, compliance automation, and ecosystem maturity — are reshaping how enterprises think about and operate Kubernetes in production. Understanding where the platform is headed helps engineering and DevOps teams make better architectural decisions today.
Kubernetes Is Moving Toward Serverless
One of the most significant near-term shifts in Kubernetes is the move toward serverless compute. The traditional Kubernetes deployment model requires operators to pre-specify node types, instance sizes, and cluster capacity. That model is changing.
AWS Fargate — the serverless compute engine that underpins both Amazon ECS and Amazon EKS — is an early indicator of where things are headed. With Fargate, teams no longer need to manage the underlying EC2 instances; compute resources are provisioned automatically based on pod specifications. The broader trajectory points toward Kubernetes clusters that negotiate resources dynamically, allocating and releasing infrastructure as workloads demand it, without requiring upfront capacity planning.
This matters operationally. The next logical step beyond on-demand compute is smarter load balancing — where Kubernetes manages workload distribution across hardware that developers never directly interact with. The outcome is a genuine abstraction of infrastructure: developers trigger an application, the orchestration layer handles the rest. The operational efficiency and developer-experience benefits of serverless are amplified when the underlying orchestrator is Kubernetes, because Kubernetes already handles scheduling, health checks, and rolling updates.
Security in Kubernetes Must Evolve
Security is one of the most actively debated topics in the Kubernetes community — and for good reason. Many enterprises adopting Kubernetes come from an on-premises background where network perimeters, hardened VM images, and traditional access controls formed the security foundation. Those controls do not map cleanly to the container model.
This creates a real tension. Teams accustomed to on-prem security practices often attempt to replicate them in Kubernetes environments — sometimes unsuccessfully, sometimes in ways that create a false sense of protection. The cloud-native model demands a different approach: immutable infrastructure, image scanning, pod security policies, RBAC, network policies, and secrets management all play roles that traditional perimeter controls once filled.
A practical gap exists in many organisations: security engineers who understand compliance and risk do not always understand Kubernetes internals, while Kubernetes engineers do not always have deep security expertise. The result can be ad-hoc, internally designed security practices that do not align with established cloud-native standards — what practitioners sometimes call “security shamanism.”
Concrete examples of where this breaks down include:
- No enforced policy on which base images or runtime versions (e.g., a specific JDK version) are permitted in containers.
- No systematic vulnerability scanning of container images in CI/CD pipelines.
- Unclear organisational tolerance thresholds for vulnerability severity (e.g., CVE scoring).
- Overly permissive RBAC configurations that grant cluster-admin rights too broadly.
The cloud-native and on-premises security mindsets need to converge around shared standards — verified base images, agreed scanning policies, and security controls embedded in the delivery pipeline rather than bolted on at the end.
Compliance as Code: Shifting Left in Regulated Industries
For organisations in regulated industries — finance, healthcare, government — Kubernetes adoption creates a specific challenge: their internal governance processes were not designed for continuous delivery. A Change Advisory Board (CAB) that meets weekly or bi-weekly to review and approve deployments is fundamentally incompatible with the release cadence that Kubernetes and CI/CD pipelines enable.
The aspiration is “Compliance as Code” — an automated change advisory process where compliance checks, security validations, and audit evidence are generated continuously as part of the software delivery pipeline, rather than performed manually as a gate before release. This concept is also described as “shifting security left”: catching compliance and security issues during development rather than in a last-minute pre-release review.
The benefits are significant:
- Reduced release risk: Issues are caught and resolved continuously, not discovered two days before go-live.
- Faster delivery: Automated evidence collection removes manual bottlenecks from the compliance process.
- Better audit trails: Code-driven compliance generates reproducible, version-controlled records.
The harder challenge is organisational. Enterprises with deeply embedded governance processes are often reluctant to change them — not because the processes are effective, but because they are familiar. This is a classic example of Conway’s Law in action: IT systems (and the processes that govern them) tend to mirror the communication structures of the organisations that build them. Digitising existing paper-based processes — rather than reimagining them — is a pattern repeated across industries, from banking UI design to CAB workflows.
Outside specialists with experience guiding regulated enterprises through this transition can be valuable precisely because they are not bound by existing organisational assumptions.
Kubernetes and Digital Transformation Reinforce Each Other
Kubernetes adoption and digital transformation programs are most effective when they happen together. A digital transformation initiative provides the organisational impetus and budget to standardise delivery pipelines. Standardised delivery pipelines, in turn, make Kubernetes adoption more consistent and governed across teams.
The risk is treating Kubernetes as a purely technical project without addressing the processes around it. A cluster that deploys at high velocity is only valuable if the organisation’s testing, security, and compliance processes can keep pace. Teams that skip this alignment often end up with Kubernetes clusters that are technically capable but constrained by the same slow, manual processes that slowed them down before.
An analogy worth holding onto: no one would accept a commercial aircraft that skips airworthiness certification because the manufacturer has its own internal quality process. Software — especially software running at the scale and speed that Kubernetes enables — deserves the same rigour. “Best practices” should be defined by the broader engineering community, not just by what happens to work in one company’s environment.
The Kubernetes Ecosystem Needs Standardisation
The Kubernetes ecosystem has grown rapidly, and with that growth has come significant duplication. Across networking, storage, observability, secrets management, service mesh, and ingress control, there are often multiple projects solving the same problem in slightly different ways. For enterprise teams evaluating options, this creates real overhead: how do you choose between competing tools without a reliable, community-endorsed evaluation framework?
Today, selection often comes down to community popularity, vendor backing, or the preferences of individual engineers — none of which are reliable proxies for production suitability. The result can be technology choices that create long-term maintenance burdens or that are poorly aligned with enterprise security and compliance requirements.
What the Kubernetes ecosystem would benefit from is something analogous to what emerged in the Java world: a recognised quality tier for open source components. The Apache Software Foundation and projects like the Spring Framework earned their reputations through sustained quality, governance, and community trust. Kubernetes components that meet defined standards of functionality, security, and maintainability could similarly benefit from a formal evaluation and endorsement process — a signal to enterprise adopters that a given component is production-ready.
The CNCF (Cloud Native Computing Foundation) landscape and graduation process already move in this direction, distinguishing between Sandbox, Incubating, and Graduated projects. Wider enterprise awareness of these signals, and continued rigour in the graduation criteria, would help close the gap.
Key Takeaways for DevOps and Platform Engineering Teams
- Plan for serverless Kubernetes now: Evaluate whether managed node groups or Fargate-style serverless compute fits your workload patterns. The abstraction will deepen over time.
- Invest in cloud-native security skills: Security engineers and platform engineers need shared understanding of Kubernetes-specific controls — RBAC, network policies, image scanning, and pod security standards.
- Start shifting compliance left: Integrate security scanning, policy checks, and compliance validation into your CI/CD pipelines rather than relying on pre-release manual gates.
- Pair technology adoption with process change: Kubernetes delivers its full value only when deployment, testing, and governance processes are adapted to match its capabilities.
- Use CNCF project maturity as a selection signal: When evaluating ecosystem components, the CNCF graduation status is a useful — if imperfect — indicator of community confidence and project health.
Kubernetes is a powerful tool, but tools alone do not drive transformation. The organisations that get the most from Kubernetes will be those that treat it as an opportunity to improve their processes, not just their infrastructure.