SAN MATEO, Calif.–(BUSINESS WIRE)–Armory, the open source continuous delivery software company, announced significant growth of its easy-to-use Spinnaker deployments, as the overall user community grew, evidenced in part by the 100% increase in attendees at the upcoming Spinnaker Summit. Spinnaker is the open source, multi-cloud continuous delivery (CD) platform for releasing software changes with high velocity and confidence.

Armory will participate at Spinnaker Summit June 22-24 with a number of sessions discussing the value of making Spinnaker more accessible and easier to use. Armory will take part in a keynote panel session moderated by Kelsey Hightower called A Deep Dive into the Benefits of CD. The Birds of a Feather session titled Continuous Delivery: Spinnaker at Scale includes speakers from Armory, Autodesk, AWS, Cox Automotive, Netflix, and Salesforce.

“Everything we do revolves around making Spinnaker more accessible and easier to use so that engineering teams are able to ship better code faster,” said Daniel R. Odio, co-founder and CEO, Armory. “And that’s achieved by working closely with partners like AWS and customers like Autodesk, who are leading the way by empowering developers and delivering code as efficiently as possible.”

Armory Frees Engineers to Focus on Delivering Value

One way Armory is making Spinnaker more accessible is through its Managed Services Offering, providing expert engineers to manage Spinnaker installations with 24/7 support and guaranteed 99.95% uptime—including break-fix, debugging and troubleshooting. Not only does this offering remove the management overhead of Spinnaker, customers typically see at least a three-times cost savings over hiring an internal team to install, configure, manage and provide 24/7 support of Spinnaker.

“Armory Managed Services eases our life with their expertise—from installation to service management—allowing us to focus on building CI/CD pipelines rather than troubleshooting Spinnaker,” said Leon Xiao, site reliability engineering manager, eHealth.

Scale Spinnaker Deployments to Kubernetes

Armory’s Agent for Kubernetes is a lightweight, scalable service that monitors each Kubernetes cluster and streams changes back to Spinnaker’s Clouddriver service, solving the following problems:

Latency issues that arise when caching large Kubernetes resources in Spinnaker;
Security and access issues that exist when Kubernetes clusters are managed by a central resource;
Bottleneck issues that surface when new Kubernetes clusters require onboarding by a central resource; and
Complexity issues stemming from supporting thousands of Kubernetes clusters that have tens of thousands of objects and multiple edge cases.
Armory and AWS Extend Use of Spinnaker

In collaboration with AWS, Armory recently added blue/green and canary support into Lambda deployments within Spinnaker. Learn more about the Lambda integration and Autodesk’s success with Armory and AWS here.

Armory will also soon be releasing an AWS Quick Start to make it simple to deploy a production-grade instance of Armory on AWS EKS. To learn more, AWS has a workshop scheduled on June 24 about continuous deployment for cloud-native applications that includes hands-on labs from Armory and others.

Simplified Spinnaker Installation

Armory Minnaker is a virtual machine leveraging K3s and the Armory Operator to enable software deployments in 10 minutes instead of 10 days. Armory Minnaker is a full Spinnaker installation packaged inside a virtual machine running the certified K3s Kubernetes distribution. Minnaker automatically handles authentication, security such as SSL/TLS, namespaces, custom resources in Kubernetes (CRD) and more.

Additionally, Armory has created pre-built DevOps pipelines, along with a self-guided tour of the platform to acquaint new users. All of this enables integration of Armory into DevOps toolchains, such as continuous integration (CI) systems, Git repositories, security tools, and targets for software distribution.

Spinnaker

Spinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence. Created at Netflix, it has been battle-tested in production by hundreds of teams over millions of deployments. It combines a powerful and flexible pipeline management system with integrations to the major cloud providers. Learn more at www.spinnaker.io.

Armory

Armory is the company driving modern digital transformation with its enterprise version of Spinnaker. Armory’s scalable, flexible, and secure platform automates software delivery, enabling software teams to ship better software, faster. The core of Armory’s platform is powered by Spinnaker, the continuous delivery platform developed and open-sourced by Netflix and Google to help companies quickly and safely deploy software into multiple clouds. Armory builds on open-source Spinnaker’s foundation, adding proprietary features for bolstered enterprise scale, along with 24×7 enterprise-grade support. Armory’s platform is trusted by dozens of Global 2000 customers in financial services, technology, retail, healthcare and entertainment. Armory is also a proud sponsor of, and contributor to, the Continuous Delivery Foundation (CDF), the vendor-neutral home of the fastest-growing projects for continuous delivery.

As enterprises ramp up their adoption of modern architectures that embrace microservices, containers and Kubernetes, application deployment strategies are being re-evaluated. Organizations operating and serving customers globally or regionally need to think about how best to make their applications available, responsive and high-performing no matter where the end user (or end device) lives.

But in an environment where enterprises operate both on-premises and in the cloud (and perhaps multiple clouds), operating Kubernetes clusters across multiple environments brings about a new set of deployment challenges. Consider the following:

A cloud gaming company develops and operates an interactive online service for customers in Asia. One cloud provider is selected with multiple regions across Asia and the provider’s managed Kubernetes service is being leveraged. Multiple Kubernetes clusters actually run in several regions to best serve its end users.

The company decides to expand its operations to Europe. The company’s IT operations team needs to evaluate European cloud providers since their Asian cloud provider doesn’t serve Europe. To complicate matters, certain European countries have geo-specific privacy and compliance laws that mandate the company store customer data in the country of residence. The company now finds itself needing several different public cloud providers. Because each cloud provider tends to offer a homegrown managed Kubernetes service, the company has to unify and simplify its Kubernetes deployment strategy to deal with multiple clouds and multiple distributions.

The company’s expansion to Europe is paying off and it has decided to acquire a rival gaming company. The acquired company operates its gaming platform in four data centers around the world and also leverages several different public cloud providers. The acquired company has decided to spin up upstream Kubernetes in all locations and has invested in an internal platform to manage and operate Kubernetes everywhere. How will the merged company manage and operate Kubernetes across clouds and data centers, including multiple Kubernetes distributions, going forward?

Challenges of Managing Diverse Clusters, Environments
Kubernetes cluster management is complex for a single cluster. Extended to multiple clusters and multiple distros, effective management may be unattainable for all but the most sophisticated SRE/Ops teams with deep expertise. To unify management and operations across clouds and distro, a Kubernetes management platform is required that should provide:

Complete visibility and governance across a company’s fleet of Kubernetes clusters, regardless of distribution. The IT or SRE/Ops team must be able to quickly figure out where a given service is running at present, which app is experiencing restarts in a given cluster, which apps have been upgraded across the fleet in the last month and much more.
On-demand cluster bring-up and customization in any cloud environment or on-premises. In addition to simply bringing up Kubernetes, SRE/Ops teams are responsible for ensuring that a given cluster is customized appropriately and conforms to the business’ security/compliance requirements and can be easily upgraded as needed.
Continuous deployment capabilities are required across the entire cluster fleet without requiring multiple deployment tools. SRE/Ops teams need access to deployment tools that work across any cluster type, in any environment, and do not require scripting/coding investments that traditionally fall on DevOps teams.
While it is possible to internally build a platform that provides these functions, this effort requires stitching together dozens of open source tools. It also requires hiring and training hard-to-find people to build and debug the platform, and then ongoing maintenance and upgrades as clusters morph and expand. The process can take multiple quarters and require an ongoing investment in people, resources and infrastructure. Still, many companies initially go down this road, only to get mired in the complexity after several months of effort.

Turnkey Solutions for Kubernetes
Is there an easier, faster and more cost-effective way? Turnkey management platforms are emerging as viable alternatives to building in-house Kubernetes platforms. These platforms can be implemented quickly and bring up enterprise-grade, production-ready clusters in minutes. Beyond saving time and resources, these platforms provide:

Global, cross-cloud, single-pane-of-glass management for centralized provisioning, monitoring and problem resolution.
Cluster blueprinting/templating enables enterprises to seamlessly add their own customized clusterwide services to create a reusable blueprint for easy replication in multiple environments.
Out-of-the-box enterprise tntegrations for registry, logging, monitoring, security, etc., to reduce development and ongoing maintenance costs.
Containerized application lifecycle management to automate and simplify the deployment, scaling, upgrading and operation of applications across multi-region, multi-cloud and hybrid environments.
When compared with roll-your-own solutions, turnkey Kubernetes management platforms are less expensive to implement, far faster to deploy and require much lower administrative costs. So when thinking about how to manage a growing collection of multi-cloud, multi-distribution clusters, DevOps and SRE/Ops teams should take a look at these platforms as an alternative to the pain of building and maintaining one on their own.

NEW YORK, Oct. 6, 2020 /PRNewswire/ — IntSights, the threat intelligence company focused on enabling enterprises to Defend Forward™, announced today the availability of the new certified IntSights Application for Splunk. This partnership between the market’s only all-in-one External Threat Protection Suite, IntSights, and Splunk, provider of the Data-to-Everything® Platform, empowers joint customers to seamlessly access enterprise-specific threat intelligence from IntSights directly within existing Splunk deployments.

Effective cyber defense extends beyond the corporate perimeter. Understanding how, when, and where attacks are likely to strike is critical. When organizations augment SIEM solutions with integrated threat intelligence, they can proactively defend and neutralize threats at the source.

The new IntSights App for Splunk introduces a revolutionary approach for connecting threat intelligence from multiple sources across the clear, deep, and dark web with a customer’s Splunk environment. The IntSights app is a unique bidirectional integration that correlates, enriches, and manages organization-specific vulnerabilities, and offers the ability to easily conduct comprehensive IntSights-driven investigations… all within Splunk.

“With this robust app, security teams can directly access IntSights-enriched IOCs from within their Splunk environment. This gives those on the front line vital real-time context for informed and prioritized risk management,” noted Yaron Paryanty, VP of Product Management at IntSights.

IntSights for Splunk enables SOC teams to:

Expand real-time visibility of threat actors and malware targeting the enterprise’s digital assets
Generate automatic alerts for relevant active indicators in an organization’s network environment
Seamlessly conduct advanced IntSights investigations from within the app
Accelerate informed decision-making and automate incident response
Instantly identify and rapidly remediate critical threats before business impact

Stay tuned for additional enhancements to the IntSights App for Splunk. In the near future, mutual customers will be able to continuously access IntSights organization-specific threat alerts and risk-scored CVEs from within their Splunk environments.

About IntSights

IntSights is revolutionizing cybersecurity operations with the industry’s only all-in-one external threat protection platform designed to neutralize cyberattacks outside the wire. Our unique cyber reconnaissance capabilities enable continuous monitoring of an enterprise’s external digital profile across the clear, deep, and dark web to identify emerging threats and orchestrate proactive response. Tailored threat intelligence that seamlessly integrates with security infrastructure for dynamic defense has made IntSights one of the fastest-growing cybersecurity companies in the world. IntSights has offices in Amsterdam, Boston, Dallas, New York, Singapore, Tel Aviv, and Tokyo. To learn more

DevOps Is No Longer Just for Application Code

For most of its history, DevOps has been synonymous with application delivery — continuous integration pipelines, automated testing, and frequent releases of application code. Databases, by contrast, were often treated as static infrastructure: carefully managed, rarely automated, and firmly in the hands of DBAs working in isolation from development teams.

That picture is changing. According to a Redgate Software survey of roughly 2,000 developers, database changes are increasingly being managed with the same principles applied to application code: version control, automated testing, continuous delivery, and collaborative ownership.

“Databases are recognized as another code deployment which can and should be managed, tested, automated, and improved with the same robust, reliable methodologies applied to application code.”

— Kendra Little, DevOps Advocate, Redgate Software

Key Findings: Adoption Is Rising, but Unevenly

The survey paints a picture of an industry in transition. DevOps adoption for databases is clearly growing, but it remains inconsistent — particularly around foundational practices like version control.

Adoption and Deployment Frequency

• 68% of respondents are in some phase of DevOps adoption across their projects.
• 18% say they have adopted DevOps “across all projects,” up from 15% the previous year.
• 46% are performing some form of database deployment automation.
• 49% report needing to deploy database changes weekly or on-demand — up significantly from 37% in a comparable 2017 survey.
• More than 60% of managers in larger enterprises believe a full transition from traditional to automated database deployments can be achieved within a year.

The Version Control Gap

One of the more striking findings is how many teams are deploying frequently without the safety net of version control. Of those deploying database changes weekly or more often, only 47% report using version control for their database schemas and migration scripts. That means a substantial share of teams are making direct changes to production databases without a reliable audit trail or rollback mechanism — a practice that directly correlates with defects requiring hotfixes, according to the survey.

Why Databases Present Unique DevOps Challenges

Applying DevOps to databases is not simply a matter of bolting a pipeline onto an existing schema. As Kellyn Pot’Vin-Gorman, co-author of the Redgate report, explains, databases introduce a set of concerns that don’t arise with stateless application code:

“Databases, which were formerly seen as configurable repositories much like file shares, are now seen as stateful data, controlled by code. However, databases present unique challenges in using change methodology due to the very nature and value of data. In particular, data loss can put the continued existence of the company at risk. This results in database deployments requiring more care than standard change management to ensure the code that’s deployed and data quality aren’t impacted. The natural state of a database environment is growth, so as the surface area naturally spreads, the challenge of change management and releases becomes more daunting.”

— Kellyn Pot’Vin-Gorman, Report Co-Author, Redgate Software

The core challenge is statefulness. Unlike application binaries that can be replaced atomically, a database holds the organisation’s actual data. A bad migration can corrupt or destroy records that have real business value — and unlike a failed application deployment, a failed database migration may not be trivially reversible.

The Cost of Staying Siloed

The survey asked respondents to identify the biggest drawbacks of keeping database development separate from application development pipelines. The top responses were:

• Slow development and release cycles — cited by 24% of respondents.
• Inability to respond quickly to changing business requirements — cited by 21%.
• Increased risk of failed deployments or downtime — cited by 18%.

These are not abstract concerns. In a competitive environment where applications ship continuously, a database team on a quarterly release cycle becomes a bottleneck that slows the entire organisation.

Developers Own Database Work — Whether They’re Ready or Not

One clear finding is that database responsibility has shifted significantly toward developers. 78% of survey respondents say they are responsible for both application and database deployment. This reflects a broader trend in which full-stack ownership — including the data layer — is becoming the norm rather than the exception.

This shift creates both opportunity and risk. Developers who own the full stack can ship features end-to-end without waiting for handoffs, but they also need the tooling, processes, and training to handle database changes safely. The version control gap highlighted above suggests that tooling and process adoption has not fully kept pace with the expansion of responsibility.

DevOps Improves Developer–DBA Collaboration

One of the more encouraging findings is the impact DevOps adoption has on the relationship between developers and database administrators. The survey found a significant difference in collaboration depending on whether DevOps practices were in place:

• 82% of developers in DevOps settings report that they and DBAs work together as a team.
• In non-DevOps settings, that figure drops to 58%.

This is consistent with the broader DevOps principle that organisational silos — not just technical ones — are a primary source of delivery friction. When database and application teams operate in a shared pipeline with shared visibility, collaboration becomes a natural byproduct of the workflow.

Measurable Quality Benefits for Teams That Go All In

Teams that have fully embraced database DevOps practices report better outcomes than those still in transition. According to the survey:

• Respondents who reported that all or nearly all their database deployments take place with the system online also reported lower lead times for changes and lower defect rates.
• 37% of those who have adopted DevOps across all projects report that 1% or fewer of their deployments introduce code defects requiring hotfixes.
• That compares to 30% for all other groups — a meaningful gap that suggests full adoption, not partial adoption, drives quality improvements.

What DataOps Adds to the Picture

It is worth distinguishing database DevOps from the related discipline of DataOps. While database DevOps focuses on applying CI/CD and change-management practices to database schema and code changes, DataOps is broader: it applies similar automation and quality principles to the flow of data itself through an organisation — from ingestion and transformation pipelines to analytics and reporting. Both disciplines are growing, and in mature organisations they increasingly overlap.

Practical Takeaways for Engineering Teams

Based on the survey findings, teams looking to improve their database delivery practices should prioritise the following:

1. Put your database schemas and migration scripts under version control. This is the minimum baseline for repeatable, auditable deployments. Given that nearly half of frequent deployers are skipping this step, it represents the single biggest gap in current practice.
2. Automate database deployments as part of your CI/CD pipeline. Manual deployments are slower and more error-prone. Treating schema changes as code — validated in a pipeline before reaching production — reduces defect rates.
3. Integrate DBA expertise into the development workflow. Rather than a handoff model, embed DBA knowledge into design and code review. The data shows that DevOps teams do this far more effectively than non-DevOps teams.
4. Plan for zero-downtime migrations. The survey links online deployments to better lead times and lower defect rates. Techniques such as expand-contract migrations, backward-compatible schema changes, and blue-green database deployments make this achievable.
5. Test database changes as rigorously as application code. This includes unit tests for stored procedures, integration tests against a representative data set, and automated rollback verification.

Conclusion

The Redgate survey is a useful data point in a broader shift: databases are no longer exempt from the engineering discipline applied to the rest of the software stack. As deployment frequency increases and developer ownership of the data layer grows, the teams that treat database changes as first-class code — versioned, tested, automated, and collaboratively owned — are already seeing measurable advantages in release quality and speed. The version control and automation gaps that remain represent both a risk for teams that haven’t closed them and an opportunity for those ready to do so.

Why Self-Managed Kubernetes Is Hard

Building a Kubernetes cluster in-house is achievable, but the hidden costs accumulate quickly:

• Domain expertise required. Configuring the control plane, networking (CNI), storage (CSI), RBAC, and admission controllers correctly demands specialist knowledge that most teams do not have on day one.
• Operational overhead never stops. Cluster upgrades, certificate rotation, node patching, and etcd backups are recurring, non-negotiable tasks.
• Monitoring is a project in itself. A production-grade observability stack — metrics, logs, alerts, dashboards — takes significant effort to design and maintain.
• Errors are expensive. A misconfiguration introduced during setup may not surface until workloads reach production, at which point a rework can delay release cycles significantly.

A managed Kubernetes service hands off these responsibilities to a provider whose core competency is exactly that, leaving your team free to concentrate on application development.

What to Look for in a Managed Kubernetes Service

Before evaluating specific vendors, agree on the capabilities your organisation actually needs. Use the following checklist as a starting point:

• Control-plane management. The provider should fully own deployment, scaling, and availability of the Kubernetes control plane (API server, scheduler, controller manager, etcd).
• Automated upgrades. Kubernetes releases minor versions roughly three times per year. Look for one-click or fully automated upgrade paths that minimise or eliminate service interruption.
• Security patching. CVEs in the Kubernetes core, container runtime, or underlying OS must be patched rapidly and applied across all clusters without manual intervention.
• Multi-environment support. If your organisation runs workloads on multiple clouds or on-premises, the service should offer a consistent management plane across all of them.
• Integrated observability. Built-in metrics collection, log aggregation, and alerting reduce the time between a problem occurring and an engineer acting on it.
• Self-healing. Automatic detection and remediation of common cluster issues — such as failed nodes or degraded components — reduces on-call burden.
• Day-2 operations focus. Onboarding is easy; long-term operations are hard. Prioritise vendors that have invested heavily in Day-2 tooling: backup, disaster recovery, and capacity management.
• API compatibility. The service should expose standard Kubernetes APIs so that existing tooling (Helm, kubectl, Argo CD, Flux) works without modification.

Leading Managed Kubernetes Providers

The following providers are notable options in the managed Kubernetes market. Each takes a somewhat different approach to the problem of simplifying cluster operations.

Platform9

Platform9 focuses on giving organisations a unified management plane that works across public clouds and on-premises infrastructure simultaneously. Supported targets include AWS, Azure, Google Cloud, vSphere, Nutanix AHV, and bare metal. Its value proposition centres on automated Day-2 operations: one-click upgrades without service interruption, instant security patches applied across all clusters, and remote monitoring with automatic remediation. Platform9 claims five-minute deployment times and the ability to import existing clusters, after which it begins discovering and managing the infrastructure automatically. It also continues to monitor clusters even when they are temporarily disconnected from the management plane.

Giant Swarm

Giant Swarm delivers fully managed Kubernetes clusters built on standard upstream Kubernetes APIs, which means workloads are portable and tooling integrations do not require vendor-specific adaptations. The platform is designed to be cloud-agnostic and supports incremental, frequent deployments — teams can push updates multiple times per day. Giant Swarm emphasises continuous upgrades and rapid troubleshooting to maintain high uptime. Notable customers cited by the company include Adidas and Vodafone.

Rancher (SUSE)

Rancher, now part of SUSE, is one of the most widely used open-source Kubernetes management platforms. Its container-based installer, Rancher Kubernetes Engine (RKE), supports both cloud and on-premises deployments. Rancher allows teams to manage multiple clusters through a single interface regardless of where those clusters run, and it supports importing clusters created by other managed services. Rancher ships with Prometheus and Grafana pre-integrated, providing immediate visibility into cluster metrics without additional setup. It is particularly popular with teams that want flexibility without being locked into a single cloud provider.

VMware Tanzu (formerly Pivotal Container Service / PKS)

Originally developed as Pivotal Container Service (PKS), this offering is now part of VMware’s Tanzu portfolio. It is designed with Day-2 operations as a primary concern, supporting workloads across both private and public clouds. Key capabilities include close cluster monitoring with regular health checks, network segmentation to isolate containers within a single cluster, and programmatic management of virtual networks. Automated patching is applied whenever new vulnerabilities are identified.

Note: Since the original article was written, VMware was acquired by Broadcom. The Tanzu product portfolio has undergone changes; verify current product names and availability directly with Broadcom/VMware before making purchasing decisions.

Kublr

Kublr is a managed Kubernetes platform that emphasises operational automation and observability out of the box. Clusters can be deployed via a UI or API, and each new cluster is automatically connected to log collection and monitoring at creation time. Kublr uses Prometheus and Elasticsearch for metric and log collection, and Grafana or Kibana for visualisation. Its Alert Manager integrates with email, Slack, and PagerDuty to ensure alerts are routed to the right responders. A lightweight agent installed on each cluster handles configuration, continuous health monitoring, self-healing, and self-orchestration, and is designed to ensure cluster portability across environments.

Cloud-Provider Managed Kubernetes: The Hyperscaler Option

The vendors above are independent platforms, but the major cloud providers also offer managed Kubernetes services that are worth considering if your workloads already live within a single cloud ecosystem:

• Amazon Elastic Kubernetes Service (EKS) — deep AWS integration, broad tooling support.
• Google Kubernetes Engine (GKE) — Kubernetes originated at Google; GKE typically tracks upstream releases closely and offers Autopilot mode for fully managed node infrastructure.
• Azure Kubernetes Service (AKS) — tight integration with Azure Active Directory, Azure DevOps, and other Microsoft services.

The trade-off with hyperscaler offerings is that they work best when you are committed to a single cloud. Multi-cloud or hybrid deployments typically benefit from one of the independent platforms listed in the previous section.

How to Choose: A Decision Framework

Use the following questions to narrow down your options:

1. Where do your workloads run today? If you are fully committed to one cloud, a native service such as GKE, EKS, or AKS reduces friction. If you need multi-cloud or on-premises support, look at Platform9, Rancher, or Kublr.
2. How much Kubernetes expertise does your team have? Lower-expertise teams benefit from platforms with strong defaults, automated upgrades, and proactive monitoring rather than raw flexibility.
3. What are your compliance and security requirements? Understand how each provider handles security patching SLAs, audit logging, and network policy enforcement before signing a contract.
4. Do you need to import existing clusters? Several providers support bringing existing clusters under management. Confirm this capability if you are migrating rather than starting fresh.
5. What is your tolerance for vendor lock-in? Platforms built on standard upstream Kubernetes APIs and CNCF-conformant distributions are easier to migrate away from if your needs change.
6. What is the total cost of ownership? Compare not just licensing fees, but the engineering hours saved on operations, the reduced risk of production incidents, and the faster time-to-delivery for your developers.

Summary

Managed Kubernetes services are not a shortcut around understanding Kubernetes — you still need to make informed decisions about architecture, security, and workload design. What they do eliminate is the operational grind of keeping clusters healthy, up-to-date, and monitored around the clock. For most engineering organisations, that trade-off is well worth making. The right choice depends on your infrastructure footprint, team skills, compliance requirements, and budget. Evaluate providers against those criteria rather than against feature lists alone, and you will be far more likely to pick a service that remains a good fit as your Kubernetes usage matures.

Kubernetes as Enterprise Infrastructure Backbone

Over the past several years, Kubernetes has matured from an experimental container orchestrator into the de facto foundation of modern enterprise infrastructure. It underpins major hybrid cloud platforms and has become one of the most widely adopted infrastructure technologies in large organisations. Despite this momentum, two structural challenges continue to slow enterprise adoption and frustrate day-to-day operations:

• A lack of clear separation between the developer experience and the operator experience.
• A lack of application context — the platform’s inability to treat a collection of related resources as a single logical application.

Challenge 1: The Blurred Line Between Dev and Ops

Kubernetes was architected to solve some of the hardest problems in scalable infrastructure. Built on containers, it delivers excellent workload scalability and reliability. However, its design philosophy is rooted in the concerns of system administrators and infrastructure operators — those who manage compute, network, and storage resources.

In traditional IaaS and PaaS environments, there is a reasonably clean boundary between developers and operators. Developers own the application lifecycle — they package, deploy, and iterate on code. Operators own the stability of the underlying platform. Each role has distinct responsibilities, tooling, and success metrics.

Kubernetes collapses that boundary. Regardless of whether a person’s title is Developer or Platform Engineer, anyone working with Kubernetes must develop a comparable depth of understanding of cluster concepts: packaging workloads, configuring resource requests and limits, defining health probes, managing scaling policies, and more. This uniform expectation creates real friction:

• Developers want to focus on rapid feature iteration and bug fixes. Being required to deeply understand Kubernetes primitives slows them down and increases cognitive load.
• Operators are measured on platform stability. Sharing ownership of deployment decisions with developers introduces risk and blurs accountability.

Enterprise Kubernetes customers are asking vendors and the open-source community for a better-defined developer experience — one that abstracts the infrastructure layer while still exposing the capabilities developers genuinely need, such as environment configuration, scaling hints, and observability hooks. Projects like the Open Application Model (OAM) and platforms like Knative and various internal developer platforms (IDPs) have emerged partly to address this need, but no single solution has become a universal standard.

Challenge 2: Kubernetes Lacks Application Context

When you deploy even a modest application on Kubernetes, the platform decomposes it into a collection of independent objects. Consider a basic web application backed by a database. A typical deployment might involve all of the following Kubernetes resources:

• Deployment — runs the frontend web server pods.
• StatefulSet — manages a highly available database instance.
• ConfigMap — holds configuration settings for the database server.
• Secret — stores credentials used by the application to connect to the database.
• PersistentVolume and PersistentVolumeClaim — provide durable storage for the database.
• Service — exposes the database to the frontend within the cluster.
• Ingress — exposes the web frontend to external traffic.

That is seven or more distinct objects for a simple two-tier application. Each object is managed independently by Kubernetes. The platform has no native concept of the application as a whole — it does not model the relationship between these objects or understand that they collectively represent a single unit of business logic.

Why Application Context Matters

Without application context, common lifecycle operations become unnecessarily complex:

• Health assessment: Determining whether the application is healthy requires checking multiple independent objects rather than querying a single entity.
• Deletion: Removing an application means tracking down and deleting each constituent resource individually, or relying on labels applied consistently at deploy time.
• Upgrades and rollbacks: Coordinating a change that spans a Deployment, a ConfigMap, and a Secret requires manual orchestration or tooling layered on top of Kubernetes.
• Auditing and cost attribution: Attributing resource consumption to a specific application requires consistent label discipline across all related objects — a discipline that is easy to let slip.

What the Ecosystem Has Done (and Not Done)

Helm, the most widely used Kubernetes package manager, partially addresses this problem at install time. A Helm chart groups related resources into a named release, making it possible to install or delete an application as a single operation. However, once a release is deployed, Kubernetes itself still treats each resource independently. If resources are modified outside of Helm — through kubectl apply, for example — the application context stored in the Helm release can diverge from the actual cluster state.

GitOps tools such as Argo CD and Flux address some of this gap by continuously reconciling desired state (stored in Git) with cluster state, and by surfacing application-level health. Custom Resource Definitions (CRDs) and Operators allow platform teams to define higher-level application abstractions that the Kubernetes API can then manage natively. These approaches move in the right direction, but they require significant investment and expertise to implement well.

What Customers Are Asking For

Enterprise teams adopting Kubernetes to run line-of-business applications are asking the ecosystem for several concrete capabilities:

1. A richer developer abstraction layer — tooling that lets developers define what their application needs (a web server, a cache, a database) without requiring them to author raw Kubernetes YAML for every primitive.
2. First-class application entities — a supported mechanism within or alongside Kubernetes to declare, package, and manage a unified application object, rather than a loosely coupled bag of resources.
3. Lifecycle management at the application level — the ability to deploy, update, roll back, inspect, and delete an application as an atomic unit.
4. Clear role boundaries — platform tooling that enforces sensible defaults and guardrails for developers while preserving operational control for platform engineers, without requiring every developer to become a Kubernetes expert.

The Bottom Line

Kubernetes has solved many of the hardest problems in distributed systems infrastructure. Its adoption across enterprises and cloud providers is a testament to that. But the platform’s infrastructure-centric design creates real usability gaps when it is used as the runtime for application teams who do not live and breathe cluster operations.

The next wave of progress in the Kubernetes ecosystem is less about raw platform capability and more about usability, abstraction, and application-level semantics. Teams evaluating Kubernetes platforms, internal developer platforms, and GitOps tooling should prioritise solutions that address these two pain points directly: clear developer/operator boundaries and genuine application-level lifecycle management.

Introduction

As 2019 drew to a close, Ali Golshan, co-founder and CTO of container security company StackRox, shared seven predictions with Digital Journal about where Kubernetes and cloud-native security were heading in 2020. The predictions cover the maturation of the Kubernetes ecosystem, the emergence of service mesh, the growing importance of third-party tooling, and the convergence of DevOps and security practices — themes that remain relevant for DevOps engineers today.

Prediction 1: Container Orchestration Consolidates Around Kubernetes

Golshan’s first prediction was that the container orchestration market would converge on Kubernetes as the clear standard. His reasoning: as more organizations adopt containers and microservices as part of their DevOps journeys, workload complexity increases, and teams develop a sharper understanding of what they actually need from the container ecosystem.

“The Kubernetes ecosystem is very rich,” Golshan noted, “and as more companies find value in using Kubernetes as a container orchestrator, they will adopt more solutions in the ecosystem. These advances mean we’ll see increasingly complex workloads running in Kubernetes.”

He highlighted SaaS companies as a leading indicator: data-heavy, highly complex applications built on Kubernetes are an ideal forcing function for both ecosystem maturity and broader service mesh adoption.

Prediction 2: Kubernetes Maturity Enables Bigger, More Critical Workloads

Golshan’s second theme was that Kubernetes was crossing from experimental adoption into production-grade, mission-critical use. He pointed to the Cloud Native Computing Foundation’s (CNCF) first full Kubernetes security audit as a turning point — confirming that Kubernetes is foundationally secure, while also prompting engineers to examine configuration weaknesses and potential vulnerabilities more carefully.

“Up to this point, a lot of organizations were running Kubernetes to build and test applications, or in environments that didn’t have external exposures,” Golshan said. “They didn’t have mission-critical applications with web-facing services exposed.”

He drew a parallel with earlier technology transitions: server virtualization in the early 2000s and public cloud adoption roughly between 2008 and 2012 followed similar maturity curves before becoming enterprise standards. Kubernetes, he argued, was following the same natural progression.

Prediction 3: Service Mesh Comes Into Its Own

Golshan’s third prediction focused on service mesh technology — tools such as Istio, Envoy, and Linkerd — gaining traction as Kubernetes deployments grew in complexity and criticality.

He described a typical microservices maturity path: lock down your CI/CD pipeline, run continuous image scanning, harden deployment processes, then move into runtime, segment the network, and incrementally add observability and application-level controls. Service mesh, he argued, represents the upper layers of that stack.

“That last piece is what service mesh provides, and from a productization and application perspective, the evolution of service meshes is still unclear — unlike with Kubernetes — no clear winner has emerged. The needs for observability, tracing, and application-level controls using policies and routing are clear; however, we have yet to see which technology emerges as the dominant player.”

Ali Golshan, CTO, StackRox (December 2019)

Prediction 4: Advanced Third-Party Tooling Makes Cloud Native More Functional

While the CNCF security audit confirmed Kubernetes’ strong security foundations, Golshan argued this did not mean Kubernetes was ready out-of-the-box to run massively scaled enterprise workloads. That gap, he predicted, would be filled by a maturing ecosystem of third-party tools covering observability, security automation, and operational intelligence.

He used Kubernetes pod security policies as a concrete example: while Kubernetes provides the policy framework, manually applying policies at scale — hundreds of times daily, thousands of times weekly — is operationally infeasible. Automation tooling is required to generate and enforce policies based on actual application behavior across development, staging, and production environments.

“You need third-party tools to ingest data, analyze it, and deliver actionable intelligence,” Golshan said. “In an ideal scenario, that intelligence will then programmatically update infrastructure for various use cases.”

Prediction 5: Kubernetes Use Cases Move Toward Operational Safety

Golshan’s fifth prediction addressed how security use cases within Kubernetes deployments evolve as organizations scale. Early-stage deployments tend to focus on basic visibility and configuration management. As deployments mature and expand, security posture management, runtime protection, and compliance automation become priorities.

He noted an interesting pattern: in some sectors, such as healthcare, newer startups were often more security-advanced than established incumbents, partly because they had built on Kubernetes from the start without legacy technical debt.

Golshan also highlighted large enterprises — citing Sony and Disney as examples — that were rebuilding streaming infrastructure on Kubernetes to compete with the delivery speed of cloud-native competitors. “Sometimes Kubernetes adoption is tied to getting a leg up on innovation, and other times it’s a matter of survival,” he said.

He added that security is increasingly embedded in the developer mindset: “Developers are realizing that if security isn’t built in, they will suffer from undetected vulnerabilities, misconfigurations, or other factors out of their control. Security is increasingly part of the developer’s consciousness.”

Prediction 6: Security as Code Translates Security Into Safety

Golshan drew a distinction between security and safety — analogous, he said, to the difference between walls and doors. Security is probabilistic; safety is deterministic. His sixth prediction was that treating both infrastructure and security as code — a practice embodied in the DevSecOps movement — would allow teams to shift from reactive security patching toward automated, policy-driven safety guarantees.

The declarative nature of Kubernetes and microservices architectures makes this shift tractable: policies can be defined once, version-controlled, and applied consistently at scale across clusters. “You have to build security into development for automation,” Golshan said, “because you’re dealing with so much data, so many users, highly distributed infrastructure, and much larger scale. You can’t just keep adding firewalls and agents and point solutions.”

Prediction 7: Operational Issues Will Drive Kubernetes Evolution More Than Security Vulnerabilities

Golshan’s seventh and final prediction was perhaps the most counterintuitive for a security-focused company to make: operational challenges — not security CVEs — would be the primary driver of Kubernetes development in 2020 and beyond.

He acknowledged that 2019 saw a number of Kubernetes CVEs, but praised the community’s response as strong and effective. Looking ahead, he expected questions like “How do I deploy Kubernetes across thousands of clusters and tens of thousands of nodes?” to dominate the roadmap more than security patch cycles.

“As these operational challenges get addressed, we’ll see an acceleration in improvements that result in increased scalability, performance, and functionality,” Golshan predicted. “As a result, Kubernetes will be adopted by a much larger arena of applications, including IoT, autonomous vehicles, and popular consumer technologies that need processing power and the ability to build and deliver applications and services more effectively.”

Key Takeaways for DevOps Engineers

• Kubernetes is the orchestration standard. Invest in Kubernetes expertise and ecosystem tooling rather than hedging across competing orchestrators.
• Service mesh is a next-layer concern. Plan for observability, traffic management, and application-level policy enforcement as workloads grow in complexity — but evaluate tools carefully, as the market has not yet fully consolidated.
• Native Kubernetes features need automation wrappers. Features like pod security policies, network policies, and RBAC require tooling to be operationally practical at scale.
• Shift-left security is not optional. Build security scanning, policy enforcement, and compliance checks into CI/CD pipelines from the start.
• Operational scale will define the next frontier. Multi-cluster management, observability at scale, and cost governance are becoming as important as security for mature Kubernetes deployments.

Note: StackRox was acquired by Red Hat in January 2021 and its technology was open-sourced as Red Hat Advanced Cluster Security for Kubernetes.

Google Cloud Takes Center Stage at RSNA 2019

The 105th Scientific Assembly and Annual Meeting of the Radiological Society of North America (RSNA) opened on December 1, 2019, at McCormick Place in Chicago, Illinois. The week-long event brought together leading players in AI, machine learning, cloud computing, and automation serving the healthcare and life sciences sectors. Among the major exhibitors, Google Cloud stood out as a prominent presence, using the conference to demonstrate its expanding portfolio of cloud solutions tailored specifically for radiology and broader healthcare use cases.

What Google Cloud Was Showcasing

Google Cloud’s exhibition at RSNA 2019 centered on recent advances in cloud-native services designed for healthcare and life sciences organizations. Key areas of focus included:

• Managed DICOM Services: Tools enabling healthcare organizations to store, manage, and retrieve medical imaging data using the DICOM standard in a fully managed cloud environment.
• HIPAA-Supported Deployments: Cloud infrastructure and configurations aligned with HIPAA compliance requirements, aimed at reducing the compliance burden for healthcare IT teams.
• Data De-identification: Solutions designed to strip personally identifiable information from DICOM images, supporting privacy-safe data sharing and research workflows.
• Analytics and AI Integration: Emerging capabilities applying machine learning to radiology workflows, including image recognition and big data analytics.

Google also highlighted developer tooling relevant to healthcare cloud deployments. Cloud Code for popular IDEs was presented as a way to help development teams write, deploy, and debug cloud-native applications more efficiently. Stackdriver Logging (now part of Google Cloud’s operations suite) was highlighted for its advanced log searching and filtering capabilities within cloud-native environments.

Corporate Symposium: “Journey to the Cloud”

On December 3, Google Cloud hosted a corporate symposium titled Journey to the Cloud. The session featured insights and testimonials from Google Cloud customers and partners operating in the radiology and imaging space. The stated goals of the symposium were to drive innovation in the PACS (Picture Archiving and Communication System) industry, support real-world evidence generation, and accelerate the development of next-generation imaging solutions.

Cloud Services and Specializations on Display

Attendees could engage with Google Cloud representatives across several specialized solution areas relevant to radiology departments and healthcare IT teams:

• Disaster recovery planning and implementation in the cloud
• Vendor-neutral archiving (VNA) solutions
• Next-generation PACS solutions
• Teleradiology infrastructure and workflows
• Machine learning-based workflow optimization
• Cost-reduction strategies for Google Cloud deployments in healthcare settings

AI in Healthcare: Google and Kaggle’s Medical Imaging Competitions

One of the more notable initiatives at RSNA 2019 was Google’s collaboration with Kaggle, the data science and machine learning competition platform. Together, the two organizations hosted AI-based medical imaging competitions designed to spur innovation in clinical diagnostics.

A prominent competition focused on detecting intracranial hemorrhage — bleeding that occurs inside the cranium — from medical images. This is a clinically urgent problem: rapid, accurate detection of intracranial hemorrhage is critical for patient outcomes in emergency settings. Winning competitors worked with an enriched imaging dataset assembled by RSNA in collaboration with the American Society of Neuroradiology and MD.ai. The prize for the winning team was $25,000.

These competitions serve a dual purpose: they generate novel AI models that may have real clinical value, and they expand the community of machine learning practitioners working on healthcare problems.

About RSNA

The Radiological Society of North America (RSNA) is an international professional society representing radiologists, medical physicists, and other medical professionals. With more than 54,000 members across 146 countries, RSNA is one of the largest radiology organizations in the world. The society has been an active proponent of AI research in radiology, particularly in applying machine learning to the detection and classification of conditions such as intracranial hemorrhage — work that has the potential to prioritize urgent cases and accelerate clinical decision-making.

Why This Matters for DevOps and Cloud Engineering Teams in Healthcare

Google Cloud’s presence at RSNA 2019 reflects a broader trend: major cloud providers are investing heavily in healthcare-specific managed services, compliance tooling, and AI capabilities. For DevOps engineers working in regulated healthcare environments, the practical takeaways from RSNA 2019 include the maturation of managed DICOM APIs, tighter integration between cloud storage and ML pipelines for imaging data, and improved support for HIPAA-compliant infrastructure-as-code patterns. As these services stabilize, the operational complexity of building and maintaining radiology IT infrastructure in the cloud continues to decrease.

The Infrastructure Complexity Problem for Data Scientists

Artificial intelligence and machine learning have become essential disciplines for data scientists, but they bring significant operational overhead. Setting up GPU clusters, managing drivers, configuring runtimes, and keeping infrastructure healthy can consume time that would be better spent extracting insights from data.

“We’re working towards reducing that complexity and making sure that people that are data scientists, AI, or machine-learning engineers are able to focus on their core business values,” said Renaud Gaubert, lead container and OSS engineer at NVIDIA Corp., speaking at KubeCon + CloudNativeCon.

The ideal experience, as Diane Mueller, director of community development at Red Hat, described it, is straightforward: data scientists want to open a JupyterHub notebook, find everything they need already in place, train their models, and move on — without worrying about what is running underneath.

“[Data scientists] would like to just open up a JupyterHub notebook, have everything there they need, train their models, have them run, and then after they’re done, they’re done.”

Diane Mueller, Director of Community Development, Red Hat Inc.

Kubernetes Operators as the New Deployment Pattern

Kubernetes Operators encode operational knowledge — installation, upgrading, failure recovery, and monitoring — into software that runs inside the cluster itself. Rather than requiring a human operator to manage complex stateful workloads by hand, an Operator continuously reconciles the actual state of the cluster with the desired state defined in a custom resource.

At KubeCon, Red Hat announced an alpha release of OpenShift 4 built entirely on Operators. Mueller described this as a significant shift in how applications and services are deployed and managed on Kubernetes platforms.

“It’s an all Operators-based deployment of OpenShift. I think the Operator framework really has been the big thing that we’ve been really getting a lot of uptake on. It’s been the new pattern for deploying applications, or services, and getting things beyond just a basic install of a service on OpenShift or any Kubernetes.”

Diane Mueller, Red Hat Inc.

OperatorHub.io: A Shared Marketplace for Kubernetes Operators

Alongside the OpenShift 4 alpha announcement, Red Hat has been building out OperatorHub.io as a community hub for upstream Kubernetes Operators. Operators listed there — including the NVIDIA GPU Operator — are designed to run on any conformant Kubernetes distribution, not just OpenShift.

“OperatorHub.io, everything in there runs on any Kubernetes. And the goal is to be able to take stuff in a hybrid-cloud model [and] be able to run it anywhere you want.”

Diane Mueller, Red Hat Inc.

Free access to these Operators means platform teams can deploy them on any Kubernetes environment, supporting a hybrid-cloud model where workloads are not locked to a single provider or distribution.

The NVIDIA GPU Operator: Four Phases of Automation

The NVIDIA GPU Operator is built on Red Hat’s Operator SDK and demonstrates how the Operator pattern can dramatically simplify AI/ML infrastructure management. Gaubert outlined four distinct phases of automation the GPU Operator handles:

Phase 1: Component Installation

The Operator automates the installation of every component a GPU cluster requires: the NVIDIA driver, the container runtime, the Kubernetes device plugin, and the necessary mount points. This replaces a manual, error-prone bootstrap process with a single declarative resource definition.

Phase 2: Infrastructure Automation and Updates

Once the cluster is running, the Operator automates infrastructure builds and manages rolling updates to individual components. This removes the need for manual intervention each time a driver or plugin version changes.

Phase 3: Lifecycle Management and Self-Healing

In a fleet of GPU nodes, individual machines will inevitably enter degraded or failed states. Phase three addresses lifecycle management: the Operator detects nodes that have drifted from the desired state and automatically remediates them, recovering from bad states to good ones without manual intervention.

Phase 4: Monitoring and Observability

The final phase surfaces operational insights to users. By integrating monitoring into the Operator itself, GPU cluster health and utilization data becomes visible without requiring separate, manually configured tooling.

“The Operator SDK has helped us a lot here, just laying out these different steps, and, in a way, it’s done the same thing as what we’re trying to do for our customers, the different data scientists. Which is, basically, get out of our way and allow us to focus on core business values.”

Renaud Gaubert, NVIDIA Corp.

Why This Matters for AI/ML Teams

The Operator pattern addresses a genuine pain point: the gap between Kubernetes as a general-purpose platform and the specific, complex requirements of GPU-accelerated AI/ML workloads. By encoding operational expertise into software, Operators allow platform teams to offer a managed-service-like experience on self-hosted or hybrid infrastructure.

• Reduced toil: Routine tasks such as driver installation, updates, and node recovery are automated rather than handled manually.
• Consistency: The same Operator runs identically on OpenShift, upstream Kubernetes, or any cloud provider’s managed Kubernetes service.
• Self-service for data scientists: With infrastructure managed by Operators, data scientists can provision GPU-backed environments without engaging the platform team for each request.
• Hybrid-cloud portability: Operators listed on OperatorHub.io are not tied to a single distribution, supporting workload portability across environments.

Further Resources

To explore Operators available for your Kubernetes environment, visit OperatorHub.io. For documentation on building your own Operators, the Operator SDK is the recommended starting point for Go, Ansible, and Helm-based Operators.

Source: SiliconANGLE / theCUBE interview at KubeCon + CloudNativeCon, San Diego, November 2019.

Background: Why VMware Bet on Kubernetes

VMware’s 2018 acquisition of Heptio — the company co-founded by Kubernetes creators Joe Beda and Craig McLuckie — signalled a clear strategic direction: embed Kubernetes natively into the vSphere platform rather than treat it as a bolt-on add-on. A year later, VMware announced Project Pacific, described internally as the most significant evolution of vSphere in a decade.

The driving logic is straightforward. Enterprises are not abandoning their existing VM-based workloads overnight, but they also need a path to modern, container-based application delivery. VMware’s answer was to make Kubernetes a first-class citizen inside vSphere itself, letting both VM and container workloads coexist on the same platform with shared management tooling.

What Project Pacific Actually Does

According to Joe Beda, Project Pacific operates on two levels simultaneously:

• Kubernetes as an infrastructure primitive: Kubernetes is embedded into vSphere not just to run container workloads, but as a foundational technology for building and managing vSphere itself. This means even customers who have no interest in containers benefit from the underlying Kubernetes-driven architecture through improved APIs and future feature enablement.
• Kubernetes as a workload platform: For customers who do want to run containerised applications, vSphere provides a first-class Kubernetes experience. Cluster management, scaling, and infrastructure operations are unified with existing VM management workflows.

A key output of this work is a unified API and toolset that lets operators manage both containers and VMs through the same interface, eliminating the operational split that has traditionally forced teams to maintain separate skill sets and toolchains.

vSphere Native Pods: Blurring the Container/VM Boundary

One of the more technically interesting elements of Project Pacific is the concept of vSphere Native Pods. Traditional approaches to running containers in enterprise environments involve spinning up a VM, installing a container runtime, and running containers inside that VM. This preserves VM-level security isolation but introduces OS overhead for every VM.

vSphere Native Pods, built directly into ESXi, aim to eliminate that overhead by hyper-optimising the virtualisation layer specifically for container workloads. The result is an architecture that offers the security and isolation guarantees of VMs with performance characteristics closer to running containers on bare metal.

“We are looking at how to hyper-optimise that VM to reduce that OS overhead and provide the best of both worlds in terms of security, all of VMware’s deep experience around getting the best performance out of VMs, and bring that into the container world.”

— Joe Beda, co-founder of Kubernetes, VMware

Beda cited early internal benchmarks claiming that vSphere Native Pods running on Project Pacific could outperform Kubernetes on traditional VMs by up to 30%, and even outperform bare-metal Kubernetes deployments by up to 8%. These figures were presented as early engineering results, not published benchmarks, and should be treated accordingly until independently verified.

Containers vs. VMs: Complementary, Not Competing

A common framing in the industry has been that containers and VMs are in competition — containers offering lower overhead and faster startup, VMs offering stronger isolation and broader OS compatibility. Beda pushes back on this framing directly.

At a technical level, containers and VMs are complementary. Containers benefit from the hardware optimisations, memory management, and security hardening that VMware has spent years building into ESXi. At the same time, Kubernetes provides the orchestration and workflow layer that helps application teams ship software faster without creating bottlenecks on the operations side.

The practical implication for enterprises is that they do not need to choose between modernising their applications and protecting their existing infrastructure investment. VMs and containers can share the same resource pool, and workloads can migrate between the two models as application requirements evolve.

Key Use Cases Identified

Enterprise Application Modernisation

Many enterprise applications are currently locked inside VMs. The path to modernisation — refactoring or rewriting them as containerised microservices — has historically required a parallel infrastructure build-out. Project Pacific removes that requirement by letting both models operate on the same underlying platform, giving teams the flexibility to modernise incrementally.

Telecommunications and 5G

Telcos building out 5G networks need platforms that can support both consumer-facing applications and network function virtualisation (NFV) workloads. Kubernetes provides the consistent orchestration layer that makes it practical to run these workloads across highly distributed infrastructure, a natural fit for the 5G architecture model.

Edge Computing

Latency requirements, data sovereignty regulations such as GDPR, and IoT data volumes are all pushing workloads away from centralised cloud infrastructure and toward the edge. Kubernetes offers a consistent operational model across cloud, on-premises data centres, and edge locations, making it well suited to the heterogeneous infrastructure that edge computing demands.

What This Means for Existing vSphere and VMware PKS Customers

At the time of the interview, VMware had not published specific upgrade or migration paths for existing vSphere or PKS (Pivotal Container Service, now Tanzu Kubernetes Grid) customers. Beda acknowledged this directly, noting that the engineering work was still in progress and that specific product timelines had not been announced.

What VMware did commit to was protecting the investments of existing customers. Organisations that had already adopted VMware PKS or standard vSphere were assured that VMware would provide the smoothest possible transition path as Project Pacific moved from technology preview to product.

Partner and ISV Ecosystem Implications

Embedding Kubernetes into vSphere changes the conversation VMware can have with customers. Historically, VMware’s primary audience inside enterprises was infrastructure and operations teams. Project Pacific expands that audience to include application developers, DevOps teams, and platform engineers — all of whom interact with Kubernetes as part of their daily workflow.

This broader reach also opens new opportunities for VMware’s partner network. ISVs building on top of vSphere can now target the same platform for both VM-based and container-based offerings, rather than maintaining separate integrations for each model.

On the question of competitive dynamics — specifically around Red Hat OpenShift, which is also a Kubernetes distribution targeting enterprise customers — Beda noted that co-opetition is standard in the infrastructure industry. VMware running on HPE hardware while competing with HPE in other areas, or Dell owning VMware while VMware supports multi-vendor environments, are examples of the same dynamic.

The Bigger Picture: Democratising Kubernetes for the Enterprise

Despite Kubernetes’ maturity as a project, adoption in traditional enterprises has lagged behind its profile in the cloud-native community. The operational complexity of standing up and maintaining Kubernetes clusters has been a genuine barrier, particularly for organisations without dedicated platform engineering teams.

VMware’s thesis with Project Pacific is that embedding Kubernetes into vSphere — a platform that enterprise infrastructure teams already know how to operate — removes the primary adoption barrier. Organisations do not need to build Kubernetes expertise from scratch; they can extend their existing vSphere knowledge and tooling to cover container workloads.

Combined with VMware’s 2019 acquisition of Pivotal (which brought Cloud Foundry and application development tooling into the VMware portfolio), the ambition is to cover the full application lifecycle: from infrastructure provisioning through to developer workflow and application delivery.

Project Pacific was subsequently released as part of vSphere 7.0 in 2020, branded under the VMware Tanzu portfolio. Readers researching current VMware Tanzu or vSphere with Tanzu capabilities should consult current VMware documentation, as the product has evolved significantly since this interview was conducted.

Overview

Delivery Hero (DH) operates Kubernetes clusters at significant scale — reportedly hundreds of nodes and thousands of pods across multiple environments. To keep this infrastructure manageable, their engineering teams rely on a coordinated set of tools built around Helm, the Kubernetes package manager. The full stack they use includes Helm itself, helmfile, helm-diff, and helm-secrets.

Why Helm?

Helm is a CNCF-hosted project that functions as a package manager for Kubernetes. Rather than maintaining a growing collection of individual YAML manifests for every resource in a cluster, Helm groups all the Kubernetes objects needed to deploy an application into a single, versioned unit called a chart.

Most teams start by writing raw YAML files to declare cluster state. This approach works at small scale but becomes increasingly difficult to maintain as the number of services and environments grows. Helm addresses this by:

• Packaging all related Kubernetes resources (Deployments, Services, ConfigMaps, etc.) into a single chart
• Enabling parameterisation through values files, so the same chart can be deployed differently across environments
• Providing versioned releases, making rollbacks straightforward

At Delivery Hero, multiple engineering teams use Helm charts to package both individual applications and cluster-level tooling.

helmfile: Declarative Management Across Clusters

helmfile is a declarative spec for deploying Helm charts. It maintains information about which charts are installed on which clusters, together with the relevant chart versions, values files, and Kubernetes cluster contexts. Williams describes it as analogous to Ansible playbooks — a single source of truth for the desired state of Helm releases across environments.

Because helmfile configurations are stored in Git, the workflow naturally supports progressive rollouts: changes can be reviewed in pull requests and applied to non-production clusters first before being promoted to production. This gives teams a clear audit trail and a safe promotion process.

helm-diff: Previewing Changes Before Deployment

helm-diff is a Helm plugin that renders a colour-coded diff of the changes that will be applied when a chart is upgraded. This allows engineers to review exactly what will change in the cluster before committing to a deployment, reducing the risk of unexpected modifications reaching production.

Williams acknowledges that a clean diff is not a guarantee of a clean deployment — issues can still arise after apply. However, he notes that Delivery Hero had not encountered problems attributable to helm-diff itself beyond issues already present in Helm’s own behaviour.

helm-secrets: Encrypting Sensitive Configuration

Managing secrets in Kubernetes is one of the most common pain points teams face when moving to GitOps workflows. Storing sensitive values in plaintext in a Git repository is not acceptable, but keeping secrets entirely out of version control creates its own operational problems.

helm-secrets solves this by wrapping Helm values files with encryption. Under the hood it uses Mozilla sops (Secrets OPerationS), which acts as a transparent encryption/decryption layer around a standard text editor or CI pipeline. Engineers edit secrets in plaintext locally; sops handles encryption before the file is committed and decryption when it is consumed.

sops integrates with major cloud Key Management Systems (KMS), including:

• AWS KMS
• GCP KMS

This is a natural fit for Delivery Hero’s infrastructure, which Williams describes as hosted “mostly on EKS and GKE, with some teams still using kops clusters on AWS.”

The Broader Toolchain

Helm and its companion tools are not the only pieces of Delivery Hero’s infrastructure puzzle. The team also uses:

• Terraform — for provisioning and managing underlying cloud infrastructure
• Sysdig — for container security and monitoring
• Prometheus — for metrics collection and alerting

Key Takeaways

Delivery Hero’s approach offers a practical template for engineering teams managing Kubernetes at scale:

• Use Helm to package applications and cluster tooling into versioned, reusable charts
• Use helmfile to maintain a declarative, Git-tracked record of which charts and versions are deployed to which clusters
• Use helm-diff to review changes before they are applied, catching unintended modifications early
• Use helm-secrets with Mozilla sops to safely version-control encrypted secrets alongside the rest of your Helm configuration
• Combine with cloud KMS (AWS or GCP) to centralise key management without adding operational overhead

This layered toolchain addresses the three main challenges of operating Kubernetes at scale: configuration management, change visibility, and secrets handling — without requiring teams to build custom tooling from scratch.

DevOps practices compound the challenge: the speed of continuous delivery increases the risk that a misconfigured resource slips through unnoticed. This is the problem that Microsoft’s own IT department — which reportedly runs the majority of its internal applications on Azure — sought to solve. The result is the Secure DevOps Kit for Azure, commonly abbreviated AzSK. It is open source and published on GitHub. This article walks through installation, core scanning commands, auto-remediation, attestation, CI/CD integration, and continuous assurance.

What Is AzSK?

AzSK is a collection of PowerShell cmdlets and Azure DevOps extensions that enforce a security baseline across the full DevOps lifecycle:

• Subscription scanning — checks subscription-level settings such as Security Center configuration, alerts, and ARM policies.
• Resource group scanning — runs Security Verification Tests (SVTs) against all resources in a given resource group.
• CI/CD integration — an Azure DevOps marketplace extension that checks ARM templates and deployed resources as part of a pipeline.
• IDE integration — a Visual Studio extension called Security IntelliSense that flags insecure code patterns inline.
• Continuous assurance — a scheduled scan that feeds results into Azure Monitor Log Analytics to catch configuration drift over time.

Installation

AzSK requires PowerShell 5.0 or later on Windows. Install the module from the PowerShell Gallery with:

Install-Module AzSK -Scope CurrentUser

If you encounter conflicts with existing modules, add the -AllowClobber flag:

Install-Module AzSK -Scope CurrentUser -AllowClobber

The kit is updated monthly. If your installed version falls more than two releases behind, AzSK will display error messages prompting you to upgrade. Re-running the install command above will update to the latest version. To enable automatic update prompts, run:

Set-AzSKPolicySettings -AutoUpdate On

AzSK has been updated to use the Az PowerShell modules. If you have the older AzureRM modules installed, uninstall them before proceeding to avoid conflicts.

Scanning a Subscription

Start by authenticating to Azure:

Connect-AzAccount

Then run the subscription-level scan cmdlet (replace the placeholder with your subscription ID):

Get-AzSKSubscriptionSecurityStatus -SubscriptionId <your-subscription-id>

After the scan completes, a folder opens automatically containing:

• A SecurityReport.csv summary file
• Subfolders with detailed log files

Open SecurityReport.csv in Excel and filter on the Status column. The two most important statuses are:

• Failed — a control was checked automatically and did not pass.
• Verify — the control cannot be checked automatically; it requires manual review.

A Recommendation column in the CSV describes the remediation steps for each failed control. Common subscription-level findings include:

• Azure Security Center not configured with the correct contact details (Set-AzSKAzureSecurityCenterPolicies)
• Missing subscription alerts (Set-AzSKAlerts)
• No ARM policies configured (Set-AzSKARMPolicies)
• Azure Security Center Standard tier not enabled

Scanning a Resource Group

To run Security Verification Tests (SVTs) against all resources in a specific resource group, use:

Get-AzSKAzureServicesSecurityStatus -SubscriptionId <your-subscription-id> -ResourceGroupNames <rg-name>

The scan duration scales with the number of resources in the group. Output is the same CSV and log structure as the subscription scan. If you prefer PDF output, add the -GeneratePDF flag, which supports both landscape and portrait orientations:

Get-AzSKAzureServicesSecurityStatus -SubscriptionId <your-subscription-id> -ResourceGroupNames <rg-name> -GeneratePDF Landscape

Automatic Remediation with -GenerateFixScript

Both subscription and resource-group scan cmdlets accept a -GenerateFixScript flag. When specified, AzSK produces a remediation script alongside the normal report output. The results folder will contain an additional FixControlScripts subfolder with two files:

• RunFixScript.ps1 — the remediation script to execute
• FixControlConfig.json — a parameters file (IP addresses, usernames, and so on) that you may need to edit before running the script

The SecurityReport.csv includes a column indicating which controls are eligible for auto-fix. Review the config file carefully before executing the fix script in a production environment.

Attestation: Acknowledging Accepted Risk

Sometimes a control failure represents an accepted, documented risk rather than something that needs to be fixed — for example, a legacy workload that cannot be migrated immediately. AzSK supports attestation to prevent known accepted exceptions from cluttering future scan reports.

Pass the -ControlsToAttest switch to either scan cmdlet. After the normal scan completes, AzSK enters an interactive attestation mode in which you provide a justification and disposition for each flagged control. The attestation record — including who provided it and when — is stored in the subscription inside a dedicated resource group named AzSKRG.

Default attestation expiry periods by severity are:

A user needs Owner or Contributor permissions on the AzSKRG resource group to perform attestation, which limits this capability to authorized security personnel. For environments with many resources spread across multiple resource groups, AzSK also supports bulk attestation.

CI/CD Pipeline Integration

Running scans on demand is a good starting point, but real security hygiene requires checks to run automatically on every deployment. AzSK publishes an extension to the Azure DevOps Marketplace called the Secure DevOps Kit (AzSK) CICD Extensions for Azure. It provides two key pipeline tasks:

• ARM Template Checker — validates infrastructure-as-code templates before deployment.
• SVT Task — runs Security Verification Tests against resources that have already been deployed.

When a check fails, you can configure the pipeline to fail the deployment, send an email notification, or pause for manual approval. This gates insecure changes before they reach production.

Security IntelliSense for Visual Studio

For developers working in Visual Studio (2015 Update 3 and later, 2017, and 2019), the Security IntelliSense extension surfaces security issues directly in the editor using red and green squiggles, similar to standard syntax error highlighting. This shifts security feedback even further left — to the moment code is written.

Continuous Assurance: Catching Configuration Drift

Pipeline checks and on-demand scans are point-in-time assessments. A resource that passes a deployment scan can drift into a non-compliant state later — for example, if someone manually changes a network security group rule or disables an audit policy through the portal. Continuous Assurance addresses this by scheduling recurring scans that feed results into Azure Monitor Log Analytics.

Prerequisites for Continuous Assurance:

• A Log Analytics workspace configured in Azure Monitor
• AzSK running on Windows 10 or Windows Server 2016

To enable Continuous Assurance on a subscription, run:

Install-AzSKContinuousAssurance -SubscriptionId <your-subscription-id> `
    -ResourceGroupNames <comma-separated-rg-names> `
    -LAWSId <log-analytics-workspace-id> `
    -LAWSSharedKey <log-analytics-shared-key>

Once configured, AzSK runs scans on a schedule and pushes results to Log Analytics, where you can build dashboards and alerts to track the security posture of all subscriptions across the entire DevOps lifecycle from a single pane of glass.

Summary

AzSK provides a layered approach to Azure security that matches the pace of DevOps delivery:

• Ad-hoc scans establish a baseline and identify existing issues.
• Auto-fix scripts accelerate remediation of common misconfigurations.
• Attestation formalizes accepted exceptions with an audit trail.
• CI/CD integration prevents regressions from reaching production.
• Continuous Assurance monitors for drift after deployment.

Because AzSK is open source, the controls it checks, the fix scripts it generates, and the policies it enforces can all be reviewed and customized to fit your organization’s requirements.

What Is IT/DevOps Incident Management Software?

Incident management software gives DevOps and Site Reliability Engineering (SRE) teams a structured way to detect, triage, communicate about, resolve, and learn from unplanned outages or service degradations. In a DevOps context the tooling goes beyond traditional IT Service Management (ITSM) ticketing: it integrates with monitoring pipelines, on-call scheduling, chat platforms, CI/CD systems, and post-incident review workflows.

Why This Market Exists

Several converging pressures have driven demand for dedicated incident management tooling:

• Higher deployment frequency. Continuous delivery pipelines mean code ships multiple times per day, increasing the probability of an incident reaching production.
• Distributed, microservices architectures. A failure in one service can cascade unpredictably, making manual incident tracking error-prone.
• Growing SLA and compliance obligations. Regulated industries require auditable incident timelines and documented remediation steps.
• On-call fatigue. Alert noise from modern observability stacks makes intelligent routing and escalation essential to engineer wellbeing and response speed.
• Shift toward blameless post-mortems. SRE culture demands structured retrospective workflows that raw ticketing systems do not provide.

Core Capabilities to Evaluate

When assessing tools in this category, DevOps teams typically evaluate the following feature areas:

Alert Ingestion and Noise Reduction

The platform should accept alerts from monitoring and observability tools (APM, infrastructure monitoring, log management, synthetic checks) and apply deduplication, correlation, and suppression rules so that engineers receive actionable notifications rather than alert storms.

On-Call Scheduling and Escalation Policies

Flexible rotation schedules, overrides, and multi-tier escalation paths ensure that every alert reaches the right person within the agreed response window. Integration with calendar systems reduces scheduling conflicts.

Incident Lifecycle Tracking

From detection through acknowledgement, investigation, mitigation, and resolution, the tool must maintain a timestamped, auditable record. Status pages that communicate impact to stakeholders and customers are increasingly included or integrated.

Collaboration Integrations

Bi-directional integrations with Slack, Microsoft Teams, and similar platforms allow responders to acknowledge alerts, update severity, and log notes without leaving their primary communication channel.

Post-Incident Review (PIR) and Postmortem Workflows

Automated timeline generation, contributing-factor tagging, and action-item tracking support blameless retrospectives and feed continuous improvement loops.

Reporting and SLA Metrics

MTTA (Mean Time to Acknowledge), MTTR (Mean Time to Resolve), incident frequency by service, and SLA breach trends give engineering and leadership teams the data needed to prioritize reliability investments.

Deployment Models

Incident management platforms are generally available in three deployment models, each with distinct trade-offs:

Common Vendor Categories

The market includes several distinct vendor types, often with overlapping capabilities:

• Dedicated on-call and alerting platforms — tools whose primary value proposition is intelligent alert routing and on-call scheduling.
• Full-stack ITSM suites with DevOps extensions — traditional service desk platforms that have added DevOps workflow support.
• Observability platforms with built-in incident management — monitoring and APM vendors that bundle incident workflows directly into their data platforms.
• Open-source and self-hosted solutions — community-maintained tools that offer flexibility at the cost of operational investment.

Key Buying Considerations for DevOps Teams

Before selecting a platform, engineering and operations leaders should answer the following questions:

1. Integration depth. Does the tool natively integrate with your existing monitoring stack, CI/CD pipelines, and chat tools, or will you need custom webhooks for every connection?
2. Alert quality controls. What deduplication, suppression, and correlation mechanisms are available to reduce alert fatigue?
3. Mobile experience. On-call engineers respond from mobile devices; the mobile app must be reliable under degraded network conditions.
4. Pricing model. Per-seat pricing can become expensive as organizations scale the number of services and on-call participants. Understand the total cost at your expected scale.
5. Data retention and export. Postmortem and audit data should be exportable in standard formats to avoid vendor lock-in.
6. Security and compliance. Verify SOC 2, ISO 27001, or other relevant certifications if your organization operates in a regulated sector.

Market Outlook

Demand for specialized incident management tooling continues to grow alongside broader DevOps and SRE adoption. Key trends shaping the category include:

• AIOps integration — machine-learning-assisted anomaly detection and root-cause suggestion are becoming standard expectations rather than premium features.
• Shift-left incident awareness — error budgets and reliability dashboards surfaced in developer portals aim to surface reliability risk before incidents occur.
• Consolidation — observability vendors are acquiring or building on-call capabilities, blurring the line between monitoring and incident management.
• Incident.io-style collaborative response rooms — structured, real-time incident channels with automated runbook prompts are replacing ad-hoc war rooms.

Summary

IT/DevOps Incident Management Software is a mature but actively evolving market category. The right platform reduces mean time to resolution, supports blameless retrospectives, and provides the metrics engineering leadership needs to justify reliability investment. Evaluate tools against your specific integration requirements, team size, deployment constraints, and compliance obligations rather than relying solely on analyst rankings or feature checklists.