PlanetScaleDB for Kubernetes: Managed Databases Inside Your Own Cluster

PlanetScale announced the beta release of PlanetScaleDB for Kubernetes, a solution that lets organizations host their databases inside their own network perimeter while still benefiting from a fully managed, SaaS-like operational experience. Deployment is handled through the PlanetScale control plane and a Kubernetes operator, aiming to reduce the operational burden of backups, high availability, and software upgrades to just a few clicks.

PlanetScaleDB for Kubernetes is a MySQL-compatible database-as-a-service designed for teams running distributed, containerized workloads on Kubernetes—whether on-premises or in a public cloud.

Built on Vitess: A Battle-Tested CNCF Project

The underlying engine for PlanetScaleDB is Vitess, a top-level Cloud Native Computing Foundation (CNCF) open source project. Vitess was originally developed at YouTube to handle massive MySQL sharding at scale and has since been adopted by companies including GitHub, HubSpot, Slack, and Square to serve millions of queries per second.

By building on Vitess, PlanetScaleDB inherits horizontal sharding, connection pooling, and topology management capabilities that are difficult to implement with standard MySQL deployments. Organizations that need MySQL compatibility but require Kubernetes-native scalability are the primary target audience.

Why Bring the Database Into the Kubernetes Cluster?

As Kubernetes adoption has accelerated, a common architectural tension has emerged: application workloads run inside a Kubernetes cluster while the database lives outside it, often in a managed cloud service or a separate VM-based environment. This separation introduces network latency, complicates security policy enforcement, and creates operational silos between application and data teams.

PlanetScaleDB for Kubernetes addresses this by co-locating the database with the application workloads inside the same cluster. According to PlanetScale, running the database adjacent to microservices can reduce query latency by up to 20 milliseconds—though this figure will vary significantly depending on existing network topology and workload characteristics.

Key Features

• Efficiency: Co-locating databases and applications in the same Kubernetes cluster eliminates the need for complex cross-network infrastructure.
• Performance: Reduced network hops between microservices and the database layer lower query latency.
• Reliability: PlanetScaleDB manages software upgrades, hardware failure recovery, and network partition handling without requiring application downtime.
• Security: Because data remains within the customer’s own network perimeter, it is easier to enforce internal security policies and compliance requirements.
• Ease of Operations: The PlanetScale control plane and Kubernetes operator handle day-two operations—backups, scaling, and failover—as a managed service.
• MySQL Compatibility: Applications that already use MySQL drivers and tooling can connect without changes to the application layer.

How the Operator Model Works

PlanetScaleDB for Kubernetes uses the Kubernetes Operator pattern: a custom controller watches for PlanetScaleDB custom resources and reconciles the actual cluster state to match the desired state declared in those resources. This means database provisioning, scaling, and lifecycle management are expressed as Kubernetes manifests and handled natively by the Kubernetes API server, rather than through a separate out-of-band management tool.

The PlanetScale control plane provides a management UI and API layer on top of the operator, delivering the simplified “few clicks” provisioning experience the company describes for teams that do not want to write raw Kubernetes manifests.

Target Use Cases

• Regulated industries where data residency and network perimeter requirements prevent use of external managed database services.
• Hybrid cloud environments where workloads span on-premises Kubernetes clusters and public cloud infrastructure.
• High-throughput transactional workloads that need horizontal sharding beyond what a single MySQL instance can provide.
• Teams migrating from VM-based MySQL to a Kubernetes-native stack without rewriting application database logic.

Availability

At the time of this announcement (June 2020), PlanetScaleDB for Kubernetes was in beta. For current availability, pricing, and documentation, visit planetscale.com directly, as the product has continued to evolve since this announcement.

PlanetScale can also be followed on Twitter at @planetscaledata.

VMware Moves to Strengthen Kubernetes Security with Octarine Acquisition

VMware announced its intention to acquire Octarine, an early-stage Kubernetes security startup, for an undisclosed sum. The deal signals VMware’s continued push to build out a comprehensive, cloud-native security portfolio — one that builds on its $2.1 billion acquisition of endpoint security firm Carbon Black roughly seven months prior.

What Octarine Brings to the Table

Octarine developed a security platform specifically designed for Kubernetes-based applications. The platform is aimed at simplifying DevSecOps workflows and improving security posture across the full application lifecycle — from development through runtime. This covers a gap that traditional endpoint and network security tools have historically struggled to address in containerized environments.

Patrick Morley, General Manager and Senior Vice President at VMware’s Security Business Unit, framed the acquisition in terms of workload protection:

“Protecting workloads is critical to the security of applications and data inside every organisation. Building Octarine’s innovation into the VMware security portfolio will present a major opportunity for our team to further simplify and improve security for our customers.”

Patrick Morley, SVP, VMware Security Business Unit

Integration Plans: Carbon Black Cloud and VMware Tanzu

VMware outlined two primary integration paths for Octarine’s technology:

• VMware Carbon Black Cloud: Octarine’s container and Kubernetes security capabilities will be embedded directly into the Carbon Black Cloud platform, extending its workload protection reach into cloud-native environments.
• VMware Tanzu: Deep hooks and integrations with the Tanzu platform will allow Kubernetes security to be enforced natively within VMware’s container management and application modernization ecosystem.

Together, these integrations are positioned to advance what VMware calls its intrinsic security strategy — the goal of protecting any application, running on any cloud, on any device — without requiring bolt-on security tools.

Context: VMware’s Broader Security Ambitions

VMware’s acquisition of Carbon Black in late 2019 marked its entry into the enterprise security market as a primary vendor, not merely an infrastructure provider. The Octarine acquisition extends that commitment specifically into the Kubernetes and container security space — an area of growing importance as enterprises accelerate cloud-native adoption.

Kubernetes environments introduce unique security challenges: dynamic workloads, ephemeral containers, complex network policies, and a large, often misconfigured attack surface. Purpose-built tools like Octarine’s platform address concerns such as runtime threat detection, network policy enforcement, and vulnerability management within Kubernetes clusters.

Next-Gen SOC Alliance Also Announced

Alongside the Octarine acquisition news, VMware launched a Next-Gen SOC Alliance designed to equip modern Security Operations Center (SOC) teams with improved context and efficiency through Extended Detection and Response (XDR) capabilities.

The alliance integrates the VMware Carbon Black Cloud with the following platforms:

• Splunk
• IBM Security
• Google Cloud’s Chronicle
• Exabeam
• Sumo Logic

Tom Barsi, Vice President of Alliances for VMware Carbon Black, described the initiative:

“The Next-Gen SOC Alliance brings a critical mass of XDR context and capabilities to SOCs in a fully intrinsic way – one that can uniquely leverage the VMware fabric.”

Tom Barsi, VP of Alliances, VMware Carbon Black

Why This Matters for DevSecOps Teams

For DevOps and platform engineering teams running workloads on Kubernetes, this acquisition reflects a broader industry trend: security tooling is moving closer to the platform layer. Rather than requiring separate security products, vendors like VMware are working to embed security controls directly into the infrastructure and orchestration layer. If executed well, this reduces friction for development teams while giving security teams broader visibility and control over containerized workloads at runtime.

The acquisition terms were not disclosed. Integration timelines into Carbon Black Cloud and Tanzu were not announced at the time of the original report.

Overview

Microsoft and Redis Labs announced a formal partnership in May 2020 to expand the capabilities of Azure Cache for Redis by integrating Redis Labs’ Redis Enterprise technology directly into the Azure platform. The collaboration was described as the first native integration between Redis Labs technology and a major cloud platform.

The partnership was driven by growing enterprise demand for sub-millisecond response times, seamless horizontal scaling, and cloud-native architectural flexibility—requirements that the existing open-source Redis managed service addressed only partially.

What Changed: Two New Enterprise Tiers

The partnership produced two new Enterprise tiers for Azure Cache for Redis, managed natively within Azure. These tiers are powered by Redis Enterprise software licensed through Redis Labs and made available via the Azure Marketplace as an integral part of the provisioning process.

Customers purchasing these tiers get a unified experience: management through the Azure portal and CLI, Microsoft-handled first-line support, standard Azure security and compliance controls, and a single consolidated bill—rather than managing a separate Redis Labs contract alongside their Azure spend.

New Redis Modules Available

A key benefit of the Redis Enterprise integration is access to Redis Labs-developed modules that extend Redis beyond its core data structures. The modules announced as part of this partnership include:

• RediSearch – A full-text search and secondary indexing engine built on top of Redis, enabling rich query capabilities without exporting data to a separate search service.
• RedisBloom – Provides probabilistic data structures such as Bloom filters, Cuckoo filters, Count-Min Sketch, and Top-K, useful for approximate membership queries and frequency estimation at scale.
• RedisTimeSeries – A time-series data structure module with built-in downsampling and aggregation, suited for IoT telemetry, monitoring pipelines, and financial tick data.

These modules open Redis to additional use cases such as real-time analytics, machine learning feature stores, and time-series ingestion pipelines that previously required separate, purpose-built databases.

Enhanced Operational Features

Beyond new modules, the Enterprise tiers layer additional operational capabilities on top of existing Azure Cache for Redis features such as data persistence, clustering, geo-replication, and VNet-based network isolation. The key additions include:

• SSD flash storage option – Enables cache sizes reported to be up to ten times larger than DRAM-only deployments at a lower cost per GB, while targeting comparable performance levels for workloads that tolerate slightly higher latency on cold data.
• Enhanced SLA – The Enterprise tiers carry a stronger availability commitment than the standard open-source Redis tiers.
• Active geo-replication – Allows a globally distributed, active-active cache configuration across Azure regions with no data loss on failover. The announcement also noted a future roadmap item to extend this to hybrid scenarios connecting on-premises caches with Azure-hosted caches.

Developer Experience and Support

From a developer workflow perspective, the Enterprise tiers are designed to require no application-level changes at onboarding. Teams already using Azure Cache for Redis can adopt the new tiers without downtime or changes to their billing management processes.

Microsoft handles first-line support for the integrated offering and works with Redis Labs on escalations that require deep Redis Enterprise expertise. This model means development teams interact with a single vendor for support rather than coordinating between Microsoft and Redis Labs independently.

Why This Partnership Matters for DevOps Teams

For DevOps engineers running workloads on Azure, the practical implications of this partnership are:

• Reduced operational complexity – Redis Enterprise capabilities are provisioned and monitored through the same Azure tooling (portal, ARM templates, Terraform Azure provider, Azure Monitor) used for the rest of the stack.
• Expanded use cases without additional infrastructure – Search, time-series, and probabilistic data structures are available inside the cache layer, potentially eliminating the need for dedicated Elasticsearch or InfluxDB deployments for certain workloads.
• Stronger HA guarantees – Active geo-replication with zero data loss failover is a meaningful upgrade for globally distributed applications with strict RPO requirements.
• Cost flexibility – The flash storage tier offers a different cost-performance trade-off for datasets larger than what DRAM alone would make economically practical.

Background: Azure Cache for Redis

Azure Cache for Redis is Microsoft’s fully managed Redis service, built on open-source Redis. Before this partnership, it covered the primary Redis use cases—distributed caching, session management, pub/sub messaging, and leaderboard data structures—with tiers ranging from Basic (single node) to Premium (clustered, persistent, VNet-isolated). The Enterprise tiers introduced through the Redis Labs partnership sit above the existing Premium tier in capability and are targeted at workloads with stricter performance, resiliency, or feature requirements.

Summary

The Microsoft–Redis Labs partnership represents a meaningful expansion of the Azure Cache for Redis feature set. By bringing Redis Enterprise modules, flash storage, active geo-replication, and enhanced SLAs into a natively managed Azure service, the collaboration lowers the barrier to adopting advanced Redis capabilities in production. Teams already invested in the Azure ecosystem gain access to Redis Labs technology without taking on a separate vendor relationship or operational surface area.

Why Kubernetes Storage Matters for Remote Work

The rapid shift to remote work accelerated reliance on cloud-based applications—video conferencing, collaborative document editing, project management tools, and more. Most of these applications run in software containers hosted in large data centers. Kubernetes, the open-source container orchestration platform originally developed by Google and now stewarded by the Cloud Native Computing Foundation (CNCF), has become the de-facto standard for managing those containers at scale.

One persistent challenge with Kubernetes has been storage: containers are designed to be ephemeral, meaning they can spin up and shut down at any time. That works well for stateless workloads, but many real-world applications—databases, file services, analytics platforms—are stateful: they need to persist data across container restarts. Several vendors responded to this gap with notable announcements in early-to-mid 2020.

Background: Containers, Docker, and Kubernetes

A container is a lightweight, isolated execution environment that packages an application and its dependencies into a single unit. Unlike a virtual machine, a container shares the host operating system kernel, making it faster to start and more resource-efficient. Docker popularized the container format, and Kubernetes builds on top of it—and other container runtimes—to schedule, scale, and manage containers across clusters of machines.

• Containers provide isolation and portability across environments.
• Docker is a widely used container runtime and image format.
• Kubernetes orchestrates containers across multiple hosts, handling scheduling, health checks, scaling, and networking.
• Stateful applications require persistent storage so data survives container restarts or rescheduling.

Red Hat OpenShift: Unifying Virtual Machines, Containers, and Serverless

At its 2020 Red Hat Summit, IBM’s Red Hat announced several enhancements to OpenShift, its enterprise Kubernetes platform. Two announcements stood out for teams managing production Kubernetes infrastructure:

• OpenShift Virtualization: Allows organizations to deploy and manage virtual machines alongside containers and serverless workloads within a single platform. This is significant for enterprises that cannot immediately migrate all legacy applications to containers—they can run VMs and containers side by side under one management layer.
• Red Hat Advanced Cluster Management for Kubernetes: Provides a unified control plane for monitoring and deploying OpenShift clusters at scale across multiple environments, reducing operational complexity for teams managing distributed Kubernetes infrastructure.

Both features target a common enterprise pain point: hybrid environments where cloud-native workloads and traditional applications must coexist without requiring separate toolchains.

NetApp Project Astra: Enterprise Storage Services for Stateful Kubernetes Apps

NetApp introduced Project Astra as a software-defined storage and data services platform built specifically for Kubernetes, developed in collaboration with the Kubernetes community. Its stated goals include:

• Delivering enterprise-class data management (backup, recovery, snapshots) for Kubernetes-managed applications.
• Enabling application and data portability for stateful workloads—meaning applications and their data can be moved between clusters or cloud environments without data loss.
• Making it practical to run long-running, data-intensive workloads—such as databases—inside containers, which previously required complex workarounds to persist state reliably.

The core problem Project Astra addresses is that a standard Kubernetes pod, when deleted or rescheduled, loses any data written to its local filesystem. Persistent Volumes (PVs) and the Container Storage Interface (CSI) provide the framework; Project Astra aims to add higher-level data services on top of that framework.

Kioxia KumoScale: NVMe-oF Storage with Kubernetes CSI Support

Kioxia (formerly Toshiba Memory) enhanced its KumoScale storage software, which leverages NVMe over Fabrics (NVMe-oF) to deliver high-performance storage over a network. The relevant additions for Kubernetes operators include:

• CSI-compliant snapshots and clones: KumoScale now supports the Kubernetes Container Storage Interface standard for creating point-in-time snapshots and clones of volumes. This is important for backup workflows and for creating development or test copies of production data without disrupting running workloads.
• Reduced backup overhead: Kioxia states the snapshot and clone features reduce time pressure and storage consumption associated with backing up large stateful applications such as databases.
• Non-disruptive data cloning: Operators can clone production data for development, testing, or QA purposes without taking the production system offline.

NVMe-oF provides lower latency than traditional iSCSI or Fibre Channel storage networks, making it suitable for latency-sensitive stateful applications running in containers.

StorageOS v2.0: Software-Defined Persistent Storage for Kubernetes

UK-based startup StorageOS released StorageOS v2.0 into general availability as a cloud-native, software-defined persistent storage solution purpose-built for Kubernetes. Key features highlighted in the release include:

• Hyper-converged and multi-cluster support: Designed for organizations running Kubernetes across multiple clusters, whether on-premises, in the cloud, or in hybrid configurations.
• Encryption in transit: All traffic between storage nodes is encrypted and authenticated, addressing a security concern that becomes more pronounced when storage traffic crosses network boundaries in distributed environments.
• Cloud-native workflows: The storage layer is designed to integrate with standard Kubernetes primitives such as Persistent Volume Claims (PVCs) and the CSI, rather than requiring custom application changes.

Why These Developments Matter: Stateful Workloads at the Core of Remote Work Infrastructure

The applications that power remote work—file collaboration platforms, video services, databases backing SaaS tools—are overwhelmingly stateful. They write data that must persist and be recoverable. The Kubernetes ecosystem’s historical weakness in this area has been a barrier to running production-grade stateful applications in containers at scale.

The announcements from Red Hat, NetApp, Kioxia, and StorageOS represent a maturing of the Kubernetes storage ecosystem. Each addresses a different layer of the problem:

• Platform management (Red Hat Advanced Cluster Management) simplifies operating many Kubernetes clusters.
• Data services (NetApp Astra) provide backup, recovery, and portability for stateful applications.
• High-performance storage (Kioxia KumoScale + CSI) brings NVMe-oF speed to Kubernetes-native workflows.
• Software-defined persistence (StorageOS v2.0) delivers encrypted, portable storage for multi-cluster and hybrid environments.

Together, these developments lower the operational barriers to running complex, data-intensive applications in Kubernetes—supporting the cloud infrastructure that underpins modern distributed and remote workforces.

Key Concepts Reference

1. Hardening and Compliance

One of the first lessons any Kubernetes administrator learns is that the platform’s defaults are not designed with maximum security in mind—they are designed for accessibility and ease of getting started. Hardening Kubernetes means understanding what is and is not enabled by default, and deliberately configuring the platform to meet your organization’s security requirements.

Some important areas to address during hardening include:

• API server access: Ensure all communication to the API server is over HTTPS and not exposed unnecessarily to public networks.
• Authentication between components: Use X.509 certificates to authenticate inter-component communication within the cluster.
• etcd encryption: The etcd datastore holds the entire cluster state. Encrypt it at rest to protect sensitive configuration data and secrets.
• Pod Security: Pod-level security controls (historically Pod Security Policies, now replaced by Pod Security Admission in modern Kubernetes versions) are critical for multi-tenant clusters but require explicit configuration.

Organizations can use published security benchmarks to guide this process. The Center for Internet Security (CIS) provides detailed configuration guidelines for hardening Kubernetes clusters against common attack vectors. Following a step-by-step benchmark checklist is one of the most effective ways to ensure a systematic approach to hardening a platform as large and feature-rich as Kubernetes.

Keep in mind that hardening involves trade-offs. Certain security settings may affect performance or developer workflow, so each control should be evaluated in terms of risk versus operational impact. Organizations that lack the in-house expertise or bandwidth to perform this hardening work themselves may want to consider a commercially supported Kubernetes distribution that ships with hardening applied out of the box.

2. Managing Workload Configurations

Beyond securing the cluster itself, you must manage the security posture of every workload running on it. As the number of microservices and deployments grows, maintaining consistent, secure configurations across all workloads becomes a significant challenge.

Helm Charts are a widely used open-source tool for packaging, provisioning, and configuring Kubernetes applications. They work well for initial deployment (Day 1 operations), making it straightforward to deploy applications consistently. However, Helm on its own does not address ongoing operational management once an application is running.

This is where Kubernetes Operators become valuable. Operators encode human operational knowledge into software, allowing them to manage the full lifecycle of complex applications—including Day 2 operations such as upgrades, backups, failure recovery, and configuration drift remediation. From a security perspective, operators can detect when a deployed service’s configuration has drifted from its declared, approved state and automatically reset it. This is especially valuable in multi-team environments where configuration drift is a common source of vulnerabilities.

Helm Charts and Operators can also be used together: a Helm Chart can be wrapped inside an Operator, giving you the templating benefits of Helm combined with the lifecycle management intelligence of an Operator. Operators can even be used to manage Kubernetes cluster components themselves, enabling automated, secured cluster configuration management.

3. Securing Multi-Tenant Clusters

As Kubernetes deployments grow, many organizations consolidate workloads from multiple teams or applications onto shared clusters. Multi-tenancy is an effective strategy for resource utilization and operational efficiency, but it requires deliberate security controls to prevent workloads from interfering with or accessing each other inappropriately.

Kubernetes provides several built-in mechanisms to support secure multi-tenancy, though many of these are not active or fully enforced by default:

• Namespaces: Namespaces provide logical isolation between teams or projects within a shared cluster. They are the foundation of multi-tenancy in Kubernetes, but isolation is only meaningful when combined with RBAC and network policies.
• Role-Based Access Control (RBAC): RBAC controls what actions a user or service account is permitted to perform within a cluster or namespace. Kubernetes ships with a set of default roles that can be bound to users and groups, simplifying initial configuration while providing meaningful access control.
• Resource Quotas: By default, pods in a Kubernetes cluster can consume unbounded CPU and memory. Resource quotas enforce aggregate consumption limits per namespace, reducing the blast radius of resource-hungry or misbehaving workloads and providing a degree of protection against denial-of-service scenarios.
• Network Policies: Network policies define how pods communicate with each other and with external endpoints. Without network policies, all pods in a namespace can communicate freely with all other pods. Applying network policies enforces micro-segmentation, limiting lateral movement in the event of a compromise.

Implementing all four of these controls in combination is the recommended approach for any multi-tenant Kubernetes deployment. Treating any one of them as optional leaves meaningful security gaps.

4. Balancing Security and Development Agility

Perhaps the most persistent challenge in Kubernetes security—and in DevOps security generally—is cultural rather than technical. Pressure to ship fast creates incentives to defer security work, leaving it as an afterthought rather than an integral part of the development and deployment process.

The DevSecOps model addresses this by embedding security automation directly into CI/CD pipelines, rather than relying on manual security reviews at the end of the release cycle. Practical steps include:

• Integrating automated container image vulnerability scanners into the build pipeline so that insecure images are caught before deployment.
• Adding automated security gates alongside existing unit and functional tests.
• Using infrastructure-as-code and policy-as-code tools to enforce security standards at the cluster and workload configuration level.
• Providing development clusters with standardized monitoring, alerting, and logging capabilities so that developers can build observable services from the start.

A service mesh (such as Istio or Linkerd) can also significantly improve the security and observability of microservice-based applications. Capabilities like mutual TLS (mTLS) for service-to-service authentication, traffic encryption, and fine-grained traffic policy enforcement can be managed at the platform level rather than requiring developers to implement them in application code. The service mesh also gives the operations team visibility into east-west traffic within the cluster, which is typically invisible without it.

Crucially, none of this works without collaboration between development, operations, and security teams. DevSecOps is as much a cultural and organizational practice as it is a technical one. Security professionals need to work alongside developers and platform engineers, sharing knowledge and building shared responsibility for security outcomes. Given the well-documented shortage of security specialists in the industry, this kind of cross-functional collaboration is not just a best practice—it is a practical necessity.

Building Security In, Not Bolting It On

The Kubernetes ecosystem continues to invest in security across the full spectrum: hardening guidance, formal security audits, RBAC improvements, pod security controls, network policy support, service mesh integration, and Operators for lifecycle management. These are powerful tools, but they only deliver value when organizations take the time to understand, configure, and consistently apply them.

The organizations that get Kubernetes security right are those that treat it as an ongoing discipline—not a one-time configuration task. That means continuous assessment of cluster configurations, regular review of workload security posture, investment in pipeline automation, and a culture where security is everyone’s responsibility.

Start with the fundamentals: harden your cluster using a published benchmark, enforce RBAC and network policies, use Operators to prevent configuration drift, and integrate security scanning into your CI/CD pipeline. These steps alone will put your organization significantly ahead of the baseline.

Docker brought containers into the enterprise; static scanning makes sure they are secure when the images are created. Who watches them when they run?

Docker made it possible to have an exact copy of the core elements of the operating system and the application code in a single, manageable file. BusyBox, the simplest production-ready Docker image, is only 2.1MB. That is small enough to check into version control and small enough to copy around on the network. It’s small enough that every build can be security scanned.

That point-in-time scanning sounds impressive, but it isn’t enough.

SEE: Kubernetes security guide (free PDF) (TechRepublic)

Production containers are computers running in a network that is a cluster, likely Kubernetes. Once they are running, any administrator can secure shell to them and change the configuration or permissions. For that matter, Kubernetes lets every system talk to every other system by default. Auditors tend to care more about the security of the production systems, not some images in version control. That means hardening for HIPPA, PCI, SarBox, and other standards, along with producing the reports the auditors want to see.Rocking your stack
Instead of running a part of the build on a build server, StackRox is a cloud-native security product. It runs inside Kubernetes, with enough privileges to inspect each node in the cluster. It can inspect the nodes for compliance, but also how Kubernetes is configured. Once the policies are in place, an administrator shouldn’t be able to log into a container and change it. StackRox can actually monitor the interaction between containers, creating a YAML file with policy changes, to limit pod-to-pod communications to what they should be. As Michelle McLean, head of community for StackRox, puts it, “Pull rich context from Kubernetes, then push policies into Kubernetes.”

McLean sees this as a tool to bring Security into DevOps. She explains “We bridge security and DevOps. DevOps is trying to learn how to run and configure Kubernetes. Security understands compliance and auditing, but does not understand the infrastructure enough to get that information.” Beyond that, they don’t even speak the language to ask the questions.

SEE: What is Kubernetes? (free PDF) (TechRepublic)

With web and microservices exposed to the open internet, a cloud native, runtime auditor can tell if someone is running a port scan attack, by examining the running processes on the container. Likewise, the tool can tell what processes are running as root.

The product also has the dashboard and visualization tools you’d expect, but that doesn’t solve the audit problem—along with the ability to export reports in .csv format for compliance, by compliance standard.

Instead of forcing yet another dashboard, McLean wants to push data to where the consumers of the data live. For security, that might be splunk; for DevOps it might be PagerDuty or SumoLogic.

Where’s the data?

I also spoke with Jeff Morris, vice president of Product Marketing for Couchbase, about container security. Jeff pointed out that where the data is housed can simplify operations. For example, some cloud service providers, especially Software As a Service (SaaS), store your data on their servers. Morris gave Salesforce as an example, along with many database “as a service” providers. StackRox, like Couchbase, can run entirely in the customer’s virtual or private cloud. Instead of renting CPU hours, Couchbase charges a simple management fee and lets the customer find the most cost-effective storage, all the way down to bare metal.

There are certainly plenty of container security products; StackRox is one. Istio is an open-source project that comes to mind.

Istio’s overlap with Kubernetes security

Istio is another popular open-source program that runs in a Kubernetes cluster and allows users to configure security policies. Like StackRox, Istio can monitor traffic between pods, limit traffic to select interactions, and even create and require authentication policies. Since all the public Kubernetes clouds support it, what’s the use in a commercial tool?

McLean refers to the difference as apples to oranges. In terms of the OSI model, StackRox works at the “network layer,” or level three, monitoring traffic on the network. That is, what nodes are communicating with each other. Istio monitors on the application layer, level seven. It can be aware of security protocols, ports, and the different applications running within a node and how they should connect. It can also encrypt that communication and provide debugging information. According to McLean “Istio isn’t a security product; it is a service mesh configuration product.”

SEE: Kubernetes rollouts: 5 security best practices (TechRepublic)

In my personal experience, Istio can require a great deal of bandwidth, memory, and CPU. Like StackRox, it sits in the same cluster. However, it roughly doubles the amount of messages, as the Istio containers need to receive all of the messages, store them in a database, aggregate them, and display the results as a dashboard. McLean is careful to not overly critique the product, but agrees that it can easily be misconfigured to consume excess resources. It may be easier to let somebody else do it.

New Relic AI: AIOps Reaches General Availability

New Relic, a leading cloud-based observability company, announced the general availability of New Relic AI, its AIOps (Artificial Intelligence for IT Operations) platform. The product is positioned as a core pillar of the broader New Relic One observability platform, extending its capabilities beyond traditional Application Performance Monitoring (APM) and infrastructure monitoring into AI-driven incident intelligence.

Background: The SignifAI Acquisition

The foundation of New Relic AI traces back to February 2019, when New Relic acquired SignifAI, a Silicon Valley-based startup headquartered in Sunnyvale, California, with additional offices in Tel Aviv. SignifAI specialized in applying AI and machine learning to IT operations — precisely the capability New Relic needed to enter the AIOps space. The acquisition allowed New Relic to integrate intelligent, ML-powered operations directly into its observability stack.

What Is New Relic AI?

New Relic AI is described as an open incident correlation and intelligence solution that is source-agnostic and data-agnostic. It integrates deeply with the New Relic One platform and is designed to help IT and DevOps teams detect anomalies, correlate incidents, and reduce the volume of noisy alerts that routinely overwhelm operations teams.

Key capabilities include:

• Anomaly detection: Evaluates telemetry data from disparate sources to surface outliers in patterns before they become critical incidents.
• Incident correlation: Automatically groups related alerts and events to reduce duplicate notifications and alert fatigue.
• Multi-signal ingestion: Ingests and analyzes alerts, logs, metrics, and deployment events from multiple data types simultaneously.
• Contextual insights: Provides an intelligent summary of each incident alongside a live view of ingested data, enabling faster diagnosis and prioritization.
• User feedback tuning: Allows operators to tune correlation rules based on feedback, improving accuracy over time.

The Role of NRDB (New Relic Database)

New Relic AI is powered by NRDB (New Relic Database), a purpose-built, distributed time-series database designed to store telemetry data — metrics, events, logs, and traces — from a wide variety of sources in a uniform format. NRDB is engineered for high-performance querying, making it well-suited for the real-time analysis that AIOps requires. Machine learning algorithms run against data stored in NRDB to identify patterns, detect anomalies, and derive context-based insights.

Reducing Alert Fatigue: What New Relic Claims

Alert fatigue is a well-documented problem in DevOps and IT operations: too many alerts, too many false positives, and too little context lead to slower incident response and missed issues. New Relic AI addresses this by correlating alerts across data sources to filter signal from noise automatically.

According to New Relic, early access customers reported seeing automatic reductions in alert noise of up to 50 percent through incident correlation. This figure is a vendor-reported claim from early access users and has not been independently verified.

Integrations: Works With Your Existing Stack

A notable differentiator for New Relic AI is its broad integration ecosystem. Rather than requiring teams to rip and replace existing tooling, the platform is designed to augment and connect with commonly used monitoring, alerting, and collaboration tools. Supported integrations at launch included:

• Monitoring & observability: Splunk, Prometheus, Grafana, Amazon CloudWatch, Google Cloud’s Stackdriver (now Google Cloud Operations Suite)
• Incident management & on-call: PagerDuty, OpsGenie, VictorOps
• IT service management: ServiceNow
• Collaboration: Slack

By integrating with both public cloud monitoring platforms and third-party tooling, New Relic AI positions itself as a correlating intelligence layer that sits above existing data sources rather than replacing them.

New Relic’s Broader Strategic Shift

New Relic began as an Application Performance Monitoring (APM) company but has progressively expanded its scope. The consolidation of APM and infrastructure monitoring into the unified New Relic One platform was a pivotal step, and New Relic AI represents the next layer — bringing machine learning and AI-driven intelligence to the data already flowing through that platform.

The company’s stated goal is to move beyond reactive monitoring toward proactive, AI-assisted operations — a requirement increasingly driven by the complexity of cloud-native, hybrid, and multi-cloud environments.

The AIOps Market Consolidation

New Relic’s move into AIOps mirrors a broader consolidation trend across the industry. Around the same period, several notable acquisitions reshaped the AIOps and observability landscape:

• Splunk acquired SignalFx
• LogicMonitor acquired Unomaly
• ServiceNow acquired Loom Systems
• VMware acquired Voyance
• New Relic acquired SignifAI

This pattern reflects an industry-wide recognition that observability data alone is not enough — operations teams need intelligent correlation and context to act quickly at scale. AIOps has emerged as the discipline that bridges raw telemetry with actionable incident intelligence.

Summary

New Relic AI’s general availability marks a significant step in New Relic’s evolution from an APM vendor to a full-stack observability and AIOps provider. For DevOps and IT operations teams managing complex, distributed systems, the platform offers a way to centralize alert correlation, reduce noise, and surface actionable insights faster — without abandoning existing monitoring tooling. As multi-cloud and cloud-native architectures continue to grow in complexity, AI-assisted operations platforms like New Relic AI are likely to become a standard part of the enterprise DevOps toolkit.

What Is Appvia Kore?

Appvia, a UK-based cloud-native software company, launched Appvia Kore as an open-source Kubernetes distribution designed to make cluster provisioning and day-to-day lifecycle management significantly more accessible for developer teams. The platform emerged from direct operational experience gained by the company’s founders while deploying and managing Kubernetes clusters on behalf of the British Home Office.

According to Appvia CEO Jonathan Shanks, that real-world experience exposed a recurring problem: standing up a production-ready Kubernetes cluster manually is error-prone, time-consuming, and demands a level of expertise that most developer teams simply do not have in-house. Kore was built to address this gap systematically.

Core Capabilities

Appvia Kore provides a curated set of lifecycle management tools and opinionated templates that automate the provisioning pipeline end-to-end. Key areas the platform targets include:

• Automated CI pipeline setup: Kore pre-configures the continuous integration (CI) pipelines a team needs before they can start building applications on a cluster, removing manual bootstrapping steps.
• Secure cluster provisioning: Security controls are baked into the provisioning process rather than applied as an afterthought, reducing the risk of misconfiguration on a complex platform.
• Repeatable, prescriptive workflows: Teams can spin up new clusters in a highly repeatable fashion, making it practical to scale Kubernetes adoption across many teams within a single organisation.
• Reduced expertise barrier: By encoding best practices into templates, Kore lowers the Kubernetes expertise threshold required to get a cluster into a production-ready state.

The Operationalisation Problem Kore Solves

Interest in Kubernetes has remained consistently high, but many organisations struggle to move beyond experimentation into reliable, large-scale operations. The core tension is straightforward: Kubernetes is one of the most operationally complex platforms in modern infrastructure, yet the expectation is increasingly that development teams — not dedicated platform engineering squads — will provision and manage their own clusters.

Without tooling like Kore, each new cluster becomes a bespoke, manual effort. Configuration drift, security gaps, and inconsistent CI setups accumulate over time, creating operational debt that slows delivery and increases incident risk. Shanks’s argument is that a prescriptive, automated approach is not merely convenient — it is a prerequisite for running Kubernetes at enterprise scale without a large, specialist platform team.

Kubernetes Adoption in a Constrained Budget Environment

At the time of Kore’s launch in April 2020, organisations were reassessing technology spending amid broader economic uncertainty. The pattern Appvia observed mirrored a common split in the market:

• Accelerating sectors — entertainment, education, and digital-first services — were actively scaling application infrastructure to meet surging demand.
• Contracting sectors — retail, hospitality, and travel — faced pressure to cut costs, sometimes pivoting existing digital initiatives into business continuity strategies rather than new feature development.

In both scenarios, containers played a role. Organisations looking to cut costs often turned to containerisation to lift and shift legacy workloads to cloud environments, improving resource utilisation and reducing on-premises infrastructure spend. Once applications moved to the cloud, further modernisation toward microservices architectures — and therefore Kubernetes — became a natural next step.

The economic pressure also reinforced the case for tools like Kore: if Kubernetes clusters must be managed with a smaller team and tighter budgets, operational automation is not optional.

CNCF Alignment and Open Source Strategy

Shanks indicated that Appvia’s longer-term ambition is for Kore to be accepted as a project under the Cloud Native Computing Foundation (CNCF). CNCF project status would give Kore broader community visibility, structured governance, and the kind of ecosystem credibility that accelerates enterprise adoption — particularly in organisations with policies favouring CNCF-endorsed tooling.

As an open-source platform, Kore invites community contribution, which also helps Appvia build momentum without requiring every prospective user to commit to a commercial relationship upfront.

Why This Matters for Platform Engineering Teams

The Appvia Kore launch reflects a broader industry shift: the recognition that Kubernetes itself is not a finished product for most organisations — it is a foundation on top of which significant engineering work must be done before developer teams can be productive. Platforms that encode this work into reusable, automated workflows represent a meaningful step toward making Kubernetes a commodity infrastructure layer rather than a specialist discipline.

For DevOps and platform engineering teams evaluating their internal developer platform (IDP) strategy, tools like Appvia Kore sit in the same problem space as projects such as Backstage, Crossplane, and Cluster API — all of which aim to make self-service Kubernetes provisioning tractable at scale.

Source: Container Journal

Technology Is the Easy Part

Container technology has a clear value proposition: faster software delivery, better resource utilization, and improved application portability. Kubernetes, the open-source container-orchestration platform originally developed at Google and now maintained by the Cloud Native Computing Foundation (CNCF), has become the de facto standard for managing containerized workloads at scale. Enterprise adoption is growing steadily.

But technology adoption is rarely a purely technical challenge. According to the VMware survey, organizational culture and internal misalignment are proving to be more formidable obstacles than any technical limitation. As the DevOps community has long observed: containers won’t fix your broken culture.

Where Enterprises Stand on Kubernetes Adoption

The survey findings paint a picture of adoption that is broad but still relatively shallow in many organizations:

• 57% of respondents are running fewer than 10 Kubernetes clusters.
• 60% are running less than half of their containerized workloads on Kubernetes.
• Despite this, the majority of enterprises report that they are now using Kubernetes to manage and align container environments.

This suggests that most enterprises are past the proof-of-concept stage but have not yet achieved full-scale production rollouts. Kubernetes is present, but it has not yet become the universal runtime for containerized applications within most of these organizations.

On-Premises Deployments Lead, Defying Expectations

One of the more surprising findings from the survey concerns where Kubernetes is actually being deployed. Despite its strong association with cloud-native architecture, most enterprise Kubernetes deployments are not in the public cloud:

• 64% of respondents have deployed Kubernetes on-premises.
• 42% run Kubernetes within a single public cloud environment.

The survey authors acknowledge this outcome was unexpected. Their interpretation: enterprises most often begin their Kubernetes journey on existing infrastructure, taking advantage of already-established virtualized environments rather than migrating to public cloud first. This is consistent with the broader pattern of incremental infrastructure modernization seen across many large organizations.

Importantly, Kubernetes’ hybrid capabilities make this a practical path. Because Kubernetes can run clusters both on-premises and in the cloud, organizations can containerize workloads on existing infrastructure and move them to the cloud progressively, rather than committing to a full cloud migration upfront.

Reported Benefits of Kubernetes in Production

Among respondents already running Kubernetes, the reported business and operational benefits are significant:

• 56% cite improved resource utilization.
• 53% report shortened software development cycles.
• 50% are using Kubernetes to containerize legacy monolithic applications.
• 42% say it makes cloud migrations easier.
• 33% report reduced public cloud costs.

The cost-reduction finding is notable. Running Kubernetes on public cloud infrastructure allows organizations to use compute resources efficiently and elastically, scaling down when demand is low rather than maintaining fixed capacity. For workloads with variable traffic patterns, this can meaningfully reduce cloud spend.

Where Culture Creates Friction

Despite the clear benefits, organizational culture is consistently identified as a top barrier to effective Kubernetes adoption. Several survey findings illustrate this:

Internal Alignment Is a Major Problem

40% of respondents cited a lack of internal alignment as a problem specifically when selecting a Kubernetes distribution. Choosing a Kubernetes platform should be a technical decision, but in practice it often becomes a cross-functional negotiation involving multiple stakeholders with different priorities.

Multiple Teams Are Involved in Every Decision

83% of respondents say more than one team is involved in selecting a Kubernetes distribution. This is not inherently problematic — broad input can improve decisions — but when combined with poor alignment, it leads to the familiar pattern of many meetings that fail to produce a clear decision.

Who ultimately drives the decision depends on context:

• When Kubernetes is deployed for development only, development teams are the primary decision-makers 38% of the time.
• In production environments, infrastructure teams are primary decision-makers 23% of the time.
• C-level executives are directly involved in the decision 18% of the time — a reflection of the strategic weight organizations place on selecting their next-generation platform.

Executives and Developers See Completely Different Obstacles

Perhaps the most operationally significant finding is a sharp disconnect between what executives think developers struggle with and what developers actually report:

• 46% of executives believe the biggest developer obstacle is integrating new technology into existing systems.
• Developers themselves rank waiting for central IT to provision infrastructure access as their top obstacle — cited by 29% of developer respondents.
• Only 6% of executives identify infrastructure access delays as a meaningful obstacle for developers.

This gap matters operationally. When leadership misdiagnoses the problem, investments go toward integration tooling and training when the actual bottleneck is an internal provisioning process. Developer velocity suffers not because of technical complexity, but because access to infrastructure is controlled through slow, centralized workflows.

Kubernetes Has Not Yet Closed the Dev–Ops Divide

One of the aspirational promises of Kubernetes is that it creates a common operational layer that brings development and operations teams closer together — a shared platform with consistent abstractions for deploying, scaling, and managing applications. In practice, the survey suggests this convergence has not fully materialized in most enterprises.

The organizational structures, decision-making processes, and cultural norms that existed before Kubernetes tend to persist after adoption. Kubernetes can reduce technical friction, but it does not automatically restructure how teams collaborate, who controls what, or how priorities are set.

What Organizations Can Do

The survey authors conclude that organizations adopting Kubernetes and other cloud-native technologies may need to make deliberate adjustments to their organizational structure and culture to realize the full potential of the technology. Some practical areas to address:

• Reduce provisioning friction. If developers are waiting on central IT for infrastructure access, self-service provisioning models — with appropriate guardrails — can eliminate a significant source of delay.
• Clarify decision ownership. Define in advance which teams own which decisions for Kubernetes platform selection, cluster configuration, and workload onboarding. Ambiguity drives the meeting-heavy, decision-poor dynamic the survey describes.
• Bridge the executive–developer perception gap. Regular, structured channels for developers to surface operational obstacles to leadership can help ensure investments target actual bottlenecks rather than assumed ones.
• Treat platform selection as a product decision. When C-level executives are involved 18% of the time in Kubernetes distribution selection, the organizational stakes are high. Treat the evaluation with appropriate rigor — defined criteria, time-boxed analysis, and a clear decision owner.
• Invest in cross-functional enablement. Kubernetes spans development, operations, security, and networking. Training and enablement programs that cut across these silos can reduce the alignment problems that slow adoption.

Key Takeaway

Kubernetes is becoming a standard part of the enterprise infrastructure stack, delivering measurable improvements in resource utilization, development velocity, and cloud cost management. But the technology alone does not resolve the organizational challenges that have historically slowed IT modernization. Cultural resistance, misaligned incentives, and siloed decision-making remain the hardest problems to solve — and they require deliberate organizational change, not just better tooling.

As the survey puts it: containers won’t fix your broken culture. But understanding where the cultural friction points are is a useful starting point for addressing them.

Microsoft Moves Deeper Into 5G Infrastructure

Microsoft announced an agreement to acquire Affirmed Networks, a specialist in virtualized, cloud-native mobile network solutions. The deal signals a clear strategic intent: to position Azure as a premier platform for telecommunications operators navigating the transition to 5G.

Affirmed Networks provides a portfolio of 5G applications and services designed to simplify network operations and accelerate the launch of new network-based services. At the time of the announcement, Affirmed was already serving major global telcos including SoftBank, Vodafone, and Orange.

What Affirmed Networks Brings to Azure

Affirmed Networks’ core product is a fully virtualized Evolved Packet Core (vEPC) and 5G core — essentially the software-defined heart of a mobile network. Running these functions in a cloud-native environment, rather than on proprietary hardware, enables operators to:

• Scale network capacity dynamically without adding physical infrastructure
• Deploy and update network functions as containerized microservices
• Run network workloads across hybrid environments that span public cloud and on-premises edge hardware
• Reduce operational costs associated with traditional, hardware-bound telco architectures

Microsoft stated that the acquisition would allow it to extend its cloud offering to operators globally as they increasingly look to operate their networks in hybrid environments — combining private on-premises infrastructure with public cloud capacity.

Microsoft’s Broader Telco Ambitions

The Affirmed acquisition is not an isolated move. Microsoft has been systematically building its telco credentials over many years, even if some earlier efforts (such as ventures into mobile operating systems) did not succeed. The purchase of Skype demonstrated that Microsoft was willing to cross traditional ICT industry boundaries when it saw long-term strategic value.

The larger question the industry is watching is whether Microsoft’s end game extends beyond selling cloud services to telcos, toward building or assembling the components of a global, virtualized network infrastructure of its own — one that could bind data centers to telco edge and access networks on a worldwide scale. Such a capability would make Azure a uniquely powerful platform for delivering end-to-end cloud services to enterprise customers.

Whether the strategy is to empower existing operators or to enable new market entrants — or both — the Affirmed deal puts Azure squarely in the telco infrastructure conversation.

A Crowded and High-Stakes Competitive Landscape

Microsoft is entering territory already contested by several well-resourced rivals:

• Amazon Web Services (AWS) had already established a presence in hosting telecom functions via AWS Wavelength, which embeds compute and storage capacity at the 5G network edge to minimize latency for end applications.
• Google Cloud launched Anthos for Telecom, extending its Anthos hybrid and multi-cloud platform to the network edge, with tools to help operators build, secure, and manage cloud-native and hybrid network environments.
• HPE released its 5G Core Stack, offering software building blocks for operators constructing 5G core networks.
• IBM acquired Red Hat, bringing open-source, cloud-native expertise — including Red Hat’s significant footprint in the telecom software space — under its umbrella.
• Dell Technologies combined Dell’s hardware scale with VMware’s virtualization and cloud software, targeting the infrastructure layer of the telco modernization stack.

Why This Matters for DevOps and Platform Engineers

The convergence of hybrid cloud, telco edge computing, and 5G represents one of the defining infrastructure shifts of the decade. For DevOps and platform engineering teams, this means:

• New edge deployment targets: 5G network edges hosted on cloud platforms like Azure will become viable deployment environments for low-latency applications, expanding the operational scope for engineering teams.
• Cloud-native telco patterns: As network functions move to Kubernetes-based, containerized deployments, the tooling and practices familiar to cloud engineers — Helm charts, GitOps pipelines, observability stacks — become relevant inside telecom networks themselves.
• Vendor consolidation risk and opportunity: Major acquisitions like this reshape platform ecosystems. Teams building on Azure should monitor how Affirmed’s capabilities are integrated into Azure services over time.

Summary

Microsoft’s acquisition of Affirmed Networks is a deliberate step in a longer-term strategy to make Azure the cloud platform of choice for telecommunications operators worldwide. With strong existing competitors already in the space, the outcome is far from certain — but the deal gives Microsoft cloud-native 5G core technology and established operator relationships that meaningfully improve its starting position. The hybrid cloud and telco edge space is set to be fiercely competitive through the remainder of the decade.

Overview

Palo Alto Networks announced a significant update to Prisma Cloud, its Cloud Native Security Platform (CNSP), in early 2020. The release targeted both DevOps and SecOps teams, adding shift-left security capabilities, centralized CI/CD policy management, Amazon Machine Image (AMI) scanning, and one-click serverless protection. The overarching goal was to unify previously siloed development and security teams under a DevSecOps model that spans the entire application lifecycle—from infrastructure code authoring through production workload monitoring.

The Security Challenge in Cloud Native Environments

Modern developer-led organizations move fast, relying on containers, serverless functions, and infrastructure as code (IaC) templates to build and scale applications. This velocity introduces compounding security risks:

• Sprawling cloud footprints: Multiple clouds and accounts increase the attack surface and the number of entities that must be monitored.
• Insecure IaC templates: According to the Palo Alto Networks Unit 42 Cloud Threat Report (Spring 2020), nearly 200,000 insecure IaC templates were found in active use across organizations globally. Misconfigurations baked into templates propagate at the speed of automation.
• Abstraction layers: Containers, orchestrators, and serverless runtimes each add layers of abstraction, making traditional perimeter-based security insufficient.
• Fragmented tooling: Disparate security controls across applications, data, and infrastructure create visibility gaps and inconsistent enforcement.

Addressing these challenges requires security to be embedded at every phase of the software delivery pipeline—not bolted on after deployment.

What Is a Cloud Native Security Platform (CNSP)?

A CNSP converges two previously distinct categories of cloud security tooling:

• Cloud Security Posture Management (CSPM): Continuously monitors cloud configurations, detects misconfigurations, and enforces compliance against standards such as CIS Benchmarks, PCI-DSS, and HIPAA.
• Cloud Workload Protection Platform (CWPP): Protects the runtime of VMs, containers, and serverless functions—covering vulnerability management, behavioral protection, and runtime defense.

By converging CSPM and CWPP in a single platform, security teams can manage risk from code commit through production workload, without switching between multiple consoles or reconciling inconsistent data.

Palo Alto Networks cited a Gartner analysis (as of early 2020) recognizing the company as one of three vendors actively converging CWPP and CSPM capabilities across development and production environments, including container and serverless protection.

Key Features in This Release

1. Shift-Left Security: IaC Scanning

Prisma Cloud introduced the ability to scan IaC templates before they are deployed, using both out-of-the-box and customizable policies. This catches insecure configurations at the point of authoring rather than at runtime.

Supported integration points at release included:

• IDE plugins: IntelliJ, VS Code
• Source Control Management (SCM): GitHub
• CI/CD pipelines: AWS CodePipeline, Azure DevOps, CircleCI, GitLab, Jenkins

Additional plugins (GitLab, Bitbucket) were announced as coming soon at the time of publication.

2. Central CI/CD Policy Management

Teams can now define vulnerability and compliance policies for CI and CD workflows directly from the Prisma Cloud dashboard. This centralization means:

• IaC policies can be authored and reviewed in a single location.
• Out-of-the-box policies cover CIS standards for AWS, Azure, and GCP.
• Policy enforcement is consistent across pipelines, reducing configuration drift between environments.

3. Amazon Machine Image (AMI) Scanning

Prisma Cloud extended its vulnerability management capabilities to cover Amazon Machine Images (AMIs), enabling teams to vet images for vulnerabilities and compliance violations before they are deployed as EC2 instances. This mirrors the scanning capability already available for container registries and serverless repositories, creating a consistent vulnerability management experience across workload types.

4. Automatic Serverless Protection for AWS Lambda

Building on Palo Alto Networks’ acquisition of PureSec (integrated in November 2019), this release added one-click automatic protection for AWS Lambda functions directly from the Prisma Cloud console. Previously, enabling serverless security required developers to manually instrument their function code with security wrappers—a friction point that slowed adoption.

With automatic protection enabled, all existing serverless security capabilities become available without code changes:

• Vulnerability management
• Behavioral protection
• Serverless Cloud Native Application Firewall (CNAF)

Customer Perspectives

Several enterprise teams shared their use cases at the time of the announcement:

“Being able to effectively identify and remediate vulnerabilities and misconfigurations before applications are released into production empowers our security and developer teams to innovate quickly—with the confidence that our business is compliant and our customers’ data is secure.”

Wiebe de Roos, CI/CD Consultant & Engineer, ABN AMRO

“Today, Prisma Cloud empowers our SOC to continuously monitor our cloud environments as well as provide forensic data for faster Incident Response. I am looking at Prisma Cloud’s Shift Left features to enable our security professionals to partner more closely with developers on security responsibilities, and ensure secure configurations in every phase of development.”

Xiaobo Long, SVP of Cloud Security, Citibank

“Prisma Cloud helps our company reach the concept of DevSecOps, where we assess security in every phase of development. If any vulnerability or flaw is discovered, we patch it before going into production. In a single pane of glass, we have everything under control.”

Nicola Mutti, Head of Security, Cuebiq

How These Features Support a DevSecOps Model

The features in this release map directly to the three core phases where security must be embedded in a DevSecOps pipeline:

This lifecycle coverage means a single platform can enforce consistent security policy from the first line of infrastructure code through the running workload—closing the gap between what developers build and what security teams monitor.

Availability

At the time of the March 2020 announcement, general availability of the new features described above was expected by late April 2020. Readers should consult current Palo Alto Networks documentation for up-to-date feature availability and platform versions.

Getting Started with Cloud Native Security

For teams beginning their cloud native security journey, the core priorities are:

1. Inventory your IaC templates and run an initial scan to identify existing misconfigurations before they reach production.
2. Integrate IaC scanning into your CI pipeline so that policy violations block builds automatically rather than relying on manual review.
3. Enable CSPM across all cloud accounts to establish a compliance baseline and detect configuration drift.
4. Extend CWPP coverage to include not just containers but also VMs (via AMI scanning) and serverless functions.
5. Centralize policy management so that development, operations, and security teams operate from the same set of rules.

This incremental approach aligns with the DevSecOps principle of embedding security at each stage rather than attempting to retrofit it after deployment.

D2iQ Expands Into CI/CD With Dispatch

D2iQ — the company formerly known as Mesosphere — extended its Kubernetes portfolio by releasing Dispatch, a cloud-native CI/CD platform integrated directly into its Konvoy Kubernetes distribution. The move signals D2iQ’s intent to offer a more complete platform story, covering not just cluster management but also the continuous integration and delivery pipelines that run on top of those clusters.

Core Design Philosophy: Separation of Concerns and GitOps

Dispatch is designed around two guiding principles: a clear separation of responsibilities between developers and operators, and a GitOps-first approach to pipeline and application configuration. In practice, this means that both pipeline definitions and deployment configuration live in a Git repository, giving every stakeholder a single, version-controlled source of truth for the state of the system.

This GitOps model is increasingly common in the cloud-native ecosystem, but Dispatch’s integration with D2iQ’s existing toolchain — including Konvoy and the Kommander cluster management layer — gives it a tighter operational context than standalone CI/CD tools typically provide.

Multi-Language Pipeline Configuration

One of Dispatch’s headline differentiators is its support for four domain-specific languages for writing pipeline configuration:

• JSON — familiar to most developers and widely tooled
• YAML — the de facto standard in Kubernetes-adjacent tooling
• CUE — a configuration language derived from JSON with added constraints and data validation
• Starlark — a Python-like scripting language originally developed for the Bazel build system, designed to be deterministic and embeddable

Most competing CI/CD platforms in the cloud-native space default to YAML exclusively. Offering CUE and Starlark alongside the more common formats gives teams with complex pipeline logic more expressive options, and reduces the friction of adopting the tool for teams already working in those languages.

Built on Tekton and Argo CD

Dispatch does not build its execution engine from scratch. According to D2iQ, it is designed to work alongside Tekton (a Kubernetes-native CI/CD framework originally from Google) and Argo CD (a declarative GitOps continuous delivery tool for Kubernetes). This means Dispatch acts partly as an orchestration and configuration layer on top of established CNCF-ecosystem components, rather than reinventing the underlying pipeline execution model.

Multi-Tenancy via Kubernetes Namespaces

Dispatch leverages Kubernetes’ native namespace model to deliver built-in multi-tenancy. Teams can run their pipelines in isolated namespaces, providing resource separation and access control without requiring a separate tenancy management system. This is a practical advantage in enterprise environments where multiple teams share the same cluster infrastructure.

Context: A Crowded CI/CD Landscape

Dispatch arrived into an already busy space. The cloud-native CI/CD problem was prominently discussed at KubeCon Europe 2018 in Copenhagen, which prompted a wave of new projects across the ecosystem. By the time Dispatch launched, the CI/CD section of the cloud-native landscape included dozens of projects at varying stages of maturity.

This level of competition cuts both ways. It validates the problem space, but it also raises the bar for differentiation. Dispatch’s primary advantages — GitOps integration, multi-language support, and tight coupling with D2iQ’s Konvoy and Kommander toolchain — are most compelling for teams already invested in the D2iQ ecosystem.

Availability and Trial

At the time of this report, Dispatch was available to try for free as part of the Konvoy trial offering. The trial bundle also included:

• A declarative universal operator for managing Kubernetes workloads
• Kommander — D2iQ’s tool for federated, cross-cluster management

This bundled approach reflects D2iQ’s broader strategy: positioning Konvoy not just as a Kubernetes distribution, but as an integrated platform for running production workloads end-to-end, from cluster provisioning through to continuous delivery.

Summary

Dispatch represents D2iQ’s entry into the cloud-native CI/CD market, with a design that prioritizes GitOps workflows, multi-language flexibility, and Kubernetes-native multi-tenancy. Its reliance on Tekton and Argo CD as underlying components gives it a foundation in proven open-source tooling, while its integration with Konvoy and Kommander makes it a natural fit for existing D2iQ customers. Teams outside the D2iQ ecosystem will need to weigh those integration benefits against the crowded field of alternatives.

Securing Kubernetes API Access on AKS

Richard Hooper (Pixel Robots) wrote a practical guide on locking down access to the Kubernetes API server on an Azure Kubernetes Service (AKS) cluster. By default, an AKS API server is reachable over the public internet via HTTPS — a significant attack surface for any production workload.

Hooper noted that while role-based access control (RBAC) and Azure Active Directory (AAD) integration add meaningful layers of security, they may not satisfy every organization’s threat model. Azure Security Center will flag clusters that fall short of its security recommendations, which can serve as a useful prompt for teams that haven’t yet addressed API exposure.

Restricting API Server Access with Azure CLI

AKS supports IP-based allowlisting for the API server. Using the Azure CLI, you can update an existing cluster to accept traffic only from a defined set of CIDR ranges. After applying the change, access can be verified with a kubectl command from an allowed IP.

One important operational consideration: if you use Azure DevOps pipelines to deploy to AKS, you must include the relevant Azure DevOps agent IP ranges in your allowlist. Omitting them will cause pipeline steps that call the Kubernetes API (such as kubectl apply or Helm deployments) to fail with a connection error.

“It’s a bit of a pain, but as I am sure you are aware Security always is. I for one will be using this for all of my AKS clusters going forward and would advise you do too. Just remember if your pipeline fails due to it being unable to connect to the AKS cluster update the IP whitelist.”

— Richard Hooper, Pixel Robots

Azure Firewall Updates: What Changed in February 2020

Aidan Finn reviewed the Azure Firewall features that entered preview or general availability in February 2020, focusing on what they mean for enterprise network administrators.

Azure Firewall Manager

Firewall Manager (at the time in preview) provides a centralized control plane for managing firewall policies and firewall resources across one or more Azure regions. For organizations running identical or similar deployments in multiple regions, the parent/child policy model is particularly useful: a parent policy defines a baseline set of rules that child policies in each region can extend without duplicating configuration.

IP Groups

IP Groups let administrators create named, reusable collections of IP addresses that can be referenced in network rules. This abstraction reduces duplication and makes rule sets easier to audit and maintain. Finn also noted that the standard maximum port range applies to TCP/UDP rules (up to port 65535), which constrains how rules can be structured.

Forced Tunneling and Public IP Flexibility

Forced tunneling — routing outbound internet traffic back on-premises — is available but, in Finn’s assessment, is likely only justified for government agencies and similarly compliance-heavy organisations. A more broadly useful capability is configuring public IP ranges in private networks via PowerShell and JSON, offering greater flexibility for scenarios that don’t require full traffic hairpinning.

Microsoft Retiring MCSE, MCSD, and MCSA Certifications

Chris Pietschmann (Build5Nines) covered Microsoft’s decision to retire the MCSE, MCSD, and MCSA certification families in favour of role-based certifications. The retirement date was set for June 30, 2020, affecting 15 certifications and 42 individual exams.

Microsoft had signalled this direction as early as September 2018. The certifications being retired include:

• MCSA: BI Reporting, SQL Server (various tracks)
• MCSD: App Builder
• MCSE: Business Applications, Core Infrastructure, Productivity, Data Management and Analytics

“If you are on your path to earning these certifications, then you have until June 30, 2020 to pass the required exams to earn the certifications. After that date they will no longer be available to be earned. Once retired, these certifications will remain on your official Microsoft certification transcript… for 2 years from the June 30, 2020 date; after which they will be moved to the ‘inactive’ section of your transcript.”

— Chris Pietschmann, Build5Nines

Transitioning to Role-Based Certifications

There are no direct one-to-one replacements for the retiring certifications, but Microsoft was developing guidance for transitional learning paths. As an example, candidates holding or pursuing the MCSE: Core Infrastructure certification were pointed toward role-based alternatives such as:

• Azure Administrator Associate
• Azure Security Engineer Associate
• Azure Solutions Architect Expert

The new role-based certifications carry a two-year renewal cycle, which aligns with the two-year transcript retention window for retired credentials.

Cloud-Native Thinking: Containers, Kubernetes, and Serverless

Karim Vaes shared a reflective post on his journey migrating VMchooser toward a more serverless and container-based architecture. His observations offer a useful on-the-ground perspective for teams navigating similar decisions.

Why Containers?

Vaes developed an appreciation for containerization around 2015, valuing the portability and repeatability containers provide. He frames containers as a form of configuration management — similar in purpose to tools like Ansible or Puppet, but packaging the entire runtime environment rather than just configuration state.

Kubernetes for Hybrid and Cross-Platform Scenarios

Kubernetes earns a place in Vaes’s architecture primarily for its cross-platform capabilities and support for hybrid cloud scenarios, where workloads must run consistently across on-premises and cloud environments. For teams already invested in Kubernetes, a managed and certified Kubernetes service (such as AKS) is the pragmatic path forward.

The Case for Going Directly to Serverless

After experimenting with serverless, Vaes questioned why more teams don’t skip containers and Kubernetes entirely in favour of serverless architectures. His reasoning:

• Serverless is less infrastructure-oriented than Kubernetes, lowering operational overhead.
• Cost optimization is more straightforward — you pay per execution rather than for always-on compute.
• For applications that don’t require fine-grained orchestration, Azure App Service or Azure Container Instances may be sufficient without introducing a full Kubernetes control plane.

The practical takeaway for teams evaluating their cloud-native strategy: the right answer depends on workload requirements, team expertise, and operational maturity. Kubernetes is powerful but carries real complexity; serverless and PaaS offerings like App Service can deliver most of the benefits with less overhead for many application types.

This roundup covers community insights from March 2020. Some product features mentioned (such as Azure Firewall Manager preview) may have since reached general availability or changed. Always consult the current Azure documentation for up-to-date guidance.

D2iQ Brings GitOps-Driven CI/CD to Enterprise Cloud-Native Workloads

D2iQ, a provider of enterprise-grade cloud platforms focused on Day 2 operations, announced the general availability of Dispatch on March 4, 2020. Dispatch is an integrated GitOps platform built to help engineering teams rapidly build, test, and deploy cloud-native, microservices-based applications at scale.

The platform targets a core challenge many organizations face when modernizing their software delivery pipelines: reducing the complexity of getting new code into production consistently and repeatably, without slowing down development velocity.

The Problem Dispatch Aims to Solve

As software teams face mounting pressure to ship features faster, the operational overhead of managing deployment workflows can become a significant bottleneck. Organizations adopting microservices architectures often struggle with:

• Coordinating responsibility between application developers and platform operators
• Maintaining consistency across automated deployment pipelines
• Reducing the manual steps required to promote code from development to production
• Managing the full application lifecycle beyond initial deployment — what D2iQ refers to as Day 2 operations

Traditional CI/CD toolchains often require significant custom integration work and can blur the lines between developer and operator responsibilities, introducing both risk and toil.

What Is Dispatch?

Dispatch is an integrated CI/CD platform built on open-source technologies that enables a GitOps approach to application delivery. In a GitOps model, Git repositories serve as the single source of truth for both application code and infrastructure configuration. Changes to the desired state of a system are made through pull requests, and automated processes reconcile the live environment to match the declared state in Git.

Key characteristics of Dispatch as described at launch:

• Separation of concerns: Dispatch enforces a clear division between developer workflows (continuous integration, building and testing code) and operator workflows (continuous delivery, managing deployments).
• Open-source foundations: The platform is built on prevailing open-source technologies, giving organizations flexibility in tooling choices and reducing vendor lock-in.
• Full CI/CD lifecycle: Dispatch covers continuous integration through to continuous delivery, providing end-to-end automation for the application delivery pipeline.
• Cloud-native focus: Designed specifically for microservices-based applications running on modern cloud infrastructure.
• Day 2 readiness: Beyond initial deployment, Dispatch is positioned to support ongoing operational management — patching, scaling, and lifecycle management after an application is in production.

GitOps and Day 2 Operations: Why They Matter Together

D2iQ has long emphasized Day 2 operations — the work that happens after initial deployment — as the real challenge in enterprise infrastructure. Most teams can get software deployed; keeping it running reliably, securely, and efficiently at scale is where complexity compounds.

Combining GitOps workflows with Day 2 operational tooling addresses this by:

• Providing auditable, version-controlled records of every change to application and infrastructure state
• Enabling rollbacks through standard Git operations (reverting a commit) rather than manual intervention
• Allowing operators to manage application configurations declaratively, reducing configuration drift
• Supporting automated reconciliation so the live environment stays consistent with the desired state defined in Git

D2iQ Leadership Perspective

“Moving from legacy to cloud native applications is becoming a requirement for organizations that want to keep pace with the digital economy. Dispatch leverages D2iQ’s expertise in building distributed systems for some of the largest global organizations to deliver business logic that enables enterprises to accelerate their cloud native CI/CD pipeline through GitOps processes. This empowers organizations with a clear path to success and business impact as their cloud native journey continues to Day 2 operations.”

— Ben Hindman, Co-founder and Chief Product Officer, D2iQ

Context: D2iQ’s Position in the Cloud-Native Ecosystem

D2iQ (formerly Mesosphere) built its reputation on distributed systems tooling, including the DC/OS platform and Kubernetes-based products. Dispatch represents the company’s push to extend its platform capabilities to cover the full software delivery lifecycle, not just cluster management and orchestration.

The launch of Dispatch placed D2iQ in direct competition with a growing field of CI/CD and GitOps tooling, including projects like Argo CD, Flux, Tekton, and Jenkins X — all of which are also built on open-source Kubernetes-native foundations.

Key Takeaways for DevOps Teams

• Dispatch targets enterprises that need a structured, opinionated GitOps platform rather than assembling their own CI/CD toolchain from scratch.
• The emphasis on separating developer and operator responsibilities can help larger organizations scale DevOps practices without creating cross-team bottlenecks.
• Being built on open-source technologies means teams are not entirely locked in, but the degree of openness and extensibility would require hands-on evaluation.
• The Day 2 operations focus differentiates Dispatch from tools that address only the initial deployment problem.

This article is based on D2iQ’s March 4, 2020 press release announcing the general availability of Dispatch. For current product information, consult D2iQ’s official documentation and release notes directly.

The Core Finding: Misconfiguration Outranks Vulnerabilities and Attacks

Securing a Kubernetes environment is a substantially harder problem than simply running one. A survey of more than 540 Kubernetes and container practitioners — spanning IT security, DevOps, engineering, and product roles — found that human error and misconfiguration are the dominant causes of container security incidents. The research was conducted by StackRox with assistance from advisory firm 451 Research.

Key top-line results from the report:

• 94% of respondents experienced at least one container security incident in the preceding 12 months.
• 44% reported that security concerns delayed moving applications into production.
• 61% cited misconfigurations as the risk they were most concerned about.
• 27% identified known vulnerabilities as their primary concern.
• 12% named active attacks as their top concern.

The near-universal rate of security incidents, combined with the production delays they cause, paints a picture of an ecosystem where security practices have not kept pace with adoption speed.

Why Kubernetes Is Especially Prone to Misconfiguration

Kubernetes offers an enormous surface area for configuration: pod security policies, RBAC rules, network policies, admission controllers, secrets management, service account permissions, and more. Each of these has sensible defaults that are often insecure, and each can be overridden by operators who may not fully understand the downstream security implications.

Common misconfiguration categories that create security exposure in Kubernetes clusters include:

• Overly permissive RBAC roles — granting cluster-admin to service accounts or users who do not require it.
• Running containers as root — failing to set securityContext.runAsNonRoot: true or a specific UID.
• Disabled or absent network policies — allowing unrestricted pod-to-pod and pod-to-external communication.
• Exposed Kubernetes API server — leaving the API server reachable from the public internet without strong authentication.
• Privileged containers — setting privileged: true without a clear operational justification.
• Missing resource limits — creating denial-of-service risk through unbounded CPU and memory consumption.
• Secrets stored in environment variables or ConfigMaps rather than a dedicated secrets manager.

As Michelle McLean, then VP of Marketing at StackRox, summarized: “People understand that Kubernetes has a lot of knobs and dials, and it’s easy to get it wrong.”

The Business Impact: Delayed Deployments and Slowed Innovation

The business case for Kubernetes is speed — faster build, test, and release cycles. When security incidents or security reviews block production deployments, that core value proposition erodes. The StackRox report identified the delayed rollout of applications as a direct consequence of unresolved security concerns, creating a feedback loop where rapid adoption outpaces the ability to govern what is being deployed.

This tension is not unique to Kubernetes, but the platform’s complexity amplifies it. Organizations that adopt cloud-native architecture without embedding security into their pipelines often discover gaps only at runtime — at which point the cost of remediation is significantly higher.

Shifting Security Left in Kubernetes Workflows

The report’s primary recommendation echoes a principle that has gained wide traction in DevSecOps: security must be embedded into the development and deployment pipeline rather than applied as an afterthought before or after production release.

Practically, shifting security left in a Kubernetes context means:

• Linting and policy checks at build time — tools such as kube-score, kube-linter, and Checkov can analyse Kubernetes manifests for security misconfigurations before they reach a cluster.
• Admission controllers — deploying policy engines such as Open Policy Agent (OPA) Gatekeeper or Kyverno to enforce security policies at the point of admission to the cluster.
• CI/CD pipeline integration — making security policy checks a blocking gate in CI, so a manifest with a privileged container or missing resource limits cannot be merged without explicit review.
• Developer education — providing developers with clear, opinionated baseline manifests and documented security requirements rather than expecting them to derive best practices independently.
• Runtime monitoring — using tools such as Falco to detect anomalous behaviour at runtime, complementing preventive controls.

Context: Kubernetes Security Audits and the CNCF Ecosystem

The report was published following the first formal security audit of Kubernetes, commissioned by the Cloud Native Computing Foundation (CNCF). That audit surfaced a number of architectural concerns and was intended to give the broader community a clearer picture of the platform’s attack surface. Despite that effort, widespread adoption continued to outrun security maturity across many organisations.

The StackRox findings reinforced a consistent message from the security community: the Kubernetes project itself is not the primary source of risk for most organisations. The risk lies in how clusters are configured and operated by the humans managing them.

Recommendations for Kubernetes Security Teams

Based on the themes in the StackRox report, teams looking to reduce misconfiguration risk should consider the following actions:

1. Audit existing clusters against a recognised benchmark such as the CIS Kubernetes Benchmark using tools like kube-bench.
2. Define and enforce a baseline pod security standard — Kubernetes 1.23+ ships with Pod Security Admission as a replacement for the deprecated PodSecurityPolicy.
3. Review RBAC configurations regularly — use kubectl auth can-i --list and third-party tools such as rbac-lookup or rakkess to audit effective permissions.
4. Enable and review audit logs — the Kubernetes API server audit log provides visibility into who is doing what in the cluster.
5. Implement a GitOps workflow — storing all manifests in version control and deploying through a controlled pipeline reduces ad-hoc manual changes that introduce misconfiguration.
6. Cross-train DevOps and security teams — misconfigurations often occur at the boundary between teams. Shared understanding of security requirements reduces the chance of errors.

As the report noted: “Companies need a combination of increased learning, cross-pollination, new tooling, and updated processes to identify and remediate security mistakes during build and deploy — rather than waiting for exposure during runtime.”

Summary

The StackRox “State of Container and Kubernetes Security” survey data from early 2020 identified a clear and persistent pattern: misconfiguration driven by human error is the leading source of security risk in Kubernetes environments, ahead of both unpatched vulnerabilities and external attacks. Addressing this requires a structural shift — embedding security into CI/CD pipelines, enforcing policy at admission time, and investing in cross-team education — rather than relying on reactive runtime detection alone.

Kubernetes Beyond the Basics

About five years after Google handed over control of Kubernetes to the Cloud Native Computing Foundation (CNCF), the platform had already become the de facto standard for container orchestration. A 2019 survey conducted in partnership with Aqua Security reportedly found that 87% of respondents were running applications in containers, with nearly 90% of those running containers in production.

What’s less commonly discussed is how Kubernetes is being used in ways that go well beyond its original purpose of scheduling and orchestrating containerized workloads. Developers, vendors, and enterprise users are actively extending Kubernetes to serve other critical functions across the stack. Here are five of the most significant—and perhaps surprising—enterprise use cases.

1. On-Premises Deployments, Not Just Cloud

Kubernetes is frequently associated with public cloud providers, but many enterprises cannot—or choose not to—move sensitive data or proprietary intellectual property to a public cloud. Others have significant on-premises infrastructure they want to continue using.

Kubernetes handles both scenarios equally well. IT teams can use the same tooling, the same deployment pipelines, and the same operational practices whether they are running workloads on AWS, Azure, GCP, or in a private data center. Cloud-native application architectures—built around containers and microservices—provide the same benefits of speed and scalability in private cloud environments as they do in the public cloud.

This flexibility is a key reason Kubernetes adoption has spread across regulated industries such as financial services, healthcare, and government, where data residency and control are non-negotiable requirements.

2. Running Stateful Applications Alongside Stateless Ones

Early container use cases focused almost exclusively on stateless applications—services where each request is independent and no session data persists between calls. This limitation made containers impractical for many traditional enterprise workloads that depend on databases and other stateful systems.

The Kubernetes ecosystem has addressed this gap significantly. Features such as StatefulSets, PersistentVolumes, and PersistentVolumeClaims give operators fine-grained control over how storage is provisioned, attached, and retained for stateful workloads. Operators—custom Kubernetes controllers—have further extended this capability for specific databases and data platforms, automating tasks like provisioning, scaling, backup, and failover.

IDC data cited in Container Journal suggested that 76% of enterprises can now use containers broadly for mission-critical applications—a figure that would have been unthinkable when containers lacked meaningful stateful support.

3. Full Application Lifecycle Management

Kubernetes is increasingly used not just to deploy applications, but to manage them throughout their entire lifecycle—including high availability, disaster recovery, backup, and compliance.

Consider a traditional backup process in a database-centric environment: a restore operation typically recovers an entire machine image, bringing back all applications and data present at that snapshot point in time. Kubernetes-native backup tools, by contrast, can target specific application namespaces, workloads, or even point-in-time data states, making restores faster, more precise, and less resource-intensive.

Using a single platform for both application deployment and lifecycle management reduces operational complexity. Teams do not need to maintain separate toolchains for deploying applications and managing their long-term operational health.

4. A Unified Control Plane for Infrastructure

Kubernetes was originally designed to orchestrate containerized applications. Increasingly, it is also being used to manage the underlying infrastructure those applications depend on—storage, networking, and compute.

Two CNCF specifications make this possible:

• Container Storage Interface (CSI): A standardized API that allows storage vendors to expose their systems to Kubernetes without modifying the core Kubernetes codebase. This enables dynamic provisioning, snapshotting, and resizing of storage volumes across a wide range of backends.
• Container Network Interface (CNI): A standardized plugin model for configuring network interfaces in containers, allowing network vendors and open-source projects to integrate with Kubernetes in a consistent way.

Together, these interfaces allow Kubernetes to act as a unified control plane across both the application layer and the infrastructure layer. This reduces the number of separate management systems an organization needs to operate and keeps infrastructure management in step with the rapid pace of application-layer changes.

5. Accelerating AI and Machine Learning Workloads

Kubernetes is well suited for AI and machine learning pipelines for several reasons:

• Isolated environments: Data scientists can work in separate Kubernetes namespaces or pods, experimenting with different datasets or model configurations without interfering with each other or with production systems.
• Independent scaling: Kubernetes allows compute resources (including GPU-backed nodes) to scale independently from storage or other services, which is particularly valuable during the training phase of ML models, when GPU demand spikes significantly.
• Streamlined deployment: Once a model is ready for production, Kubernetes enables it to be packaged and deployed as a containerized microservice, using the same CI/CD pipelines used for other application workloads.
• Workflow automation: Projects such as Kubeflow—built on top of Kubernetes—automate ML pipeline steps including data preparation, training, hyperparameter tuning, and serving.

Major vendors including Google and HPE have built AI-specific offerings on top of Kubernetes, reflecting broader industry recognition that container orchestration is a natural fit for the iterative, compute-intensive nature of machine learning development.

What This Means for Enterprise IT

The common thread across all five use cases is convergence. Rather than operating separate platforms for application deployment, infrastructure management, data lifecycle management, and AI workloads, enterprises are increasingly using Kubernetes as a single, extensible platform that spans all of these concerns.

This consolidation offers real operational advantages: fewer tools to learn, fewer integration points to maintain, and a single community and ecosystem to draw from when solving new problems. The same speed, flexibility, and scale that made containers attractive for application development are now being extended into adjacent areas of enterprise IT—and Kubernetes is the platform making that possible.

As the open-source ecosystem around Kubernetes continues to mature, it is reasonable to expect further extension of the platform into areas such as edge computing, serverless workloads, and multi-cluster federation—each of which is already seeing active development in the CNCF project landscape.

Overview

Ericsson announced four additions to its 5G platform aimed at enhancing user experience, reducing complexity and total cost of ownership (TCO), enabling faster service deployment, and introducing automated provisioning. As operators move to 5G, the mobile network must support a broader range of services and significantly higher data volumes than previous generations, demanding greater levels of automation and intelligence throughout the stack.

David Bjore, Head of R&D and Portfolio, Business Area Digital Services at Ericsson, commented: “Through our core networks, service providers can get to market faster and can capitalize on new services, through leading consumer and enterprise communication and monetization solutions, enabling them to stay ahead in the race for 5G business, today and tomorrow.”

Key Additions to the 5G Platform

• Dual-mode 5G Core with built-in software probes, integrated with Ericsson Expert Analytics
• Ericsson Cloud Native Infrastructure: bare-metal container infrastructure for 5G Core deployments
• Ericsson Communication Accelerator: cloud-based microservices for business communication
• Automated eSIM offering for expanded device connectivity

Securing 5G Experience with Built-In Software Probes

Traditional appliance-based probing is not sustainable at 5G Core scale. Hardware probes add cost and operational complexity that conflicts with the cloud-native design principles underpinning 5G architecture. Ericsson’s dual-mode 5G Core addresses this by embedding software probes directly into the core network, eliminating the need for separate probing appliances and the associated capital expenditure.

These built-in probes are pre-integrated with Ericsson Expert Analytics, providing correlated end-to-end insights that extend from the core to the Radio Access Network (RAN). Transparent and secure interfaces in the 5G Core architecture also ensure that sensitive subscriber data remains protected during analysis.

Anil Rao, Principal Analyst at Analysys Mason, stated: “The traditional appliance-based probes technology and the associated CEM approaches are not fit for purpose to guarantee customer experiences in cloud-based 5G networks. Ericsson’s dual-mode 5G Core with built-in software probes, pre-integrated with Ericsson Expert Analytics’ intelligence, enables CSPs to deliver superior 5G customer experiences and accelerate 5G roll-out.”

Cloud Native Infrastructure: Containers on Bare Metal

Ericsson introduced Ericsson Cloud Native Infrastructure, a bare-metal container platform designed to simplify the deployment of cloud-native applications such as 5G Core, both at central data centers and at edge sites. By removing the virtualization layer—eliminating the hypervisor overhead present in traditional VM-based deployments—the solution reduces complexity and improves hardware efficiency and application performance.

Ericsson claims TCO savings of 30% or more compared to VM-based infrastructure, though this figure should be treated as a vendor estimate rather than an independently verified benchmark. Automated deployments across distributed sites are a core design goal, which aligns with the operational requirements of large-scale 5G rollouts.

Caroline Chappell, Research Director at Analysys Mason, noted: “A bare metal container infrastructure makes network deployments and operations simpler and automation easier as well as enhancing cloud native function (CNF) performance. The announcement of a bare metal solution is an important contribution to further progress telecom operators’ implementations of cloud native applications.”

Ericsson Communication Accelerator: Business Communication Services

The Ericsson Communication Accelerator is a portfolio of cloud-based microservices that communication service providers (CSPs) can combine to rapidly deliver advanced mobile business communication offerings. The solution is delivered as-a-service and is designed to leverage a service provider’s existing network assets, reducing time to market while maintaining security and quality of service controls.

New Service Opportunities for Operators

• Enterprise Voice Services: Combines traditional business voice with innovative features to differentiate operator offerings in the enterprise market.
• IoT Voice Services: Provides automated, centralized management of voice services for IoT deployments.
• Contextual Communication Services: Enables straightforward integration of advanced communication and collaboration capabilities into websites or third-party applications.

Diane Myers, Senior Research Director for VoIP, UC and IMS Technology at IHS Markit, commented: “Cloud communications services for business users have been the playground for pure-play UCaaS and CPaaS providers. It is time for mobile operators to accelerate their business communication offerings to the market. An initial focus on the microbusiness segment is a good steppingstone for expansion and growth in the business segment.”

Automated eSIM and Consumer Demand

Complementing the Communication Accelerator, Ericsson also launched a fully automated eSIM offering. eSIM simplifies multi-device connectivity for consumers and enterprises by enabling over-the-air SIM provisioning without physical SIM card swaps. According to an Ericsson ConsumerLab report cited at the time of announcement, 94% of survey respondents indicated willingness to pay extra to connect additional devices to their existing subscription plan, and 86% expressed interest in “try and buy” service offerings.

Together, these additions position Ericsson’s 5G platform as an end-to-end portfolio covering network infrastructure, operational analytics, business communication services, and consumer connectivity — addressing the commercial as well as technical requirements operators face in a 5G transition.

Summary

As 5G deployments mature, orchestration, automation, and cloud-native design will increasingly separate competitive operators from those still managing legacy infrastructure. These additions reflect Ericsson’s strategy of tying together core network modernization with commercial service enablement on a single platform.

Why Security Has Become Non-Negotiable in Software Delivery

Data breaches regularly make front-page news, and the fear of becoming the next headline is now a board-level concern. Organizations must satisfy an expanding landscape of compliance obligations — GDPR at the global level, state-level privacy laws, and sector-specific regulations covering finance, healthcare, energy, and beyond. Security can no longer be bolted on at the end of a release cycle; it has to be woven into every stage of delivery.

Introducing new security tooling and practices into a long-running software development lifecycle is genuinely difficult. Before organizations can integrate security effectively into DevOps, they must first take a clear-eyed look at how they currently design, build, and release software. A controlled reconstruction of the application delivery pipeline — rather than a hasty overlay of security tools — allows teams to modernize thoughtfully, minimize human error, and reduce the gaps where vulnerabilities slip through.

Why Modern Architectures Increase the Attack Surface

Microservices, containers, and cloud-native architectures let teams ship faster and at greater scale than monolithic applications ever allowed. That agility comes with a trade-off: more moving parts mean more potential exposure points.

• Container image provenance: Images pulled from public registries may contain compromised or outdated base layers. Without image scanning and a trusted internal registry, every deployment is a potential risk.
• Open source dependencies: Libraries and packages fetched from public repositories can carry known vulnerabilities (CVEs) or even malicious code. Dependency management and software composition analysis (SCA) are essential controls.
• Secrets in source control: Platforms like GitHub encourage collaboration and code sharing — but teams frequently and accidentally commit credentials, API keys, or certificates to public repositories. Automated secret scanning before code is pushed is a baseline requirement.
• Release frequency: Shipping many small, containerized units frequently means a misconfiguration or vulnerability can reach production faster than in a gated monolithic release process.

These pressures demand a focused, systematic approach to securing every phase of the pipeline — not just a periodic penetration test.

The DevSecOps Framework: People, Processes, and Tools

DevSecOps is built on three interdependent pillars: people, processes, and tools. Get all three right and you create a delivery pipeline where security is a shared responsibility, not a last-minute gate. This article focuses on the first and most foundational pillar — processes. People and tools will be covered in Part 2.

Defining Governance Across the Release Pipeline

Process governance means establishing a formal, documented set of rules that govern how code and configuration move from a developer’s workstation all the way to production. Every promotion step should be intentional and auditable. Key questions to answer include:

• What gates must code pass before it moves from the development environment to staging?
• Who has authority to approve a promotion to production?
• How are rollbacks triggered, and who is accountable for initiating them?
• Which security checks are mandatory versus advisory at each pipeline stage?

Cloud-Native Promotion Paths

In cloud-native environments, the promotion path is typically described in terms of Kubernetes namespaces and clusters rather than bare-metal servers or virtual machines. Each namespace can represent a stage (development, staging, production), with RBAC policies and network policies controlling what can cross those boundaries.

GitOps: Applying DevOps Principles to Operations Artifacts

A natural extension of sound pipeline governance is GitOps — applying version control, access management, and lifecycle processes not just to application code, but to the operational artifacts that define environments: YAML manifests, Helm charts, monitoring scripts, and infrastructure-as-code templates. Treating configuration as code means:

• Every change is tracked, attributed, and reversible.
• Environment drift — where production silently diverges from the desired state — is detected and corrected automatically.
• Compliance is addressed proactively through environmental consistency rather than reactive audits.

Justifying Every Step in the Pipeline

Each stage in a release pipeline should earn its place by mitigating a specific, named risk. Treat undocumented or unexplained steps as technical debt to be resolved. The following examples illustrate the principle of linking pipeline steps directly to risk mitigation:

When every step has a documented rationale, the pipeline becomes self-documenting evidence of due diligence — valuable both internally and during compliance audits.

Making IT Security a First-Class Stakeholder

One of the most important cultural shifts in DevSecOps is giving IT security a seat at the table alongside development, operations, product ownership, and QA — not just as a reviewer of finished work, but as an active participant in designing the pipeline itself.

A product-focused agile team values delivery velocity. Security should not be positioned as an obstacle to that velocity, but as a contributor to sustainable speed. Security professionals who understand the pipeline can design controls that are automated, lightweight, and non-blocking wherever possible — reserving manual gates for genuinely high-risk decisions. This balance between risk mitigation and delivery velocity is the hallmark of a mature DevSecOps culture.

Document Everything — Then Hold It Sacred

Processes only provide value when they are written down, version-controlled, and consistently followed. Documentation serves multiple audiences:

• New team members onboard faster when the pipeline’s rules and rationale are explicit.
• Auditors and compliance officers need evidence that security controls exist and are enforced.
• Incident responders can trace exactly what happened and when during a security event.
• Platform engineers can improve the pipeline confidently without inadvertently removing a control.

Question everything in the current pipeline, document the answers, and treat that documentation as a living artifact — reviewed at regular intervals and updated whenever architecture or risk posture changes.

Key Takeaways

• Audit your existing release pipeline before adding security tooling — understand what you have before you change it.
• Define formal governance: document who approves each promotion step and what automated checks are mandatory.
• Adopt GitOps practices to apply version control and access management to operational configuration, not just application code.
• Justify every pipeline stage by linking it explicitly to a security or quality risk it mitigates.
• Include IT security as a co-designer of the pipeline, not an external reviewer of its output.
• Document all processes and treat that documentation with the same rigor as production code.

Process governance is the foundation on which effective DevSecOps is built. In Part 2, we’ll explore how people and tools complete the picture — covering team structures, shared ownership of security, and the tooling that automates enforcement across the pipeline.

APIs as the Foundation of Cloud-Native Businesses

APIs have become the essential building blocks of modern digital businesses. As organizations grow their reliance on microservices, containers, and cloud infrastructure, the demands placed on API management have evolved significantly. DevOps teams now need API management solutions that address the following challenges:

• Creating, publishing, and monetizing APIs and API products at scale.
• Maximizing application adoption and reuse across internal and external APIs.
• Enforcing consistent API security policies.
• Supporting cloud environments built on Kubernetes, microservices, service meshes, and CI/CD pipelines.

WSO2 API Manager 3.0 addresses these demands by introducing native Kubernetes support through a Kubernetes Operator and an API Microgateway — two capabilities that treat APIs as first-class citizens in a Kubernetes environment.

Kubernetes Operators: Extending Automation Beyond Core Kubernetes

Kubernetes is designed around automation, but as application complexity grows, so does the operational burden on DevOps teams. Native Kubernetes constructs are powerful but limited to general-purpose workload management. Kubernetes Operators extend that automation by combining two primitives:

• Custom Resources (CRDs): Define new API objects that represent domain-specific concepts — in this case, APIs, security policies, and rate-limiting rules.
• Custom Controllers: Watch those custom resources and reconcile the actual cluster state with the desired state, automating tasks that would otherwise require manual intervention.

This extensible architecture allows teams to encode operational knowledge — such as how to deploy an API microgateway — into the cluster itself, without modifying any core Kubernetes code. The result is repeatable, auditable deployments that reduce human error.

API Microgateway: Decentralized Policy Enforcement for Microservices

In a microservices architecture, applications are decomposed into small, independently deployable services organized around business capabilities. This model allows smaller, focused teams to build, test, and deploy services autonomously — but it also means API governance must be applied at the service boundary level, not just at a central gateway.

The WSO2 API Microgateway treats an OpenAPI definition as the single source of truth for each API. The OpenAPI specification contains all required information about an API — its paths, parameters, authentication requirements, and rate limits. By supplying this definition to the WSO2 API Microgateway toolkit, teams can generate a lightweight, purpose-built microgateway for that specific API, enforcing governance policies at the point of ingress.

WSO2 API Operator for Kubernetes: What It Solves

API developers typically want to focus on their domain — defining backend services, setting security policies, and configuring rate limits — not on Kubernetes internals such as pod scheduling or service discovery. The WSO2 API Operator bridges this gap by abstracting Kubernetes complexity while delivering the capabilities API teams actually need:

• Publishing APIs to a developer portal to build an API marketplace.
• Protecting and monetizing APIs through policy enforcement.
• Monitoring and analyzing API usage in real time.
• Generating business insights from API traffic data.

By providing an OpenAPI definition to the apictl (API Controller) command-line toolkit, the API Operator automatically deploys an API microgateway with the appropriate policy enforcement configured — no manual Kubernetes YAML authoring required for API-specific concerns.

Custom Resource Definitions Introduced by the API Operator

The WSO2 API Operator for Kubernetes introduces four Custom Resource Definitions (CRDs) that map directly to API management concepts:

TargetEndpoint Deployment Patterns

The TargetEndpoint CRD supports three deployment patterns, giving teams flexibility depending on their architecture:

• Shared mode: Multiple APIs share a single microgateway instance, suitable for lower traffic or development environments.
• Private-jet mode: Each API gets its own dedicated microgateway instance, providing strong isolation for high-traffic or sensitive APIs.
• Sidecar mode: The microgateway runs in the same Kubernetes pod as the backend service, eliminating network hops between the gateway and the service.

If the backend service is already running and only needs to be exposed via a microgateway, the target URL can be defined directly in the Swagger/OpenAPI file. If the backend service is not yet running but will be deployed in the same Kubernetes cluster, the TargetEndpoint CRD can reference a Docker image, and the API Operator will automatically spin up the corresponding Kubernetes Deployment for that backend alongside the microgateway.

How the API Controller Automates Microgateway Builds

When a user applies an API custom resource to the cluster, the following sequence occurs automatically:

1. The custom API Controller reads the OpenAPI definition from the referenced ConfigMap.
2. It creates a Kaniko job — Kaniko is an open-source tool for building container images from a Dockerfile inside a container or Kubernetes cluster, without requiring a Docker daemon. This job uses a multi-step Dockerfile that includes the pre-built API Microgateway toolkit base image.
3. The Microgateway toolkit processes the OpenAPI definition and generates the microgateway runtime configuration tailored to that API.
4. Kaniko builds a new, API-specific microgateway Docker image and pushes it to the configured container registry.
5. The API Controller then creates the required Kubernetes Deployments and Services for both the microgateway and backend services, based on the selected deployment mode.

This pipeline encodes deployment best practices into the operator itself, freeing DevOps engineers from manually orchestrating each step and reducing the surface area for configuration errors.

Installation and Getting Started

Installing the WSO2 API Manager 3.0 Kubernetes Operator is designed to be straightforward. The primary installation path involves applying the operator manifests to an existing Kubernetes cluster using kubectl. From there, teams download and configure apictl, the API Controller CLI, on their local machines to interact with the API management layer.

Full installation instructions, manifest files, and usage examples are available in the WSO2 Kubernetes API Operator Git repository. Always verify the current installation steps against the official repository, as procedures may have been updated since this article was written.

Key Takeaways

Kubernetes is rapidly becoming the de facto orchestration standard for cloud-native workloads. Managing APIs in this environment requires tooling that integrates natively with Kubernetes primitives rather than sitting alongside them as an afterthought. The WSO2 API Manager 3.0 approach — using a Kubernetes Operator with domain-specific CRDs — achieves this integration by:

• Giving API developers a familiar, API-centric interface rather than exposing raw Kubernetes complexity.
• Automating microgateway image builds and deployments through the Kaniko-based build pipeline.
• Supporting flexible deployment patterns (shared, private-jet, sidecar) to match diverse architectural requirements.
• Treating OpenAPI definitions as the authoritative source of truth for policy enforcement.

The net result is higher productivity for developers, DevOps engineers, and cloud administrators when building, deploying, and governing APIs at scale in a Kubernetes-native environment.

Why Kubernetes Has Become the Enterprise Standard for Container Orchestration

In the relatively short time since its public release in 2014, Kubernetes has established itself as the de facto container orchestration platform for enterprise environments. CIOs across industries recognise it as a top-tier container management system, and its adoption continues to accelerate. The job market reflects this: a LinkedIn search cited at the time of writing found over 16,000 open Kubernetes roles — a figure that has only grown since.

This growth is not accidental. Kubernetes addresses real, recurring problems that DevOps teams face when running containerised workloads at scale: automated scheduling, self-healing deployments, horizontal scaling, and consistent behaviour across heterogeneous infrastructure. Understanding why enterprises are standardising on Kubernetes requires looking at three distinct advantages it offers over alternative container management approaches.

1. Innovation Driven by a Mature Open Source Community

Kubernetes began as an internal Google project — drawing on lessons from Google’s internal Borg and Omega cluster management systems — before being open-sourced in 2014. From the outset, Google’s engineering credibility gave the project legitimacy, and it rapidly attracted thousands of contributors on GitHub.

Today Kubernetes is governed by the Cloud Native Computing Foundation (CNCF), a vendor-neutral home that helps prevent any single company from controlling the project’s direction or creating vendor lock-in. Key contributors include Amazon Web Services, Google, Microsoft, Red Hat, SUSE, and SAP, among many others.

The practical result of this community scale is rapid, well-tested innovation. Features such as custom resource definitions (CRDs), the operator pattern, and sophisticated network policies have all emerged from community collaboration. The annual KubeCon + CloudNativeCon conferences — which have drawn tens of thousands of attendees — demonstrate both the breadth of the ecosystem and the speed at which it evolves.

For enterprises, backing Kubernetes means backing a platform with a near-zero risk of abandonment and a rich ecosystem of complementary tooling — from service meshes like Istio and Linkerd, to observability stacks like Prometheus and Grafana, to GitOps tools like Argo CD and Flux.

2. Deployment Agility Across Hybrid and Multi-Cloud Environments

Most enterprises today operate a hybrid IT model: some workloads run on-premises, others in public cloud, and many span both. Moving workloads between environments — or running them consistently across environments — has historically been painful. Kubernetes addresses this directly.

Because Kubernetes abstracts away the underlying infrastructure, the same manifests and Helm charts that deploy an application to an on-premises cluster can, with appropriate configuration, deploy to a managed Kubernetes service such as Amazon EKS, Google GKE, or Azure AKS. DevOps teams are not forced to rewrite deployment logic for each target environment.

This infrastructure-agnostic design has two important consequences:

• Portability: Applications packaged in containers and described by Kubernetes manifests are portable across any conformant Kubernetes cluster, reducing dependency on a specific cloud provider’s proprietary services.
• Workload diversity: Kubernetes handles both legacy monolithic applications that have been containerised and modern cloud-native microservices. A single cluster can run both simultaneously, giving platform teams a single operational model to manage.

Kubernetes also integrates well with Platform-as-a-Service layers such as Cloud Foundry, and with infrastructure provisioning tools such as Terraform and Pulumi, giving teams the flexibility of IaaS with the developer ergonomics of PaaS.

3. Automating and Accelerating the DevOps Lifecycle

One of Kubernetes’ most significant contributions to DevOps is automation of the operational work that previously consumed engineering time. Without orchestration, teams manually handle tasks such as:

• Deciding which host should run a given container
• Restarting failed containers
• Scaling out application replicas under load
• Rolling out new versions with zero downtime
• Rolling back failed deployments

Kubernetes automates all of these through its core primitives: Deployments manage rollout strategy and replica counts; HorizontalPodAutoscalers react to CPU or custom metrics; liveness and readiness probes trigger self-healing; and Services provide stable network endpoints regardless of which pod instances are currently running.

This automation allows developers to focus on writing application code rather than managing infrastructure operations. CI/CD pipelines can push changes directly to a Kubernetes cluster and rely on the platform to handle safe rollout and rollback without human intervention.

Autoscaling in Practice: The Spotify Example

A frequently cited example of Kubernetes-driven scalability in the enterprise is Spotify. Facing the challenge of supporting over 200 million monthly active users, Spotify adopted Kubernetes to replace manual capacity provisioning. By leveraging Kubernetes’ autoscaling capabilities, their engineering teams could shift attention from reactive infrastructure management to feature delivery. The reported outcomes included reduced operational costs and faster iteration cycles.

This pattern — freeing engineering capacity by automating infrastructure concerns — is consistent across large-scale Kubernetes adoptions and represents the core DevOps value proposition of the platform.

Key Kubernetes Concepts Every DevOps Engineer Should Know

To get full value from Kubernetes in an enterprise context, DevOps teams should be familiar with the following foundational concepts:

• Pods: The smallest deployable unit in Kubernetes — one or more tightly coupled containers that share a network namespace and storage.
• Deployments: Declarative descriptions of the desired state for a set of pods, including replica count and update strategy.
• Services: Stable virtual network endpoints that route traffic to the appropriate pods, regardless of individual pod lifecycles.
• Namespaces: Logical partitions within a cluster, useful for separating environments (dev, staging, production) or tenants.
• ConfigMaps and Secrets: Mechanisms for externalising application configuration and sensitive credentials from container images.
• Helm: The de facto package manager for Kubernetes, enabling reusable, parameterised application definitions.
• Operators: Custom controllers that extend Kubernetes to manage complex, stateful applications using domain-specific operational knowledge.

Is Kubernetes Right for Every Organisation?

Kubernetes is powerful, but it carries real operational complexity. Smaller teams or organisations with simple workloads may find that a managed container service — such as AWS Fargate, Google Cloud Run, or Azure Container Apps — provides sufficient capability with lower overhead. Kubernetes delivers the most value when:

• Workloads are sufficiently numerous and varied to justify cluster overhead
• Teams have or are building platform engineering capability
• Portability across clouds or on-premises environments is a strategic requirement
• The organisation needs fine-grained control over scheduling, networking, or resource isolation

For enterprises that meet these criteria, the investment in Kubernetes pays dividends through faster delivery cycles, more resilient applications, and a consistent operational model across heterogeneous infrastructure.

Conclusion

Kubernetes has earned its position as the enterprise container orchestration standard through a combination of genuine technical capability, a large and healthy open source community, and broad industry support. Its ability to automate complex operational tasks, run consistently across hybrid environments, and integrate with the wider cloud-native ecosystem makes it a foundational technology for DevOps organisations pursuing faster, more reliable software delivery.

Enterprises that have not yet standardised on Kubernetes should evaluate it seriously — not because it is fashionable, but because the operational and developer-productivity benefits are well-evidenced at scale.