Editorial note: The original source of this article was a teaser for a paid market research report published by Alexa Reports (via sciencein.me, 2020). Specific revenue figures and CAGR projections from that report are not reproduced here because they were redacted in the public teaser (shown as “xxx”). The analysis below is an independent explanation of the topic based on publicly available knowledge of the DevOps tooling market as of the original publication date.

What Is the DevOps Software Market?

The DevOps software market encompasses tools and platforms that support continuous integration, continuous delivery (CI/CD), infrastructure automation, configuration management, monitoring, security (DevSecOps), and collaboration between software development and IT operations teams. Organisations adopt these tools to shorten time-to-market, improve deployment reliability, and reduce manual operational overhead.

Market analysts typically segment DevOps software by deployment model (cloud-based vs. on-premises), by organisation size (large enterprises vs. small and medium-sized businesses), and by geography.

Key Vendors and Competitive Landscape

The DevOps software space is crowded and competitive. As of 2020, prominent vendors covered by market analysts included:

• VersionOne – Agile and DevOps planning platform (acquired by CollabNet, now part of Digital.ai).
• Pivotal Software – Known for Pivotal Cloud Foundry and application modernisation tooling (acquired by VMware).
• Chef Software – Infrastructure automation and compliance (acquired by Progress Software).
• CA Technologies – Broad enterprise DevOps portfolio including Continuous Delivery Director (acquired by Broadcom).
• CAST Software – Software intelligence and application analytics.
• DBmaestro – Database DevOps and release automation.
• Electric Cloud – Release automation and pipeline orchestration (now CloudBees).
• IBM – Enterprise CI/CD, UrbanCode, and cloud-native toolchains.
• Kovair Software – ALM and DevOps integration platform.
• Sonatype – Software supply chain security and dependency management (Nexus platform).
• Puppet – Infrastructure automation and configuration management.
• BMC Software – IT operations management with DevOps workflow integration.
• Rocket Software – DevOps tooling for mainframe and hybrid environments.
• Microsoft – Azure DevOps (formerly VSTS) and GitHub, now a dominant platform player.

Beyond this list, the broader ecosystem includes GitLab, JFrog, HashiCorp, Atlassian (Jira, Bitbucket), CircleCI, and dozens of specialised point solutions — reflecting how fragmented the toolchain market remains.

Deployment Models: Cloud-Based vs. On-Premises

DevOps tools are sold and delivered in two primary models:

Cloud-Based (SaaS)

Cloud-hosted DevOps platforms have become the dominant choice for most organisations, particularly SMBs and cloud-native teams. They eliminate infrastructure management overhead, scale on demand, and typically offer consumption-based pricing. Examples include GitHub Actions, Azure DevOps Services, CircleCI, and GitLab SaaS.

On-Premises

Heavily regulated industries — financial services, defence, healthcare, government — often require on-premises deployments for data residency, compliance, or air-gapped environments. Vendors such as GitLab (self-managed), Bitbucket Data Center, Jenkins, and Nexus Repository cater explicitly to this segment. On-premises licensing typically carries higher upfront cost but offers full control over data and audit trails.

Industry Segments: Large Enterprises vs. SMBs

DevOps adoption patterns differ significantly by organisation size:

• Large enterprises invest in integrated, enterprise-grade platforms that support complex governance, role-based access control, audit logging, and integration with existing ITSM systems (ServiceNow, Jira Service Management). They are more likely to standardise on vendor suites such as Microsoft Azure DevOps, GitLab Ultimate, or IBM UrbanCode.
• Small and medium-sized businesses (SMBs) tend to favour lightweight, low-cost or open-source tools — Jenkins, GitHub, CircleCI, Docker Hub — often assembling their own toolchains rather than buying integrated suites. Cloud-based SaaS products with free tiers are the dominant entry point.

Regional Market Dynamics

DevOps software adoption is a global phenomenon but with notable regional differences in pace and priority:

North America

The United States and Canada represent the largest and most mature DevOps software market, driven by a high concentration of technology companies, cloud-first enterprises, and early adopters of agile and continuous delivery practices. Major platform vendors (Microsoft, IBM, GitHub) are headquartered here.

Europe

Western Europe — particularly the UK, Germany, France, and the Nordic countries — shows strong enterprise DevOps adoption, with additional complexity introduced by GDPR compliance requirements influencing tool selection, data storage preferences, and vendor contracts. Eastern European markets are growing rapidly as a software development hub.

Asia Pacific

China, India, Japan, South Korea, and Australia are major growth markets. India’s large software services industry drives significant demand for CI/CD and test automation tools. China has a distinct domestic ecosystem with homegrown alternatives to Western platforms. Japan and South Korea have strong enterprise adoption.

Middle East and Africa

Adoption in MEA is accelerating, especially in the Gulf Cooperation Council (GCC) states (Saudi Arabia, UAE, Qatar, Kuwait) driven by government digital transformation initiatives. South Africa is the leading African market for enterprise software.

Key Growth Drivers

• Accelerating software release cycles: Competitive pressure forces organisations to ship more frequently, making CI/CD automation essential rather than optional.
• Cloud migration: As organisations move workloads to AWS, Azure, and Google Cloud, cloud-native DevOps tooling becomes the natural complement.
• Security integration (DevSecOps): Growing awareness of supply chain vulnerabilities is driving adoption of tools that embed security scanning into the pipeline.
• Remote and distributed teams: The shift to remote work increased demand for collaborative, cloud-hosted DevOps platforms that do not require VPN access to an on-prem server.
• Container and Kubernetes adoption: The widespread use of Docker and Kubernetes has created demand for container-aware CI/CD tools, Helm chart management, and GitOps platforms such as Argo CD and Flux.

Key Challenges and Restraints

• Toolchain complexity and sprawl: The sheer number of tools in a typical DevOps stack creates integration overhead, maintenance burden, and skills gaps.
• Cultural resistance: DevOps is as much an organisational change as a technology change. Legacy enterprises often struggle with breaking down silos between Dev and Ops teams regardless of which tools they buy.
• Skills shortage: Demand for engineers experienced with CI/CD, infrastructure-as-code, and platform engineering consistently outpaces supply.
• Vendor lock-in risk: Proprietary pipeline syntax and tight platform integrations make it costly to switch vendors, a concern that pushes some teams toward open standards and open-source tools.
• Compliance and audit requirements: Regulated industries must ensure their DevOps pipelines produce auditable evidence of change control, which adds complexity to toolchain selection and configuration.

Market Structure and Report Coverage

Comprehensive commercial market research reports on DevOps software typically cover the following analytical dimensions, which practitioners can use as a framework for their own vendor evaluations:

• Vendor market share by revenue and shipment volume
• Product segmentation by deployment model (cloud vs. on-premises) and pricing tier
• Regional market sizing and growth projections
• Competitive positioning and recent M&A activity
• End-user adoption by industry vertical (financial services, healthcare, retail, government, technology)
• Technology trends influencing future tool selection (AI-assisted development, GitOps, platform engineering, internal developer platforms)

For teams making toolchain decisions, analyst reports from Gartner, Forrester, and IDC — as well as the annual State of DevOps Reports published by DORA (now part of Google Cloud) and the State of the Octoverse from GitHub — offer data-backed benchmarks that are freely accessible.

Summary

The DevOps software market remains one of the most dynamic segments of enterprise software. The convergence of cloud computing, security awareness, and organisational pressure for faster delivery continues to expand both the market and the number of vendors competing within it. Whether you are evaluating tools for a small engineering team or planning a large-scale platform strategy for a multinational enterprise, understanding the competitive landscape, deployment trade-offs, and regional dynamics covered in this article provides a solid starting framework.

Why Traditional Security Falls Short in Kubernetes Environments

As more organizations shift to microservices-based architectures and orchestrate containerized workloads with Kubernetes, the perimeter-based security model that relied on firewalls and network segmentation begins to break down. Cloud infrastructure is elastic and highly dynamic — the static boundaries that firewalls enforce simply do not map cleanly onto ephemeral pods, virtual private cloud (VPC) networks, and cloud-native applications maintained by many different teams.

In a Kubernetes cluster, the threat model must account for risks that originate inside the running environment. Common examples include a malicious or compromised third-party library pulled in as a dependency, or a container image sourced from an untrusted registry. Because the attack surface is internal as well as external, distributed security controls are essential.

What Kubernetes Provides Natively

Compared to many open or VM-based platforms, Kubernetes ships with a reasonably strong set of built-in security primitives:

• Flexible authentication — Kubernetes supports multiple authentication strategies including X.509 certificates, bearer tokens, and OIDC identity providers.
• Role-Based Access Control (RBAC) — A mature RBAC system lets administrators define fine-grained permissions for users and service accounts across namespaces and resources.
• Admission controllers — Resources are validated (and optionally mutated) before being admitted into the cluster, enabling policy enforcement at creation time.
• Pod security controls — Configuration options allow operators to constrain how processes run inside containers (e.g., preventing privilege escalation, enforcing read-only root filesystems).
• Network Policies — Kubernetes NetworkPolicy resources enable east-west (intra-cluster) microsegmentation between pods.

Fine-grained microsegmentation, in particular, significantly reduces the attack surface by limiting lateral movement — making it harder for a compromised component to pivot to other services, exfiltrate data, or spread within the cluster.

Understanding Kubernetes Network Policies

Kubernetes NetworkPolicy is the primary API for controlling pod-to-pod and pod-to-endpoint traffic. Before configuring policies, it is important to understand the default behaviour and the key semantics:

• Open by default: Without any NetworkPolicy applied, all pods can send and receive traffic freely — to and from any source or destination inside or outside the cluster.
• East-west scope: Native NetworkPolicy semantics are limited to intra-cluster segmentation and CIDR block specification. Domain names and domain wildcards are not supported in policy rules.
• Label-based selection: Policies select pods using labels and define rules specifying which ingress or egress traffic is permitted for those pods.
• Additive and whitelisting: Policies are additive — there is no native concept of an explicit drop action. Once any NetworkPolicy selects a pod, all traffic not explicitly permitted is denied for that pod.
• CNI plugin requirement: NetworkPolicy enforcement requires a Container Network Interface (CNI) plugin that supports the NetworkPolicy API. Popular choices include Calico and Flannel, as well as cloud-provider CNI plugins that integrate with VPC networking.

Start with a Default Deny-All Policy

The most impactful first step is to flip the open-by-default posture by applying a default deny-all policy to each namespace. This single change means that no pod can send or receive traffic unless an explicit allow rule is defined. The recommended workflow is:

1. Apply a default deny-all NetworkPolicy to every namespace.
2. Incrementally add explicit allow policies for each known, legitimate communication path between services.

This approach — sometimes described as default deny, explicit allow — minimises the blast radius of any compromised component.

Below is a minimal example of a default deny-all NetworkPolicy for a namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

With podSelector: {}, the policy selects all pods in the namespace. Specifying both Ingress and Egress policy types with no rules blocks all inbound and outbound traffic by default.

Ingress Traffic Controls: Load Balancers and Layer-7 Proxies

Beyond pod-to-pod policies, Kubernetes offers additional network security controls for traffic entering the cluster from external sources. Using special resource annotations on Service and Ingress objects, operators can instruct the Kubernetes cloud controller to configure underlying VPC security groups and load balancers — for example, restricting which source IP ranges are permitted to reach a load balancer. These annotations are consumed by the cloud controller, which acts as a translation layer between Kubernetes resources and the underlying cloud platform.

Where Native Kubernetes Security Falls Short

Despite these capabilities, Kubernetes native security controls have well-documented gaps that require additional tooling or architectural decisions to address:

• Host-network pods: Pods configured to run on the host network namespace are not subject to NetworkPolicy rules. These pods require separate controls at the host or infrastructure level.
• No explicit drop actions: Native NetworkPolicy has no way to express an explicit deny rule. Third-party tools such as Calico’s GlobalNetworkPolicy extend the API to support deny semantics.
• External domain endpoints: Workloads that need to reach external services (databases, SaaS APIs) identified by DNS hostnames cannot be segmented on their egress paths using native NetworkPolicy, since domain names are not supported.
• Identity-based access: Native controls do not provide workload identity or service-to-service authentication at the application layer. Service mesh solutions (such as Istio or Linkerd using mutual TLS via sidecar proxies) are typically required for this level of control.
• No policy violation logging: Kubernetes does not natively expose logs or statistics for network policy violations, making it difficult to feed data into intrusion detection and prevention systems (IDPS).
• DNS is open by default: The Kubernetes DNS service (used for service discovery) is accessible to every pod in the cluster by default. This creates a potential channel for exfiltration techniques such as DNS tunneling, which require specialised network security analysis to detect.

Complementary Tools and Practices

Given these limitations, a mature Kubernetes security posture typically combines native controls with additional layers:

• Extended CNI policies (e.g., Calico GlobalNetworkPolicy): Adds drop-action semantics and cluster-wide policy enforcement beyond namespace scope.
• Service mesh (e.g., Istio, Linkerd): Provides mutual TLS between services, workload identity, fine-grained traffic management, and observability through sidecar proxies without requiring application code changes.
• Admission controllers and policy engines (e.g., OPA/Gatekeeper, Kyverno): Enforce security policies at resource admission time — for example, blocking privileged containers or images from untrusted registries.
• Runtime security (e.g., Falco): Detects anomalous behaviour at runtime by monitoring system calls, providing the intrusion detection layer that native Kubernetes lacks.
• Image scanning: Integrate container image scanning into your CI/CD pipeline to catch known vulnerabilities before images reach production.
• Audit logging: Enable the Kubernetes API server audit log and ship logs to a centralised SIEM to capture all API activity for compliance and incident response.

Key Takeaways

Securing Kubernetes is not a single-step configuration task — it is an ongoing practice that spans the entire workload lifecycle. The most important principle is to understand and deliberately change the open by default posture of Kubernetes:

• Enable RBAC and apply the principle of least privilege to all users and service accounts.
• Apply default deny-all NetworkPolicies to every namespace and add explicit allow rules as needed.
• Use a CNI plugin that fully supports the NetworkPolicy API.
• Supplement native controls with a service mesh, extended CNI policies, and runtime security tooling to close the gaps that Kubernetes alone cannot address.
• Ensure policy violations, API audit events, and runtime anomalies are logged and monitored.

Kubernetes provides a strong foundation, but production-grade security requires deliberate configuration and complementary tooling layered on top of it.

Why Edge and IoT Demand a Unified DevOps Approach

Digital transformation touches every part of an enterprise—HR, finance, logistics, operations—but it is the IT function that must be the most responsive and agile. Applications are the primary vehicle through which business needs are met, which means delivering new deployments faster, with a consistent cadence, has become a strategic imperative rather than a nice-to-have.

Meeting that imperative typically involves a familiar set of modern practices:

• Containerized application packaging
• Iterative, pipeline-driven DevOps
• Microservice-based architectures
• Software-defined infrastructure
• Automation platforms for provisioning and configuration

These practices are well-understood for cloud and on-premise workloads. The challenge that edge computing and IoT introduce is extending the same discipline—continuous delivery, automated testing, rapid rollback—to environments that are physically distributed, resource-constrained, and often connected through intermittent or low-bandwidth links.

The Core Problem: Fragmented Development Methodologies

One of the most common mistakes enterprises make when expanding into edge or industrial IoT is treating those environments as entirely separate from their existing development pipeline. The result is two (or more) toolchains, two release cycles, and two sets of operational runbooks—multiplying complexity and slowing everything down.

A better model treats edge and cloud as different deployment targets for the same artifacts. Container images built and tested centrally can be deployed to edge nodes using the same orchestration tooling used in the data center. Continuous delivery pipelines can target edge clusters as just another environment, enforcing the same quality gates and rollout strategies.

This portability-first philosophy requires that the underlying platform be consistent across environments. That is where the choice of operating system, container runtime, and orchestration layer becomes critical.

Why Open Source Is the Only Practical Foundation

Proprietary stacks can introduce vendor lock-in that actively undermines portability. An application packaged for one vendor’s edge gateway may not run without modification on another vendor’s hardware—defeating the entire purpose of containerization.

Open-source software provides several structural advantages in this context:

• Portability: Open standards and open container formats (OCI) mean workloads are not tied to a specific vendor’s runtime.
• Security transparency: Open codebases allow the security community to audit, find, and fix vulnerabilities faster.
• Breadth of features: A large contributor ecosystem means edge-specific capabilities (hardware accelerator support, real-time kernels, LoRa/5G networking drivers) are developed and maintained by those closest to the hardware.
• Vendor independence: Organizations retain the ability to switch hardware vendors or cloud providers without rewriting their application layer.

SUSE’s Position in the Edge and IoT Stack

SUSE was among the first vendors to ship an enterprise Linux distribution, and it has extended that lineage into edge and IoT scenarios. The portfolio relevant to edge DevOps (as described in the original 2020 source material) includes several components:

SUSE Embedded Linux

An embedded Linux operating system designed for IoT and Industrial IoT (IIoT) devices. The goal is to provide a production-grade, security-hardened Linux foundation on resource-constrained hardware—the same kernel lineage that runs in the data center, adapted for the constraints of embedded and edge deployments.

SUSE CaaS Platform

A Kubernetes-based container-as-a-service platform that, per the source material, can be used to build and deliver applications targeting edge environments. Running Kubernetes-compatible orchestration at the edge allows teams to reuse the same deployment manifests, Helm charts, and CI/CD integrations they already use for cloud workloads.

Cilium-Based Advanced Networking

The source material references SUSE’s use of Cilium—an open-source project that provides eBPF-based networking, observability, and security for Kubernetes clusters. At the edge, network policy enforcement and east-west traffic visibility are especially important because edge nodes frequently operate in less-controlled network environments than a typical data center.

SUSE Cloud Application Platform

A platform-as-a-service layer (based on Cloud Foundry at the time of writing) that abstracts infrastructure details away from developers, enabling faster application delivery across cloud and on-premise targets.

Edge-Specific Technical Considerations

Several characteristics distinguish edge deployments from traditional data center or cloud workloads, and DevOps tooling must account for all of them:

Bandwidth and Latency Constraints

Edge nodes frequently sit on expensive or unreliable WAN links. Pushing every byte of raw sensor data to a central cloud for processing is economically and technically impractical at scale. Local pre-processing—filtering, aggregation, anomaly detection—reduces the volume of data that must traverse the WAN and enables real-time decision-making that a round-trip to the cloud cannot support.

Real-Time and Deterministic Requirements

Industrial, medical, and autonomous-vehicle applications often have hard real-time requirements. A general-purpose Linux kernel may need to be configured with real-time patches (PREEMPT_RT) or replaced with a real-time kernel variant to guarantee deterministic response times. Operating system choice matters here in a way it simply does not for a typical web application.

Remote Fleet Management

When a fleet of edge devices is spread across geographies—remote utilities, retail locations, transport hubs—manual updates are not a viable operational model. Automated over-the-air (OTA) update mechanisms, integrated with CI/CD pipelines, are essential for maintaining security and feature currency across the fleet without requiring on-site visits.

Machine Learning at the Edge

Running inference workloads locally—rather than sending data to a central ML service—reduces latency and bandwidth usage. Edge ML pipelines typically involve training models centrally (using aggregated data), then deploying optimized model artifacts to edge nodes where inference runs locally. Platforms that support GPU or neural processing unit (NPU) passthrough into containers simplify this workflow considerably.

In combination with communications technologies like 5G (low latency, high throughput) and LoRa (long range, low power), locally-running ML models can generate actionable insights from IoT sensor streams without a constant cloud dependency.

Applying DevOps Principles to Edge Deployments

The principles of DevOps translate to edge environments, though the implementation details differ:

Key Takeaways for DevOps Engineers

• Unify your pipeline. Resist the temptation to build a separate toolchain for edge. Treat edge nodes as deployment targets within your existing CI/CD system.
• Choose a portable base. An open-source, standards-compliant OS and container runtime reduces the risk of being locked into hardware or cloud vendor decisions made today.
• Design for disconnected operation. Edge deployments will lose connectivity. Applications, update mechanisms, and observability tooling must degrade gracefully and recover automatically.
• Account for real-time requirements early. Retrofitting real-time kernel support into a production edge deployment is painful. Understand latency requirements before selecting the OS layer.
• Automate fleet management from day one. Manual update processes that are acceptable for a handful of edge devices become untenable at hundreds or thousands. Build OTA update automation before the fleet scales.

Further Reading

For more detail on SUSE’s edge and IoT offerings, refer to the SUSE Edge Computing solutions page. For background on the Cilium networking project referenced above, see the Cilium project website. The original article appeared on TechHQ.

The VA’s DevOps Challenge Is Fundamentally a People Problem

When most organizations talk about DevOps adoption, they reach for tooling: CI/CD pipelines, container orchestration, infrastructure-as-code. The Department of Veterans Affairs is taking a different approach. According to Patty Craighill, the VA’s Director of DevOps Implementation, the hardest — and most important — part of the agency’s digital modernization is transforming its workforce and culture, not its technology stack.

Speaking at the March 2020 ATARC Federal DevOps Summit, Craighill was direct about where her energy goes: “My biggest focus has been the people … issues of workforce transformation and how to modernize the workforce. And that led into adopting DevSecOps and product line management at the VA and thinking about the impact that has on our workforce.”

Culture Change Before Tool Adoption

A recurring theme in Craighill’s remarks is that DevSecOps cannot be installed like a software package. Cultural preconditions — trust, autonomy, and a tolerance for iteration — have to exist before technical practices take root.

“Moving to DevSecOps is really a culture change. And if you don’t do the culture change, the rest of it won’t matter because it’s really hard getting everyone’s mindset to the right frame.”

— Patty Craighill, Director of DevOps Implementation, VA

This is a well-documented friction point in federal IT: hierarchical management structures and risk-averse procurement cultures are often at odds with the iterative, feedback-driven model that DevOps requires. At the VA — one of the largest civilian agencies in the US federal government — this tension is amplified by organizational scale and the high stakes of the systems involved.

Craighill described the trust component as bidirectional and non-trivial: “It’s about building trust across the organization from the top down among the people — leaders trusting the people who are working for them, and the people who are doing the everyday jobs trusting their leaders are giving them good direction. That’s not actually so easy to do if you don’t already have a culture of trust and autonomy.”

Breaking the Waterfall Funding Mindset

One structural obstacle Craighill identified is the traditional federal funding cycle, which pushes agencies to define and lock down project requirements and costs up front — an approach fundamentally incompatible with agile and DevOps delivery models.

“We’ve spent years in this framework where we put all our money up front. Then we want to protect it, so we’ve invested in building a certain capability. We don’t want it to vary at all because we’ve predicted how much it’s going to cost, and we want to get to the end state and be done with it in the amount of money and time that we’ve projected.”

— Patty Craighill

The shift DevOps demands is a philosophical one about what project success looks like. Rather than reaching a fixed endpoint on time and on budget, success in a DevOps model means establishing the organizational capacity to keep improving continuously.

“The new way throws all of that out and says: get into your customers’ head, make room for change, we don’t have to nail everything down up front. Success is not getting to the end point, but getting into a state of continual change and continuing to take risks. So you’re setting your organization up to keep improving and keep adding.”

— Patty Craighill

Mastery Teams: Training That Sticks

One of the most concrete workforce initiatives Craighill described is the concept of mastery teams — a training model designed to solve a problem every L&D team knows well: skills acquired in isolation decay quickly when they aren’t applied immediately.

“We’ve come up with the concept of ‘mastery teams,’ which is the idea that if you’re going to get training — particularly technical training — and don’t use it right away, it’s almost worthless. You forget, and it’s hard to go back and remember what you learned. So mastery teams embody the concept of going to training as a team, and then being able to use what you learned in training right away.”

— Patty Craighill

The mastery team model addresses this by ensuring that training is cohort-based and immediately actionable. Teams attend training together and are set up to apply new skills to real work directly afterward — compressing the gap between learning and practice to near zero. This is consistent with established principles in workplace learning, though the VA’s specific implementation details were not published in the source material.

Change Teams: Bridging Old Processes and New Practices

Alongside mastery teams, Craighill introduced the concept of change teams — volunteer groups tasked with working through the practical governance questions that arise when an organization tries to apply DevOps in a federal context.

These are not abstract process discussions. Adopting DevOps at a federal agency raises concrete questions around cost accounting, budget allocation, and acquisition — all of which are governed by rules that were written with waterfall delivery in mind.

“How do we do cost control, how do we do budgeting? And how do we do acquisition differently when we start doing DevOps? So all of these ideas we turned into change teams where we invited volunteers to work with us.”

— Patty Craighill

The volunteer model is notable: it creates internal advocates rather than imposing top-down mandates, and it surfaces practitioners who are already motivated to solve these problems.

Extending DevOps Beyond Central IT: Legacy and Cloud

The VA’s longer-term goal is to push DevOps and Agile practices beyond its central Office of Information and Technology into regional and local operations — particularly as the agency migrates workloads from private data centers to the cloud.

Recognizing that not all VA systems will move to the cloud immediately, Craighill outlined a plan to create reference implementations of DevOps tooling and practices on legacy environments — essentially staging environments distributed across VA regions where staff can safely experiment before cloud migration occurs.

“We have a lot of systems that are not in the cloud yet, so we’re going to establish some reference implementations using DevOps tools and practices on legacy environments so folks who aren’t yet on the cloud can practice these principles. We’re going to establish those in regions across the country so there are places where folks can go and try out the tools … We’re trying to make those available to anyone who wants to experiment.”

— Patty Craighill

This is a pragmatic acknowledgment that cloud migration and DevOps adoption do not have to be sequential. Teams can begin internalizing DevOps practices on existing infrastructure, reducing the learning curve at the point of cloud transition.

Key Takeaways for DevOps Leaders in Large Organizations

• Culture precedes tooling. Without a foundation of organizational trust and a tolerance for iteration, DevOps tools won’t produce DevOps outcomes.
• Training must connect immediately to practice. Cohort-based mastery teams that apply skills right after training are more effective than individual classroom learning with delayed application.
• Governance gaps are real blockers. Change teams that tackle acquisition, budgeting, and cost accounting within existing regulatory frameworks are as important as technical enablement.
• Cloud migration and DevOps adoption can run in parallel. Reference implementations on legacy environments let teams build skills before migration, not only after.
• Volunteers create internal momentum. Inviting motivated practitioners into change efforts builds advocates rather than resistors.

The VA’s approach underscores a lesson that applies well beyond the federal sector: at organizational scale, the human side of a DevOps transformation is almost always the longer pole in the tent.

CircleCI Brings AWS GovCloud Support to Its Server Product

CircleCI announced the availability of AWS GovCloud support as part of a broader set of updates to its self-hosted server solution. The addition is significant for U.S. government agencies, defense contractors, and heavily regulated industries — such as healthcare, finance, criminal justice, and energy — that need a modern CI/CD platform without compromising on compliance.

What Is AWS GovCloud?

AWS GovCloud is an isolated AWS region designed specifically to host sensitive data and regulated workloads for U.S. government customers. It is built to comply with a wide range of federal security and regulatory frameworks, including:

• FedRAMP – Federal Risk and Authorization Management Program
• ITAR – International Traffic in Arms Regulations
• DoD SRG – Department of Defense Security Requirements Guide
• CJIS – Criminal Justice Information Services
• HIPAA – Health Insurance Portability and Accountability Act

With this announcement, CircleCI server installations on AWS can be configured to run within the GovCloud region, giving agencies the controls needed to satisfy these regulatory requirements while modernizing their software delivery pipelines.

Why This Matters for Government DevOps Teams

Government development teams have historically relied on older, on-premises CI systems that, while sometimes free to license, carry significant operational overhead. Maintaining, patching, and scaling these legacy tools often consumes engineering time that could be spent delivering better public services.

CircleCI CEO Jim Rose addressed this directly at the time of the announcement:

“Previously, government developers were forced to rely on cumbersome, legacy CI options that, while free, required too much overhead, were costly to maintain and diminished productivity. Now, the government’s developer community can gain the same competitive advantage long available to the private sector, assured of the security and privacy controls that federal agencies require.”

— Jim Rose, CEO, CircleCI

Compliance Context: FedRAMP and SOC 2

The GovCloud support was announced alongside CircleCI’s SOC 2 compliance milestone. CircleCI had also previously become the first CI/CD solution to achieve FedRAMP certification — a certification that occurred approximately 18 months before this announcement, according to the original report. Together, these credentials position CircleCI as one of the most compliance-ready CI/CD platforms available to federal customers.

Federal Agencies Already Using CircleCI

According to CircleCI, several federal agencies were already using the platform to automate their build, test, and deployment workflows at the time of the announcement, including:

• Small Business Administration (SBA)
• General Services Administration (GSA)
• Department of Veterans Affairs (VA)

Ryan Hilliard, IT Specialist and Systems Developer at the Small Business Administration, offered a practical perspective on the total cost of ownership argument:

“Federal managers need to start thinking about the total cost of ownership for their development tools. We chose CircleCI after trying several different build tools, ranging from totally free open source tools to managed services. CircleCI just works, and that means our team only has to focus on building better government services. The total cost of ownership is much lower for a service like CircleCI.”

— Ryan Hilliard, IT Specialist/Systems Developer, Small Business Administration

Federal Cloud Spending Backdrop

The announcement came against a backdrop of growing federal investment in cloud infrastructure. Federal government spending on cloud infrastructure, platforms, software, and support services was projected to reach $7.1 billion in fiscal year 2020, according to figures cited in the original report. This context underscores the scale of opportunity — and responsibility — for DevOps tooling vendors serving the public sector.

Key Takeaways for DevOps Engineers in Regulated Environments

• CircleCI Server can now be deployed within AWS GovCloud, satisfying a broad set of federal compliance requirements.
• Agencies subject to FedRAMP, ITAR, CJIS, DoD SRG, or HIPAA can now use a modern CI/CD platform without building a custom compliance wrapper around a legacy tool.
• The total cost of ownership argument for managed CI/CD versus self-maintained open-source tooling is particularly relevant for government teams with limited platform engineering resources.
• SOC 2 and FedRAMP certifications provide independent third-party validation of CircleCI’s security and operational controls.

Platform9 Partners with Promark to Expand Kubernetes and OpenStack Distribution

Platform9, a provider of managed Kubernetes and OpenStack services, has signed a distribution agreement with Promark Technology, a subsidiary of IT distribution giant Ingram Micro. The deal gives Platform9’s two flagship products — Platform9 Managed Kubernetes (PMK) and Platform9 Managed OpenStack (PMO) — access to Promark’s established network of value-added resellers (VARs) and channel partners across the United States.

Why the Deal Matters for Platform9

According to Kamesh Pemmaraju, Platform9’s head of product marketing, the primary challenge the company faced before the Promark deal was market awareness. Despite offering what he described as a compelling managed solution, many potential customers were unaware that Platform9 existed — and were instead attempting to build and operate their own Kubernetes environments independently.

“People don’t know about us. We have a very compelling solution but customers don’t know we exist… they try to build this on their own and find it hard to do.”

— Kamesh Pemmaraju, Head of Product Marketing, Platform9

Pemmaraju positioned Platform9’s value proposition as an “easy button” for Kubernetes deployments — a fully managed alternative for organizations that discover, often painfully, that self-managing Kubernetes at scale is far more complex than anticipated. By leveraging Promark’s extensive channel ecosystem, Platform9 gains access to training programs, marketing infrastructure, partner services, and a broad reseller base that would take years to build independently.

What Platform9 Offers: PMK and PMO

Platform9’s two core products address two of the most operationally demanding open-source infrastructure technologies:

• Platform9 Managed Kubernetes (PMK): A SaaS-delivered managed Kubernetes service that supports deployments across public cloud, hybrid cloud, private cloud, and on-premises environments. The service is designed to abstract away the operational complexity of cluster provisioning, upgrades, and lifecycle management.
• Platform9 Managed OpenStack (PMO): A managed service that enables organizations to stand up an OpenStack private cloud in minutes, with Platform9 taking responsibility for the full OpenStack lifecycle — including updates, patches, and operational monitoring.

Both products are targeted at enterprises that want the capabilities of these open-source platforms without the significant engineering overhead typically required to operate them reliably.

Promark’s Perspective: Meeting Channel Partner Demand

Jeffrey Brown, President and General Manager of Promark Technology, framed the partnership as a direct response to demand from Promark’s channel partners for cloud-native solutions that help end customers navigate hybrid cloud strategies.

“Our channel partners and resellers look up to us for new born-in-the-cloud technologies. Many organizations search for efficient and affordable ways to implement a hybrid cloud strategy and our partners are there to help them with this mission. Platform9’s managed Kubernetes platform provides a fully automated solution to tackle the challenges of hybrid cloud environments.”

— Jeffrey Brown, President and General Manager, Promark Technology

Brown highlighted the combination of automation, simplified deployment, and cost efficiency as the key attributes that make Platform9’s offering attractive to Promark’s reseller base and their enterprise customers.

Industry Analyst View: Addressing the Kubernetes Skills Gap

Tony Iams, an IT analyst with Gartner at the time of reporting, noted that the deal reflects a broader market dynamic: as Kubernetes adoption accelerates, many organizations lack the in-house engineering expertise to deploy and maintain production-grade Kubernetes clusters.

“As the use of Kubernetes proliferates, organizations that lack the engineering resources to deploy and maintain Kubernetes clusters seek out managed service providers such as Platform9 to automate management of container systems on-premises or in public clouds. By leveraging Platform9’s PMK SaaS offering, Promark will make Kubernetes available to a wider base of mainstream users.”

— Tony Iams, IT Analyst, Gartner (via Channel Futures, February 2020)

Rollout and Availability

At the time of announcement, both PMK and PMO were immediately available through Promark’s distribution channel. Promark’s sales teams had begun training on Platform9’s product portfolio, with additional VAR onboarding sessions scheduled to follow shortly after the announcement.

Context: The Managed Kubernetes Market in 2020

This distribution deal reflects the wider challenge enterprises faced in the early 2020s: Kubernetes had become the de facto container orchestration standard, but operating it reliably required deep expertise in networking, storage, security, and cluster lifecycle management. Managed Kubernetes services — whether from hyperscalers like AWS (EKS), Google (GKE), and Microsoft (AKS), or from independent providers like Platform9 — emerged to bridge that skills gap. For organizations running workloads on-premises or in hybrid environments where hyperscaler-native managed services were not an option, providers like Platform9 offered an alternative path to operational Kubernetes without building a dedicated platform engineering team.

The Promark partnership gave Platform9 a channel-sales mechanism to reach those organizations at scale, particularly mid-market enterprises that typically engage with IT distributors and VARs rather than purchasing directly from vendors.

Background: The DevSecOps Gap ZeroNorth Aimed to Close

As DevOps practices matured throughout the late 2010s, one persistent challenge remained: security teams and development teams were operating in separate silos, using different tools, speaking different languages, and working at different velocities. ZeroNorth positioned itself as a solution to this gap by offering what it described as risk-based vulnerability orchestration — a platform designed to aggregate, correlate, and prioritize security findings across an organization’s entire application and infrastructure portfolio.

At RSA Conference 2020, one of the security industry’s flagship annual events, ZeroNorth used booth #5360 in Expo Hall North to demonstrate its platform capabilities to DevOps engineers, security practitioners, and technology leaders.

“Since software has become such an integral part of our daily lives, the importance of strong software security cannot be overstated. Software powers cars and airplanes, is responsible for personal financial and healthcare information, plays a number of different roles in the political process and elections, and much more — so it better be secure. As DevOps culture continues to take hold, it has never been more important to make sure security and development teams work closely. And as shifting realities push them apart, ZeroNorth is bringing them back together.”

— John Worrall, CEO, ZeroNorth

Core Platform Capabilities Demonstrated at RSA 2020

ZeroNorth highlighted four key areas of platform functionality during the conference. Each addresses a distinct pain point in enterprise application security programs.

1. Rapid AppSec and Open Source Tooling

One common barrier to launching an application security (AppSec) program is the time and cost involved in procuring, configuring, and integrating scanning tools. ZeroNorth addressed this by embedding open source scanning tools directly within its platform. This approach allows organizations to start running security scans against their applications and infrastructure quickly, without the overhead of standing up and maintaining individual tools independently.

For DevOps teams, this matters because it lowers the activation energy required to introduce security into a CI/CD pipeline — a foundational step in any shift-left strategy.

2. Vulnerability Ingestion, Correlation, and Compression

A significant operational problem in enterprise security programs is alert fatigue and duplicated effort. Multiple scanning tools — SAST, DAST, SCA, and infrastructure scanners — often flag the same underlying vulnerability in different ways, generating thousands of redundant findings that overwhelm development backlogs.

ZeroNorth’s platform ingested findings from disparate tools and correlated them to eliminate duplication. Related issues were compressed into a single “unit of work” — a developer-facing ticket or task representing one underlying problem, regardless of how many tools reported it. This directly reduces remediation burden and makes it practical for developers to act on security findings without context-switching across multiple systems.

3. Target Discovery and Application Asset Mapping

Before an organization can govern its security posture, it needs to know what it has. Shadow IT, sprawling microservices architectures, and rapidly changing cloud infrastructure make maintaining an accurate asset inventory genuinely difficult.

ZeroNorth’s target discovery capability was designed to identify the scope of an organization’s technology assets — including applications, services, and infrastructure components — and map them into a coherent view. From there, assets could be grouped and aligned to business risk factors, enabling security and engineering leadership to apply appropriate governance based on the actual risk profile of each system rather than treating everything uniformly.

4. Software-Defined Security Governance

Governance in AppSec programs has traditionally relied on manual review processes, periodic audits, and spreadsheet-based reporting — none of which scale alongside modern software delivery pipelines. ZeroNorth’s platform allowed organizations to define toolsets, security gates, and policies programmatically, embedding governance decisions into the delivery pipeline itself.

Key outcomes of this approach included:

• Frictionless communication between security and development teams, with shared visibility into risk status
• Automated policy enforcement via security gates that can block or flag builds based on defined thresholds
• Consistent reporting that provides leadership with a coherent, auditable picture of organizational risk over time

The TCO Calculator: Quantifying the Cost of Vulnerability Programs

In addition to platform demos, ZeroNorth introduced a Total Cost of Ownership (TCO) calculator at RSA 2020. The tool was designed to help security and engineering leaders estimate the true operational cost of their existing vulnerability discovery programs — factoring in not just tool licensing, but the hidden costs of manual triage, duplicate effort, and developer time spent on remediation workflows.

This kind of cost-visibility tooling is increasingly relevant to DevOps teams making the business case for security investment. Framing security as an operational efficiency problem — rather than purely a compliance or risk concern — tends to resonate more effectively with engineering and finance stakeholders.

Why This Matters for DevOps Practitioners

The themes ZeroNorth emphasized at RSA 2020 reflect broader industry trends that remain relevant today:

• Tool sprawl is a real problem. Most organizations run multiple security scanning tools that produce overlapping, inconsistent results. Orchestration and correlation layers reduce noise and make findings actionable.
• Developers need context, not just alerts. Compressing findings into unified units of work and routing them through familiar developer tooling (issue trackers, CI pipelines) increases fix rates.
• Security governance must be automated to scale. Manually reviewing security findings at the cadence of modern CI/CD pipelines is not feasible. Policy-as-code and automated gates are prerequisites for mature DevSecOps.
• Asset visibility precedes risk management. You cannot prioritize what you cannot see. Discovery and mapping capabilities are foundational to any serious AppSec program.

About ZeroNorth

At the time of this announcement, ZeroNorth described itself as the first provider of risk-based vulnerability orchestration for applications and infrastructure. The company focused on helping enterprises unify their security tooling, reduce remediation overhead, and integrate security governance into DevOps workflows. ZeroNorth was later acquired by Devo Technology in 2021.

Note: This article is based on a February 2020 press release. Product capabilities, company structure, and market positioning may have changed significantly since publication.

Why Ansible Works Well for Network Automation

Two properties make Ansible particularly attractive in a network context:

• Agentless operation. Ansible communicates with network devices over SSH (or a vendor API where available). There is nothing to install on the managed device — a major advantage when you are working with switches and routers that do not expose a general-purpose OS.
• Low barrier to entry. YAML playbooks read almost like plain English. Network engineers who are comfortable with incremental learning — picking up IOS features as needed, for example — adapt quickly to Ansible’s model.

Ansible runs on a control node (a Linux host or WSL instance) and issues commands to one or many network devices simultaneously. Its behaviour is governed by plain-text configuration files, making it easy to version-control your automation alongside your other infrastructure code.

Key Concepts Before You Start

• Inventory — a list of the devices Ansible manages, organised into groups.
• Playbook — a YAML file describing one or more plays, each containing one or more tasks.
• Module — a reusable unit of work. Network modules such as ios_command, eos_command, and the vendor-agnostic cli_command handle interaction with specific platforms.
• Variables — stored in group_vars and host_vars directories and merged at run time, giving you fine-grained control over per-device or per-group settings.

Recommended Directory Structure

You can run Ansible with a single flat file, but that quickly becomes unmanageable. A structured layout separates concerns and scales cleanly as your device count grows. The following layout is used in the examples below:

.
├── ansible.cfg
├── group_vars
│   └── IOS_switches.yml
├── host_vars
│   └── test_sw.yml
├── inventory.yml
└── sh_arp.yml

ansible.cfg

This INI-format file overrides Ansible defaults. The most important settings for network automation are disabling fact gathering (which is designed for Linux hosts, not network devices) and pointing Ansible at your inventory file.

[defaults]
gathering = explicit
inventory = inventory.yml
retry_files_enabled = False

group_vars/IOS_switches.yml

Variables in group_vars apply to every host in the named group. Here we set the connection type to network_cli, declare the OS as ios, and supply credentials. In production, use Ansible Vault or SSH keys rather than plain-text passwords.

---
# IOS_switches variables
ansible_connection: network_cli
ansible_network_os: ios
ansible_become: yes
ansible_become_method: enable
ansible_become_password: "foobar"

ansible_user: tester
ansible_ssh_pass: foobar

host_vars/test_sw.yml

Host-level variables override group variables for a specific device. A management IP address and hostname are the minimum useful entries.

---
# test_sw variables
ipaddr: 192.168.1.108
hostname: test_sw

inventory.yml

The inventory file lists your devices and organises them into groups. A single device can belong to multiple groups, which is useful when you want to target switches by both vendor OS and network role.

---
all:
  children:
    IOS_switches:
      hosts:
        test_sw:
    IOS_routers:
      hosts:
        router1:
    access:
      hosts:
        test_sw:
    core:
      hosts:
        router1:

Writing Your First Playbook: Collecting the ARP Table

A good first automation task is read-only data collection — it is safe, immediately useful, and gives you a baseline to compare against. The playbook below, sh_arp.yml, issues show arp to every host in the IOS_switches group and prints the output.

---
- name: Gather ARP data
  hosts: IOS_switches
  tasks:
    - name: "Task 1: Get output of show arp on IOS"
      ios_command:
        commands: "show arp"
      register: cli_result

    - name: "Task 2: Display stdout_lines[0]"
      debug:
        msg: "{{ cli_result.stdout_lines[0] }}"

Key points about the playbook structure:

• ios_command sends a CLI command to an IOS device and returns the output as a string.
• register: cli_result saves the module’s return value into a variable for use in later tasks.
• The debug module prints the value of cli_result.stdout_lines[0] — a list of output lines from the first (and only) command issued.

Running the Playbook

$ ansible-playbook sh_arp.yml

Expected output:

PLAY [Gather ARP data] ***************************************************

TASK [Task 1: Get output of show arp on IOS] *****************************
ok: [test_sw]

TASK [Task 2: Display stdout_lines[0]] ***********************************
ok: [test_sw] => {
    "msg": [
        "Protocol  Address     Age (min)  Hardware Addr   Type  Interface",
        "Internet  192.168.1.108       -  bcc4.933e.49c0  ARPA  Vlan1",
        "Internet  192.168.1.126       5  f894.c220.2177  ARPA  Vlan1",
        "Internet  192.168.1.133       1  88c2.55fb.9ce7  ARPA  Vlan1",
        "Internet  192.168.1.138       0  a860.b60a.7a3a  ARPA  Vlan1"
    ]
}

PLAY RECAP ***************************************************************
test_sw                    : ok=2    changed=0    unreachable=0    failed=0

The PLAY RECAP line confirms two tasks completed successfully with no changes and no failures — exactly what you want from a read-only operation.

Scaling Up: Running Across Many Devices

The real value of Ansible is not running a single command on one switch — it is running a set of tasks across dozens or hundreds of devices with a single command. Once your inventory is populated, the same playbook targets every matching host automatically.

Practical use cases that are well suited to this pattern include:

• Compliance auditing. Verify that device configurations match a known-good template — for example, that QoS policies or MPLS route targets are consistent across the fleet.
• Inventory and documentation. Collect show version output from every device and store it to disk. You immediately have a searchable record of firmware versions, model numbers, and serial numbers.
• MAC and IP address tracking. Save show arp and show mac address-table dynamic output, then use grep to locate any device on the network by its IP or MAC address across hundreds of output files.
• Configuration generation and deployment. Combine Ansible with the Jinja2 templating language to dynamically render device configurations and push them across the network.

Beyond the Basics

The example above covers a small fraction of what Ansible can do for network teams:

• Ad hoc mode. Run a single module against an inventory group without writing a playbook — useful for quick checks during troubleshooting.
• Ansible Vault. Encrypt sensitive files such as credential variables so that secrets are never stored in plain text.
• Filters and plugins. Parse structured output, transform data, and extend Ansible’s capabilities beyond its built-in modules.
• Jinja2 templating. Generate device-specific configuration files from a single template, replacing manual copy-paste workflows.
• Roles. Package related tasks, variables, and templates into a reusable unit that can be shared across projects or published to Ansible Galaxy.

Nick Russo’s tutorial, Automating Networks with Ansible the Right Way, is frequently cited as a useful resource for engineers who want to move beyond basic playbooks into areas such as maintaining MPLS configurations with Ansible.

Getting Started: Recommended Approach

1. Install Ansible on a Linux control node (or WSL on Windows).
2. Build the directory structure shown above with a single test device in your inventory.
3. Start with the read-only ARP collection playbook and confirm it works.
4. Expand to additional show commands and save results to files using the copy or template modules.
5. Once comfortable, explore write operations — start with non-production devices and always test with --check mode where supported.

Ansible’s official Ansible for Network Automation documentation section is the authoritative starting point. It links to a getting-started guide, an advanced topics guide, and a full list of network modules organised by vendor and platform.

Summary

Ansible is a practical choice for network automation: it is agentless, uses SSH, and its YAML-based playbooks are no harder to learn than many networking concepts you already know. Starting with simple read-only tasks — collecting ARP tables, documenting firmware versions, auditing configurations — gives you immediate value with minimal risk. As your confidence grows, the same tool scales to configuration deployment, compliance enforcement, and full network lifecycle management.

Three Pillars of Continuous Delivery Success

Ten years after the publication of Continuous Delivery by Dave Farley and Jez Humble, the two authors took the stage at DeliveryConf to reflect on progress made and lay out what they believe the next decade must look like for CD to mature across the industry. Their central argument: succeeding with CD is not a purely technical problem. It demands simultaneous progress across three deeply interrelated dimensions—technical performance, organizational performance, and cultural performance.

Research from DORA (DevOps Research and Assessment) supports this framing. Technical practices can lead the way, but they cannot drive lasting change on their own. Organizations that neglect the human and structural dimensions of delivery will hit a ceiling regardless of how sophisticated their tooling becomes.

What the Deployment Pipeline Actually Means

A common misreading of Farley and Humble’s original book is that teams should build a separate pipeline for each environment. Farley called this an anti-pattern. The deployment pipeline is meant to be a single mechanism: changes enter at one end, and releasable software emerges at the other. The goal is the continuous delivery of ideas—fast, validated feedback from real users telling you whether your assumptions were correct.

In the decade since the book was published, several practices have grown up around this core model, including distributed tracing, chaos engineering, and traffic shifting (canary releases and feature flags). These techniques all serve the same underlying purpose: reducing the risk and cost of change while accelerating the feedback loop.

“Teams need to have a great story on these technical practices to have great technical performance, which is a necessary driver for CD.”

— Dave Farley, DeliveryConf

Technical Performance: Engineering Discipline at the Core

Farley frames software development as fundamentally about two things: learning and managing complexity. Effective CD practices must optimize for both.

• Optimizing for learning: Use fast feedback loops, work incrementally, and run controlled experiments. The smaller the batch size, the quicker you learn whether a change delivers value.
• Managing complexity: Apply sound architectural principles—modularity, separation of concerns, high cohesion, and loose coupling. These properties make systems easier to change safely and independently.

“It’s about engineering—applying rational scientific thinking to solving practical problems within economic constraints.”

— Dave Farley, DeliveryConf

Organizational Performance: Structure Enables Autonomy

Even technically excellent teams will struggle to deliver continuously if the organizational structure works against them. Farley defines organizational performance as building team structures that enable genuine collaboration and sufficient autonomy. Teams that must constantly coordinate with other teams to ship a change are structurally constrained from practicing CD.

Farley referenced The Art of Action by Stephen Bungay as a useful model for understanding this challenge. Organizations pursue outcomes through plans and actions, but three gaps inevitably appear: a knowledge gap (not knowing enough to plan perfectly), an alignment gap (people acting on different interpretations), and an effects gap (actions not producing the expected outcomes). These gaps cannot be eliminated, but they can be reduced—through tighter feedback loops, smaller batches of work, and clearer intent communicated throughout the organization.

Cultural Performance: The Hardest Problem

Cultural performance—how teams behave, how diversity of thinking is valued, and how technical rigor is maintained day-to-day—is the dimension most frequently underestimated. Farley referenced a Harvard Business Review article arguing that the biggest impediment to adopting agile practices is not a lack of methodology, evidence, or proof of concept. It is executive behavior.

“Organizations can’t succeed at doing CD on one of these aspects without the others.”

— Dave Farley, DeliveryConf

The audience discussion at the end of the session surfaced practical strategies for influencing executive behavior:

• ROI and cost analysis: Quantifying the business value of CD—reduced lead time, lower failure rates, faster recovery—gives executives a concrete case to evaluate. This is often a necessary starting point.
• Reframe the conversation: Farley argued that you will not win senior leaders by talking about deployment pipelines. You win them by talking about the organization’s ability to evolve and respond to market change.
• Generate an emotional response: One audience member pointed out that ROI alone rarely changes culture. The classic observation applies here: culture eats strategy for lunch. Leaders need to feel the urgency of change, not just see a spreadsheet justifying it.

Humble’s Expectation: Real Continuous Integration First

Jez Humble stressed that one of his most important expectations for the next decade is straightforward but widely ignored: teams should actually practice Continuous Integration as it is defined. That means developers integrate their work into a shared mainline branch—or merge feature branches into the mainline—at least once per day. When the build breaks, it is fixed within approximately ten minutes. Reliable, automated tests validate every change.

Without this foundation, the rest of the CD pipeline is built on unstable ground. Long-lived feature branches, infrequent merges, and flaky test suites are among the most common reasons CD initiatives stall before they deliver value.

Feedback as the Engine of Innovation

Humble also emphasized that fast feedback is not just an operational concern—it is critical to innovation. Most new ideas turn out to be wrong. The faster an organization can find that out, the less waste it produces and the sooner it can pivot to something better.

In Accelerate, Humble, Nicole Forsgren, and Gene Kim describe the goal of modern product delivery this way:

“Product delivery is about building an engine that gives you quality feedback promptly, enabling a deterministic flow from development to production—this is the engine where product ideas bake in.”

— Accelerate, Forsgren, Humble, and Kim

Key Takeaways for Practitioners

• A deployment pipeline is a single end-to-end mechanism, not a separate pipeline per environment.
• Technical, organizational, and cultural performance are inseparable. Invest in all three or expect diminishing returns.
• Reduce knowledge, alignment, and effects gaps by working in smaller batches and communicating intent clearly.
• Architects and engineers should optimize for learning (fast feedback, incremental work) and for managing complexity (modularity, loose coupling).
• Genuine CI—daily integration into a shared mainline with fast automated tests—is a prerequisite for everything else.
• To influence executives, speak in terms of business agility and market responsiveness, not deployment frequency metrics alone.

Source: InfoQ coverage of DeliveryConf, featuring Dave Farley and Jez Humble.

Android device and deployment application management company Esper announced a $7.6 million Series A funding round. According to the company, the funding will help it provide a full stack development and management platform for Android edge devices.

Esper explained that the overall edge market is growing 26% annually with more than 7 million developers worldwide working on applications for Android edge devices such as tablets, kiosks, point-of-sale, and mobile payment devices. By 2024 it is expected that there will be over 200 million Android devices deployed in the dedicated device space.

RELATED CONTENT:
Edge and cloud: A power couple
Technology advances and demands for speed are driving enterprises to the edge

“This market is growing quickly as consumers and employees rely on these devices to get specific jobs done. Right now these fleets of devices are relying on home grown solutions for updating and maintaining which doesn’t scale,” Yadhu Gopalan, the CEO of Esper, told SD Times. “Esper is a modern approach to developing and deploying these apps.”

Esper aims to provide a platform for the creation, deployment, updating, and monitoring of remote smart touch-screen devices and their associated applications and firmware.

“With real-time monitoring and staged and fine-grained control of deployments to a large fleet of edge devices customers can iterate and scale their device fleet faster,” Gopalan said. “By automating many of the common monitoring scenarios we also allow customers to reduce their operational overhead.”

In addition to its application and operating system updates and device and fleet management solutions, Esper allows for secure/authenticated real-time diagnosis and debugging of the remote device.

“We understand environmental and site-specific issues during deployment and want to fully support developers,” Gopalan said. “All of the core functionality of Esper can be performed by a cloud-based dashboard or through APIs/CLI.”

Engineering and operations teams can use Esper to increase business agility, automate previously manual processes using telemetry for analytics, alerts, and actions to increase fleet uptime and reliability, diagnose deployed applications and devices in real-time, and reduce the resources needed to intelligently deploy and scale device fleets, Gopalan explained.

Gopalan said that the company also plans on adding more integration with third-party back-end tooling.

Also, with Esper Enhanced Android, the platform can seamlessly enroll and manage devices to achieve no-touch drop-ship directly from the factory to deployment sites and addresses the challenge of receiving and managing timely Android system updates for increased security and uptime.

Chef has revamped its channel approach, rolling out a new partner program that addresses inconsistencies in the company’s previous partnering efforts; more IT channel news.

Chef, a DevOps tool provider, has launched a new channel program that the company said provides a uniform structure for working with its nearly 500 Chef partners, which include systems integrators, managed service providers and resellers.

Chef, based in Seattle, offers four tools covering various facets of DevOps and DevSecOps. Chef Infra automates infrastructure configuration, Chef InSpec automates security and compliance, Chef Habitat automates application lifecycle management and Chef Automate provides a DevOps dashboard for operational visibility. Chef partners typically use the tools on digital transformation projects in which they help customers adopt modern software development practices.

Chef had been offering Chef Infra, InSpec and Habitat on an open source basis, but in 2019 extended open source licensing to Chef Automate, which originated as a propriety product. The previously mixed licensing model contributed to an uneven partnering approach, which Chef is looking to remedy with its revised program.

“We had no consistent way of interacting with these partners,” said Vikram Ghosh, vice president of business development at Chef.

The previous channel effort relied heavily on partner managers. But when a manager moved to a different job within Chef or left the company, the relationship with the partner would “go sideways,” Ghosh said.

The larger issue, however, was a conflict with service-oriented Chef partners who saw value in the vendor’s open source tools but were asked to sell the Chef Automate observational layer. The revised partner program, which builds upon the company’s 100% open source approach, aims to align Chef’s business model with partner needs, Ghosh said.

Components of the Chef Partner Program include a co-sell incentive model for partners who don’t wish to pursue product transactions as part of their service offerings. The program also includes support for the recurring revenue model and co-marketing opportunities as well as sales/technical enablement programs and tools.

Chef’s channel program offers three partner tiers: Principal, Senior and Junior. Top-level Principal partners are those that deliver “great customer outcomes” with Chef, differentiate themselves through integration with Chef’s technology partners and take advantage of Chef’s go-to-market programs, Ghosh said. Chef’s technology partners include Cloudbees, HashiCorp and Jenkins.

Channel partners play a number of roles in the Chef ecosystem. For one, they provide resources for delivering and supporting Chef technology. “From our standpoint, we are a relatively small company,” Ghosh said. “We need the scale that our partners provide.”

Systems integrator partners help customers integrate Chef’s offerings into the broader DevOps tool chain and CI/CD pipeline, he noted. MSPs, for their part, help customers manage the system an integrator sets up. “Customers don’t want to manage the underlying system that is delivering a business outcome,” Ghosh said.

The need for DevOps managed services has contributed to an SI-to-MSP shift, he added.

The Chef Partner Program in the coming months plans to highlight partner success stories through its marketing channels, including blog posts, events and webinars. Some of those stories, Ghosh said, will focus on SIs that found ways to provide ongoing services that drive recurring revenue.

Digital transformation projects, DR and marketing spell channel work
A channel partner to-do list might include restarting stalled digital transformation projects, boosting customer confidence in disaster recovery, and investing in sales and marketing — based on the results of industry surveys released this week.

Forty-two percent of the 293 U.S.-based IT decision-makers polled in a survey sponsored by Ahead, an enterprise cloud solutions provider based in Chicago, said they struggle to achieve success in digital transformation. The most-cited stumbling blocks are legacy systems and technical debt, according to the survey, which Hanover Research conducted on Ahead’s behalf. Overall, 67% of respondents identified infrastructure as a big part of their digital transformation strategies.

A US Signal survey, meanwhile, revealed three-quarters of the 110 U.S.-based IT decision makers it polled now use backup and disaster recovery from a third-party edge data center provider. That said, a significant portion of the respondents were not completely at ease with the business continuity offerings they’ve purchased. Fifty-four percent said they are somewhat or not very confident in their DR and backup solutions in the event of cyberattacks, outages or other incidents.

The survey from US Signal, a data center services provider, based in Grand Rapids, Mich., also noted 66% of respondents reported operating a hybrid IT infrastructure, while 20% said they were entirely in the cloud and 14% said they were entirely on-premises.

Beyond infrastructure issues, the MSP portion of the channel continues to grapple with sales and marketing. The North American MSPs surveyed in a SolarWinds report listed sales, lack of resources and marketing as their biggest growth obstacles. The results are consistent with other service provider surveys that have also cited sales and marketing as an MSP challenge.

The SolarWinds survey, conducted in conjunction with The 2112 Group, also pointed to patterns in MSP security. North American respondents said they were most comfortable offering and using antivirus, firewalls, data backup and recovery, and endpoint security. They were the least comfortable with biometrics, cloud access security brokers and digital rights management, according to the report.

Offshore players continue cloud consultancy purchases
Infosys, a $12 billion digital services and consulting firm based in Bengaluru, India, agreed to acquire Simplus, a Salesforce partner with headquarters in Salt Lake City.

The $250-million transaction is expected to close in the next 30 days, according to a Simplus spokesperson. Simplus offers cloud consulting, implementation, data integration, change management and training services for Salesforce CPQ and the Salesforce Billing add-on package. Simplus has offices in North America, Australia, the United Kingdom, and operates a delivery center in Manila.

The pending deal closely follows Atos’ acquisition of Maven Wave, a Google Cloud partner based in Chicago. Atos, a Paris-based IT services company, said the acquisition will bolster its cloud services footprint in North America. The Infosys-Simplus transaction is also reminiscent of Wipro Ltd.’s acquisition of Appirio, a Salesforce consulting firm, Appirio in 2016.

Other news
IBM Storage updated and consolidated its Storewize and FlashSystem products under the IBM FlashSystem brand, a move that was largely shaped by partner input, the vendor said. A company spokesperson said close to 150 partners and distributors globally gave feedback on the design and performance of the FlashSystem offering. In a blog post, Eric Herzog, IBM’s chief marketing officer and vice president of worldwide storage channels, noted the FlashSystem launch doesn’t affect IBM Storage’s go-to-market strategy. FlashSystem models 5000, 5100 and 7200 will continue to be offered exclusively through IBM business partners, he said.
Nerdio, a Microsoft Azure automation platform company that targets MSPs, closed $80 million in funding. The company said it would use the funding to drive product development and support for Microsoft Azure offerings, including Windows Virtual Desktop, as well as build out operations and resources for its channel partners. According to a Nerdio spokesperson, Nerdio expanded aggressively in the channel through 2019 by striking distributor agreements with Pax8 and Ingram Micro and pushing into international markets, such as Latin America, Belgium and the Netherlands.
TPx Communications, a Los Angeles-based MSP, has been acquired by affiliates of private equity firm Siris Capital Group. In conjunction with the acquisition, TPx said, its CEO, Richard A. Jalkut, will retire, and Siris executive partner Joseph A. Cozzolino will serve as executive chairman of the board and interim CEO.
US Signal tapped Infinidat, a data storage company based in Waltham, Mass., to provide storage arrays for a Detroit area data center scheduled to open in March 2020. US Signal already uses 12 Infinidat InfiniBox systems in seven data centers in the Midwest.
In the managed detection and response sector, eSentire Inc., based in Waterloo, Ont., launched esCLOUD, which extends its on-premises MDR offerings to cloud environments. In addition, Agio, a managed security services provider based in New York, unveiled a partnership with Respond Software. Agio is incorporating Respond Software’s technology into its MDR services.
Pax8, a cloud distribution company based in Denver, formed a partnership with Novacoast, an IT services and solutions provider. Under the arrangement, Pax8 will offer Novacoast’s novaSOC, a monitoring and alerting security service.
Atera, an IT automation platform based in New York, launched Atera Network Discovery, a tool the company said scans networks and extracts a list of business opportunities and tasks for MSPs.
Unified Office Inc., an MSP based in Nashua, N.H., developed an offering for the hospitality industry, based on its Total Connect Now business communication product. The hospitality offering will integrate with hotel management and messaging services such as Opera, Synergy and Kipsu, according to the company.
Atos is forming a systems integrator relationship with RingCentral. The companies plan to launch a co-branded unified communications as a service
Netsurion, a managed security service provider (MSSP), integrated its co-managed SIEM offering, EventTracker, with the Mitre ATT&CK cybersecurity framework. The ATTT&CK framework is a public knowledge base of threat tactics and techniques developed by Mitre Corp., a nonprofit research and development organization. Netsuiron said the integration will be available in the upcoming 9.3 release of EventTracker.
High Wire Networks, an MSSP, launched Overwatch 24/7, a new security platform for managed service providers. The platform integrates detection and response technology with High Wire Network’s security operations center as a service, the company said.
DLT Solutions, a technology aggregator and Tech Data subsidiary based in Herndon, Va., added offerings from Glasswall, Illumio, NetBrain, Parasoft, Perfect Sense, TYCHON and ZorroSign to its product roster.
Apps Associates, an MSP and Oracle cloud migration specialist, rolled out a diagnostic and management toolset, dubbed Apps Pack.
Extreme Networks signed a 10-year agreement with Gannon University to establish a regional networking training center for students and professionals. Additionally, Gannon and Extreme will integrate Extreme’s training curriculum and technical certification into the academic curriculum of Gannon’s undergraduate and graduate engineering and computing programs, the vendor said. An Extreme spokesperson noted that partners in the region will have access the facility, dubbed Extreme Academy, for on-site training. Under the partnership, Extreme will work alongside Networking Technologies, a value-added reseller (VAR) and integration, to outfit and upgrade equipment for the Extreme Academy and other Gannon academic buildings.
Axonius, a cybersecurity asset management platform vendor, appointed Mark Daggett as its vice president of channels and alliances. Dagget joins Axonius from Cylance, where he served as director of global distribution.
MSP360, a data backup and recovery solutions provider based in Lewes, Del., appointed Kate Knyazheva as head of inside sales. She joins the company from Veeam.
Matrix Integration, an IT solutions provider based in Jasper, Ind., appointed Rob Wildman as vice president of professional services.

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 Kubernetes Security Deserves Serious Attention

Kubernetes has become the de facto container orchestration platform across industries, running at scale in on-premises data centers, public clouds, and hybrid environments alike. That ubiquity creates a large and growing attack surface. Throughout 2019, a series of significant vulnerabilities were disclosed in Kubernetes itself—most notably a privilege escalation flaw discovered at the end of 2018, which allowed any authenticated user to establish a connection through the Kubernetes API server to a backend server and potentially escalate privileges.

As Gary Duan, CTO of NeuVector, put it: “Kubernetes has some basic security features—primarily around securing its own infrastructure. These include role-based access controls (RBACs), secrets management, and pod security policies. However, Kubernetes should not be deployed in business-critical environments or for applications that manage sensitive data without dedicated container security tools.”

The three tips below represent the core guidance Duan and Platform9’s Roopak Parikh offered for teams running Kubernetes at scale.

Tip 1: Enforce Role-Based Access Control (RBAC) and Network Policies

Security in a distributed system like Kubernetes requires multiple overlapping layers—there is no single control that covers everything. RBAC is the foundation, but it must be combined with network policies, authentication integration, and strong secrets management to be effective.

Connect Kubernetes to Your Enterprise Identity Provider

Parikh recommends integrating Kubernetes clusters with an enterprise authentication provider—such as an LDAP directory, Active Directory, or a single sign-on (SSO) platform. This ensures that access to cluster resources is governed by the same identity controls used elsewhere in the organization.

“A lot of times what we have seen is, you can secure all your systems all you want, but it’s also important to secure the keys—the passwords you use—with multi-factor authentication and use certificates to make sure people cannot get in through those easy doors,” Parikh said.

Assign Least-Privilege Roles and Isolate Namespaces

Each application or team should be scoped to specific namespaces, with RBAC policies that grant only the permissions required for that workload. Concretely, this means:

• Defining Role and ClusterRole objects that grant the minimum necessary verbs (e.g., get, list, watch) on only the required resources.
• Binding those roles to specific service accounts, not to broad groups.
• Using NetworkPolicy resources to restrict pod-to-pod and pod-to-external traffic to only what is explicitly needed.
• Storing application credentials in Kubernetes Secrets, and considering external secrets management systems (such as HashiCorp Vault) for sensitive production workloads.

Consider a Service Mesh for Encrypted Pod-to-Pod Communication

Duan noted that layering a service mesh such as Istio or Linkerd on top of Kubernetes can improve security by encrypting pod-to-pod communications via mutual TLS (mTLS). Service meshes also provide fine-grained traffic policies and observability. However, Duan cautioned that a service mesh introduces additional components—and therefore additional attack surface—that must themselves be secured and kept up to date.

Apply Cloud-Native Security Tools Across the Full Lifecycle

Traditional perimeter-based security tools are not designed for containerized environments. Duan recommended deploying cloud-native security tools that cover the entire application lifecycle, from the CI/CD pipeline through to runtime. For multi-cluster deployments spanning public and private clouds, federated policy management—where security policies are defined centrally and enforced across all clusters—becomes essential.

“True defense in depth is not possible without deep network visibility and protection, such as with a Layer 7 container firewall. Such a container-focused firewall will be able to detect and prevent network-based attacks, probes, scanning, breakouts, and lateral movement between containers using container micro-segmentation techniques.”

— Gary Duan, CTO, NeuVector

Tip 2: Continuously Scan for Insecure Code and Vulnerable Dependencies

Running workloads in containers does not automatically make them secure. Container images can bundle outdated OS packages, vulnerable language runtimes, or insecure application code. Parikh stressed that teams need tooling to detect these issues before and after deployment.

Scan Images at Build Time and in Registries

Integrate image vulnerability scanning into your CI/CD pipeline so that images are checked for known CVEs before they are pushed to a registry or deployed to a cluster. Many open-source and commercial tools exist for this purpose. Scans should also be run against images already sitting in your registry, since new vulnerabilities are disclosed continuously.

“You may want to scan it to figure out if there is insecure code or if you’re using an older version of a Python library. There are tools out there which can help you find out those details and give you a report on that. Based upon that, you can either deny or allow running those applications in the form of containment,” Parikh noted.

Declare Security Policy as Code

Duan highlighted that Kubernetes provides automation mechanisms that security tools should leverage. One practical approach is to declare security policy as code: capture the expected behavior of new services in a YAML manifest and deploy that policy as a Kubernetes custom resource definition (CRD). This makes security policy auditable, version-controlled, and reproducible—the same as application configuration.

Keep the Host OS and All Components Patched

The security of a Kubernetes cluster depends on the security of the nodes it runs on. Parikh emphasized that teams must keep the underlying operating system patched and use kernel security mechanisms (such as AppArmor or seccomp profiles) to restrict the capabilities available to containers. The principle of least privilege applies at every layer: the host OS, the container runtime, the Kubernetes control plane components, and the workloads themselves.

“You need to make sure that every component you install is patched and up to date.”

— Roopak Parikh, Co-founder and CTO, Platform9

Tip 3: Audit and Restrict Exposed Ports and API Endpoints

Every port and endpoint exposed by a Kubernetes cluster—whether via a LoadBalancer Service, a NodePort, an Ingress, or the Kubernetes API server itself—is a potential entry point for attackers. Parikh said Platform9 has observed real-world scanning activity against customer clusters where misconfigured or inadvertently exposed ports were probed by external parties.

“Someone figured out that something was exposed to the internet by other companies and we saw in the logs some people trying to probe our servers to figure out if those ports were open because insecure ports were open. Kubernetes itself has an API server, and in the past we have seen exposed ports,” Parikh said.

Harden the Kubernetes API Server

The API server is the central control point of any Kubernetes cluster and should never be exposed to the public internet without strict access controls. Ensure that:

• Anonymous authentication is disabled.
• The API server is accessible only over TLS with valid certificates.
• Access is restricted to known IP ranges using firewall rules or cloud security groups.
• Audit logging is enabled so that all API requests can be reviewed.

Review Every Externally Exposed Service

For each Service or Ingress that exposes a workload externally, teams should verify:

• Is this service intended to be public, or was it accidentally exposed?
• Is the exposure limited to the minimum necessary ports and protocols?
• If running in a public cloud, are the associated security groups or firewall rules as restrictive as they can be?
• Does the service require authentication before allowing access?

Automate Security Checks in the Pipeline

Duan recommended defining all integration points in the delivery pipeline where security checks should be automated, then building a roadmap to achieve complete security automation. Early steps might include triggering vulnerability scans on image builds and generating alerts on anomalous network activity. Over time, these checks can be expanded to cover admission control (using tools like OPA/Gatekeeper to reject non-compliant workloads at deploy time) and runtime behavioral monitoring.

Summary: A Layered Approach Is Non-Negotiable

Running Kubernetes safely at scale is not a single-control problem. The combination of RBAC and network policies, continuous image scanning, host-level hardening, and disciplined port management creates the overlapping layers of defense that are necessary in production environments handling sensitive workloads. As Duan summarized, traditional security tools were not built for containerized infrastructure—cloud-native tooling must be adopted across the full software lifecycle, from build to runtime.

As your cluster footprint grows across clouds and regions, invest in centralized, federated policy management so that security posture does not degrade with scale.

What Is Nutanix Karbon?

Nutanix Karbon is a curated Kubernetes distribution and management platform built on top of upstream Kubernetes. It abstracts away much of the operational complexity involved in deploying and managing Kubernetes clusters on Nutanix HCI infrastructure, making it easier for enterprise teams to run cloud-native, containerised workloads without deep Kubernetes expertise.

The Air-Gap Problem With Kubernetes

A core operational challenge with standard Kubernetes deployments is external network dependency. During cluster bootstrapping and normal operation, Kubernetes pulls container images and configuration data from public registries such as Docker Hub or gcr.io. This makes running Kubernetes in a fully network-isolated — or air-gapped — environment effectively impossible without additional tooling.

Air-gapped environments are common in:

• Government and defence networks handling classified data
• Industrial control and SCADA systems
• Financial institutions with strict regulatory segmentation requirements
• Organisations defending against ransomware and malware by physically or logically isolating workloads from internet-connected networks

Prior to Karbon 2.0, none of these environments could realistically run Karbon-managed Kubernetes clusters without some form of internet connectivity.

Karbon 2.0: Air-Gap Support Explained

Karbon 2.0 introduces the Karbon Air Gap feature, which allows Kubernetes clusters to operate in network-isolated environments by replacing the dependency on external registries with a locally hosted Docker registry.

According to Ervik Johnsen’s blog post (since removed), the architecture works as follows:

“The Air Gap uses a local Docker registry, hosted on a separate VM, to provide Karbon services. Deploying the Air Gap requires Internet access to download the deployment package from the Nutanix Support Portal and transfer it to a local web server.”

Alexander Ervik Johnsen, Nutanix Senior Systems Engineer

Deployment Workflow

The air-gap deployment process follows a standard sneakernet pattern used in secure environments:

1. Download the Karbon Air Gap deployment bundle from the Nutanix Support Portal. This requires a machine with internet access.
2. Transfer the bundle to a portable storage device (USB drive, external disk, or similar removable media).
3. Transport the storage device physically to the air-gapped site. This step can be performed by Nutanix, a certified system integrator, or the customer’s own staff.
4. Install the binaries onto a local web server within the isolated environment.
5. Serve container images from the locally hosted Docker registry VM, replacing all external registry calls.

Once the local registry is operational, Kubernetes clusters managed by Karbon pull all required images from within the isolated network, eliminating the external internet dependency entirely.

One-Click Kubernetes Version Upgrades

A historically painful operational task for Kubernetes administrators is performing in-place version upgrades. Without purpose-built tooling, upgrading Kubernetes often means redeploying entire clusters or individual applications — a disruptive, time-consuming process that many teams avoid, leading to clusters running outdated Kubernetes versions.

Karbon 2.0 addresses this directly by introducing one-click Kubernetes upgrades accessible via the karbonctl command-line tool. Administrators can trigger a Kubernetes version upgrade on an existing cluster without redeployment, reducing both downtime risk and operational complexity.

Prism Central and Active Directory Integration

Karbon 2.0 deepens integration with Nutanix Prism Central, the unified management plane for Nutanix infrastructure. Specifically, administrators can now leverage an existing Prism Central + Active Directory (AD) configuration to grant read-only Prism user access to Karbon resources.

This allows organisations to extend role-based access control (RBAC) from their existing AD infrastructure into their Kubernetes management layer without managing a separate identity system for Karbon.

Summary of Karbon 2.0 Capabilities

Why This Matters for Enterprise and Regulated Environments

The air-gap capability is a meaningful step toward making Kubernetes viable in sectors where network isolation is non-negotiable. Combined with simplified upgrades and tighter identity management integration, Karbon 2.0 positions Nutanix’s Kubernetes offering more competitively for enterprise customers who have previously been blocked from adopting container orchestration due to connectivity requirements.

For teams already running Nutanix HCI with Prism Central, these additions lower the barrier to adopting and maintaining Kubernetes clusters at scale within their existing operational workflows.

What Is DevOps?

DevOps is a cultural and organisational movement — a combination of practices, ideas, tools, and processes designed to break down the traditional silos between software development and IT operations teams. Its core goal is to enable organisations to build, test, and release software faster, more reliably, and with higher quality.

In Patrick Debois’s own framing, DevOps represents “a movement of people who think it’s time for a change in the IT industry — time to stop wasting money, time to start delivering great software, and building systems that scale and last.”

Key attributes of a DevOps culture include:

• Shared ownership — development and operations teams are jointly responsible for product quality and uptime.
• Continuous feedback loops — teams monitor production systems and feed insights back into the development process.
• Automation-first thinking — repetitive manual tasks (provisioning, testing, deployment) are automated wherever practical.
• Incremental delivery — software is shipped in small, frequent batches rather than large, infrequent releases.
• Collaborative tooling — teams share dashboards, on-call rotations, and post-mortems instead of working in isolation.

DevOps is not a specific tool, a job title, or a pipeline. It is a way of working — a cultural shift that must be adopted at the team and organisational level before any tooling decisions are made.

Why DevOps Exists: The Historical Context

Historically, development teams wrote code and then “threw it over the wall” to operations teams who were responsible for deploying and running it. This handoff model created conflict, slow feedback, finger-pointing during outages, and long release cycles. DevOps emerged as a direct response to these friction points, encouraging the two groups to collaborate throughout the entire software lifecycle rather than only at handoff moments.

DevOps in Practice: A Real-World Example

Facebook is a widely cited example of DevOps practices at scale. Its engineering approach has long emphasised code ownership, automation, incremental changes, and continuous improvement — all hallmarks of DevOps thinking. The company reportedly completed a migration of its infrastructure and back-end services to the Chef configuration management platform around 2015, allowing it to manage thousands of servers and push multiple code updates daily. Some of those Chef cookbooks were also made publicly available.

This example illustrates that DevOps is not a single tool or pipeline — it is a philosophy that shapes how an entire engineering organisation operates.

What Is CI/CD?

CI/CD stands for Continuous Integration / Continuous Delivery (and sometimes Continuous Deployment). It is a concrete set of engineering practices and automated workflows — often implemented as a “pipeline” — that enable teams to integrate, test, and release code changes frequently and reliably.

Where DevOps is the culture, CI/CD is one of the most important technical implementations of that culture. Think of DevOps as the philosophy and CI/CD as a key part of the machinery that puts that philosophy into practice.

Continuous Integration (CI)

Continuous Integration is the practice of developers merging their code changes into a shared repository frequently — ideally multiple times per day. Each merge triggers an automated build and a suite of automated tests. The goals are:

• Catch integration bugs early, before they compound.
• Keep the main branch in a consistently deployable state.
• Give developers rapid feedback on whether their change broke anything.

In their book Continuous Delivery, Jez Humble and David Farley recommend that developers check in to the main branch at least a couple of times a day. The longer a branch lives in isolation, the harder — and riskier — the eventual merge becomes.

Continuous Delivery (CD)

Continuous Delivery extends CI by ensuring that every change that passes automated tests is also automatically prepared for release to production. Critically, the final push to production still requires a human decision. A staging or pre-production environment is typically used for user acceptance testing (UAT) or manual review before deployment is approved.

The key benefit of Continuous Delivery is that releases become low-risk, routine events rather than high-stakes, infrequent ordeals. Because the software is always in a releasable state, the business can choose when to ship based on business needs rather than technical readiness.

Continuous Deployment (also CD)

Continuous Deployment goes one step further: every change that passes all automated test stages is automatically pushed to production without any manual approval step. This requires a high level of confidence in the automated test suite, because there is no human gate before the change reaches users.

Continuous Deployment is not appropriate for every organisation or every product. Regulated industries, for example, may require manual sign-off before production releases. However, for mature teams with comprehensive test coverage, it can dramatically accelerate the feedback loop between developers and end users.

Summary: The Scope of Automation in Each Practice

CI/CD in Practice: A Real-World Example

The ReactJS framework maintained by Facebook (now Meta) is a publicly visible example of CI/CD in action. The project’s GitHub repository includes status badges — such as CircleCI build status and code coverage reports via Coveralls — that reflect the results of their automated pipeline on every pull request. Clicking through those badges shows the individual steps of their CI process and how the pipeline is configured. This transparency also serves as a useful learning resource for teams building their own pipelines.

CI/CD vs. DevOps: The Core Distinction

The confusion between CI/CD and DevOps is understandable — both aim to speed up and improve software delivery, and CI/CD is almost always present in a healthy DevOps organisation. But they operate at different levels:

• DevOps is the culture and strategy. It defines how teams are structured, how they communicate, and what values guide their work. You cannot buy DevOps as a product or install it as a tool.
• CI/CD is a set of technical practices and automated pipelines. It is one of the most powerful enablers of a DevOps culture, but it is possible to run a CI/CD pipeline without having a genuine DevOps culture — and conversely, a DevOps culture encompasses much more than just CI/CD (including monitoring, incident management, infrastructure as code, and organisational design).

A useful analogy: DevOps is to CI/CD what Agile is to Scrum. Agile is a set of values and principles; Scrum is a specific framework that implements many of those principles. Similarly, DevOps is the broader cultural philosophy, and CI/CD is one of the most important concrete frameworks for living it out.

Why the Distinction Matters

Getting this distinction right has practical consequences:

• Tooling decisions: Choosing a CI/CD tool (Jenkins, GitHub Actions, GitLab CI, CircleCI, etc.) is a technical decision. Adopting DevOps requires leadership buy-in, team restructuring, and cultural change — no tool alone delivers it.
• Diagnosing problems: If your deployments are still slow and painful despite having a CI/CD pipeline, the root cause may be cultural — siloed teams, poor communication, lack of shared ownership — not a pipeline configuration problem.
• Setting expectations: Promising stakeholders that “we’re adopting DevOps” when you mean “we’re setting up a Jenkins pipeline” sets up a gap between expectation and reality that can undermine confidence in the initiative.

Key Takeaways

• DevOps is a cultural and organisational philosophy that bridges the gap between development and operations to enable faster, higher-quality software delivery.
• CI/CD is a set of engineering practices and automated pipelines — Continuous Integration, Continuous Delivery, and Continuous Deployment — that automate the building, testing, and releasing of software.
• CI/CD is one of the most important technical pillars of a DevOps culture, but the two terms are not synonymous.
• You can implement CI/CD without a full DevOps transformation, but you cannot achieve a true DevOps culture without some form of CI/CD automation.
• The key differentiator among CI, Continuous Delivery, and Continuous Deployment is the degree of automation applied — particularly whether the final production deployment requires human approval.

VMware’s Virtualization Legacy and the Container Challenge

VMware built its enterprise reputation on virtual machine (VM) technology. For decades, it was the dominant vendor in server virtualization, and large enterprises relied on VMware infrastructure management solutions to run their data centers. However, the rapid rise of container technology introduced a structural challenge: containers offered many of the same portability and isolation benefits as VMs, but with a lighter runtime footprint and faster startup times, making them increasingly attractive for modern application development.

Rather than leading the container movement, VMware was slow to respond. Its existing customer base and revenue model were deeply tied to the VM ecosystem, and containers — largely driven by open-source communities — represented a different development culture than VMware had traditionally served.

Why Enterprise Container Adoption Accelerated

Enterprise interest in containers grew rapidly in the late 2010s. According to a Gartner report cited in the original source, more than 75% of global organizations were projected to run containerized applications in production by 2022, up from fewer than 30% in 2018.

“Containers provide companies with much needed agility,” said Arun Chandrasekaran, distinguished vice president and analyst at Gartner. Containers divide application code into small, discrete packages that teams can compose, deploy, and update independently — reducing development cycles and enabling continuous delivery practices.

Market research firm IHS Markit projected that container software revenue would reach $1.6 billion by 2023, representing a roughly 30% compound annual growth rate from 2019, according to its Data Center Compute Intelligence Service.

VMware’s Slow Start in Containers

While Red Hat and Docker moved early to capture the container market, VMware stayed focused on its VM business. By the time VMware made substantive moves into containers, competitors had already established strong footholds. According to figures cited in the original reporting, VMware held approximately 6% of the container market, compared to IBM’s Red Hat at around 44% and Docker at roughly 23%.

The gap is partly explained by the different philosophies of these vendors. Red Hat built its enterprise business around open-source software and cultivated deep relationships with developer communities through consulting and training. Docker embraced open-source tooling from the start, making its runtime the de facto standard before Kubernetes emerged as the dominant orchestration layer. VMware, by contrast, had historically focused on proprietary infrastructure tooling and enterprise sales cycles rather than developer-led adoption.

“VMware built a legacy business based off of customers who work with its infrastructure management solutions, but lacked a strong presence in the developer community,” said Gary Chen, research director of software defined computing at IDC.

VMware’s Strategic Pivot: Key Acquisitions

Recognizing the risk of being left behind, VMware made a series of targeted acquisitions to build its container and Kubernetes capabilities:

• Heptio (November 2018): Heptio was founded by Craig McLuckie and Joe Beda, two of the original creators of Kubernetes at Google. The acquisition gave VMware both Kubernetes expertise and credibility within the open-source Kubernetes community. “The Heptio acquisition was geared as much [toward] gaining the company’s talent as its technology,” Chen noted. “The founders were very influential in the Kubernetes community.”
• Bitnami (May 2019): Bitnami specializes in application packaging for container and Kubernetes environments, simplifying the deployment of common workloads on Kubernetes clusters. This acquisition strengthened VMware’s developer-facing tooling.
• Pivotal (December 2019): VMware had partnered with Pivotal since 2018 before acquiring it outright. At the time of acquisition, Pivotal’s container platform was reported to have around 140 enterprise customers. Pivotal brought cloud-native application development expertise and its Cloud Foundry-based platform into VMware’s portfolio.

These moves signaled a deliberate effort to complement VMware’s infrastructure management strengths with modern container orchestration and developer tooling capabilities. VMware’s existing enterprise relationships — particularly its dominance in server virtualization and network management — gave it a natural upsell path for container management solutions.

Challenges Facing VMware’s Competitors

Red Hat and IBM Integration

IBM acquired Red Hat in October 2018 for approximately $34 billion, one of the largest technology acquisitions in history. While Red Hat’s OpenShift platform remained the leading enterprise Kubernetes distribution, integrating a company of Red Hat’s scale presented significant organizational complexity. At the time of the original reporting, IBM had made relatively few changes to Red Hat’s day-to-day operations, instead focusing on weaving Red Hat technology — particularly OpenShift — into its own cloud and software portfolio.

Docker’s Orchestration Pivot and Mirantis Acquisition

Docker’s own trajectory illustrates how fast the container market shifted. Docker developed Swarm as its native container orchestration tool, and it gained meaningful adoption. However, Kubernetes quickly became the industry standard for container orchestration, largely displacing Swarm in production environments.

In November 2019, Mirantis acquired Docker’s enterprise platform business, which reportedly served around 750 business customers. Mirantis, previously known for its OpenStack expertise, planned to incorporate the Docker Enterprise platform into its Kubernetes-as-a-Service offering. Mirantis also committed to supporting Docker Swarm for at least two more years post-acquisition.

However, Mirantis’s OpenStack background was viewed as a potential liability. “Throughout its history, Mirantis has been closely aligned with OpenStack; containers are much different,” Chandrasekaran said. Like VMware, Mirantis faced the challenge of pivoting its engineering culture and go-to-market approach to align with Kubernetes-centric enterprise needs.

VMs and Containers: Coexistence, Not Replacement

One factor working in VMware’s favor is that containers and virtual machines are not mutually exclusive. Many enterprises run containers on top of VMs, using VMs to provide hardware isolation and security boundaries while containers handle application packaging and deployment. This hybrid model plays to VMware’s existing strengths and gives it a natural entry point for adding container management capabilities to its existing customer accounts.

Even in organizations that fully embrace containers and microservices, underlying infrastructure — networking, storage, compute management — remains a requirement. VMware’s infrastructure management expertise remains relevant across both paradigms.

The Road Ahead

As of the original publication date (early 2020), the container market was still in a formative phase. VMware’s acquisitions had positioned it more competitively, but execution remained the key variable.

“VMware got a late start with containers, but they have been pivoting hard and outlined a vision that should appeal to their customer base,” Chandrasekaran said. “What they need to do now is execute on that vision.”

VMware’s primary advantages — a massive installed enterprise base, deep expertise in infrastructure management, and a trusted brand among operations teams — give it a credible platform to build on. Whether those strengths translate into container market share depends on how effectively VMware can close the gap with developer communities that Red Hat and Kubernetes-native vendors have cultivated over years.

Key Takeaways

• VMware entered the container market later than Red Hat and Docker, resulting in a significantly smaller market share as of early 2020.
• A series of acquisitions — Heptio, Bitnami, and Pivotal — were VMware’s primary mechanism for gaining Kubernetes talent and tooling.
• Red Hat leads the enterprise container market, but its absorption into IBM introduced integration complexity.
• Docker’s Swarm lost out to Kubernetes; its enterprise business was acquired by Mirantis in late 2019.
• Containers and VMs coexist in many enterprise environments, which provides VMware an organic expansion path from its existing customer base.
• Execution on strategy, not just the strategy itself, will determine VMware’s long-term standing in the container market.

DevOps

DevOps is the best-known of these disciplines and serves as the foundation from which many others have evolved. At its core, DevOps is about breaking down the cultural and process silos that traditionally separated software development teams from IT operations teams. Developers are typically oriented toward introducing change quickly; operations teams prioritise stability. Without structured collaboration, those incentives conflict — slowing delivery, increasing defect rates, and creating organisational friction.

DevOps addresses this by promoting shared responsibility, continuous integration and delivery (CI/CD), infrastructure as code, and automated testing and monitoring. It builds on Agile and Lean principles but adds an explicit focus on the operations side of the house — something earlier Agile frameworks largely ignored.

Common drivers cited by organisations adopting DevOps include improving software quality, reducing overall delivery costs, improving customer experience, reducing operational complexity, and increasing cross-team collaboration.

ScrumOps

Scrum is an Agile framework first described in 1986, built around the recognition that software projects are inherently unpredictable. Rather than attempting to define every requirement upfront, Scrum organises work into short iterative cycles (sprints), with frequent inspection and adaptation. It is designed to help teams respond to change rather than resist it.

ScrumOps combines Scrum’s iterative framework with DevOps principles. Critics sometimes argue the two are incompatible — Scrum focuses on feature delivery within time-boxed sprints, while DevOps often promotes continuous flow. In practice, however, the two complement each other. Scrum provides the team structure and cadence; DevOps provides the tooling and culture to automate delivery and operations work within that cadence.

“It’s a total misconception that it has to be either Scrum or DevOps. And there’s a tension between the two that is wholly misplaced… The fact that you can use Scrum for more effective DevOps truly should be something that everyone gets.”

Dave West, CEO of Scrum.org

ServiceOps

As organisations increasingly rely on data centres, hosted platforms, and third-party managed service providers, integrating and managing those services introduces significant operational complexity. ServiceOps emerged as a discipline to address that challenge — bringing operational thinking into service design from the outset rather than bolting it on at the end.

Key principles of ServiceOps include:

• Early operations involvement: Operations teams participate during the service design phase, not just after handoff.
• Automation and self-service: Manual intervention is treated as a cost to be minimised, both in time and money.
• Value sufficiency: Services are optimised to the point of maximum value, rather than over-engineered beyond what customers need — sometimes described as “good is good enough.”

InfraOps

InfraOps — short for infrastructure operations or infrastructure optimisation — focuses on the management and optimisation of physical and virtual infrastructure, including on-premises data centres and cloud environments.

A central goal of InfraOps is simplification: reducing the number of discrete components, eliminating unnecessary breakpoints in the infrastructure stack, and increasing reliability through consolidation. Practically, this often points toward software-defined networking and storage, hyperconverged infrastructure, or fully cloud-native architectures that abstract away physical hardware concerns. When infrastructure is complex and fragile, every deployment carries greater risk; InfraOps attempts to reverse that dynamic.

CloudOps

Cloud computing has shifted how organisations provision and operate infrastructure, but it has not eliminated operational risk. Misconfigurations, outages, and human error remain persistent threats at cloud scale. High-profile incidents — such as the 2017 AWS S3 outage caused by a typo during a routine maintenance procedure — demonstrated that even hyperscale cloud platforms are vulnerable to operational mistakes with widespread downstream consequences.

CloudOps is the discipline of managing cloud environments with the same rigour traditionally applied to on-premises data centres, adapted for the elasticity and distributed nature of cloud platforms. Core concerns include:

• Maintaining maximum uptime and availability across cloud regions and providers
• Managing multi-cloud and hybrid environments to increase redundancy
• Automating provisioning, scaling, and recovery workflows
• Cost visibility and governance across cloud spend
• Security posture management in dynamic, ephemeral environments

As organisations diversify across multiple cloud providers to avoid single points of failure, CloudOps tooling and practice have become increasingly important.

ChatOps

ChatOps integrates tooling, automation, and operational workflows directly into team chat and messaging platforms. Rather than switching between a chat application and separate deployment dashboards, monitoring tools, or ticketing systems, engineers trigger actions and receive notifications within the same communication channel the team already uses.

In practice, a ChatOps workflow might look like this:

• An engineer types a deployment command in a shared team channel.
• A bot executes the pipeline and posts progress updates back to the channel.
• All team members can see the deployment status, provide input, or intervene in real time.
• The chat log becomes a transparent, searchable audit trail of what happened and when.

This approach improves visibility, reduces context-switching, and reinforces the collaborative culture that DevOps promotes. Tools such as Slack, Microsoft Teams, and Mattermost are commonly used as ChatOps platforms, often extended with bots built on frameworks like Hubot or purpose-built integrations.

AppOps

AppOps applies a full-lifecycle ownership model to application development. Under AppOps, the engineer or team that writes the software is also responsible for deploying it, monitoring it in production, and maintaining it over time. In modern terms, this aligns closely with the “you build it, you run it” principle popularised by Werner Vogels of Amazon.

In earlier decades, when development teams were smaller, this was standard practice — individual developers naturally owned the entire lifecycle of the software they wrote. As projects grew in scale and complexity, specialised teams took over deployment and operations, creating handoff points and diffused accountability. AppOps is a deliberate return to that ownership model, adapted for modern platforms. The rationale is straightforward: developers who run their own software in production write better, more operable software because they directly experience the consequences of their design decisions.

EnterpriseOps

As automation has expanded across IT operations, some predicted that traditional IT operations roles would shrink or disappear entirely. EnterpriseOps reflects the opposite trend: as automation grows more sophisticated, someone must design, implement, govern, and maintain those automated systems. That responsibility falls to operations professionals.

EnterpriseOps focuses on the operational backbone of large organisations — the processes, governance frameworks, and expertise required to keep enterprise-scale automated systems running reliably, securely, and in compliance with regulatory requirements. Far from being made redundant by DevOps, enterprise operations teams are increasingly critical enablers of the automation those organisations depend on.

How These Disciplines Relate

These Ops disciplines are not competing alternatives — most organisations will find themselves operating across several simultaneously. DevOps provides the cultural and process foundation. CloudOps and InfraOps address the infrastructure layer. AppOps and ScrumOps shape how development teams take ownership of delivery. ServiceOps governs third-party service integration. ChatOps improves team communication and operational transparency. EnterpriseOps ensures that at scale, governance and reliability are maintained.

It is also worth noting that security is increasingly a first-class concern across all of these disciplines. As organisations accelerate delivery through DevOps pipelines and automation, security practices that cannot keep pace become the new bottleneck — a challenge the DevSecOps movement addresses directly.

Conclusion

The proliferation of Ops disciplines reflects the growing complexity of modern software delivery and infrastructure. Some — like AppOps — are reframings of long-established practices. Others — like ChatOps and CloudOps — are genuinely new models made possible by modern tooling and platforms. Understanding what each discipline addresses, and where it fits in the broader delivery lifecycle, helps engineering and operations leaders make informed decisions about where to invest improvement effort.

No single Ops framework solves every problem. The most effective organisations tend to adopt the principles that address their specific bottlenecks, rather than treating any one methodology as a universal solution.

Retail Surprises as the On-Demand Deployment Leader

When DevOps practitioners think of elite software delivery, they typically picture technology giants like Amazon, Google, and Netflix. Yet Puppet’s 2019 State of DevOps Report — drawn from nearly 3,000 survey respondents — found that retail outperforms most other sectors in a critically practical metric: the ability to deploy to production on demand.

According to the report, 57% of retail respondents can deploy to production on demand, with 28% doing so regularly. Alanna Brown, Senior Director of Community and Developer Relations at Puppet, described retail’s position as “head and shoulders” above other industries when she spoke to CIO Dive.

Why Retail Moves Fast

Two factors explain retail’s outsized DevOps agility:

• Competitive pressure from Amazon: The rise of e-commerce — and Amazon’s relentless pace of iteration — has forced brick-and-mortar and online retailers alike to accelerate software delivery or risk irrelevance. Competition acts as a forcing function that tech bureaucracy rarely can.
• Lower regulatory burden: Unlike financial services, insurance, or government agencies, retailers are not subject to the same compliance and security mandates that require slower, more controlled release processes. This freedom allows retail engineering teams to iterate more aggressively.

In retail, breaking down departmental silos isn’t a DevOps aspiration — it’s a business survival strategy. Teams are incentivized to move fast, optimize systems, and remove friction from software delivery pipelines.

Technology Leads Where It Counts Most: Security Integration

Despite retail’s deployment advantage, the technology sector holds the top position for DevOps maturity overall — particularly in integrating security into the software delivery lifecycle.

According to the Puppet report:

• 35% of technology companies treat security as a shared responsibility across teams, compared to a cross-industry average of 31%.
• This positions the tech sector as the closest to a true DevSecOps model among all industries surveyed.

Brown’s framing of this relationship is worth internalizing: “If you are doing DevOps well, chances are you are already doing security well.” The implication is that security integration is not a separate discipline bolted on to DevOps — it is a natural byproduct of mature DevOps practice.

A Note on the Technology Sector’s Survey Demographics

Top-tier technology companies such as Amazon, Google, and Netflix are widely cited — including by DevOps Research and Assessment (DORA) — as capable of deploying thousands of times per day. This would ordinarily skew overall technology-sector scores upward significantly.

However, Brown noted that the technology survey sample skewed toward smaller companies, which prevented the data from being dominated by elite performers. This is an important caveat when interpreting the numbers: the tech sector’s aggregate score reflects the broader industry, not just its outliers.

Government and Financial Services Lag Behind

At the other end of the DevOps maturity spectrum sit government agencies and financial services and insurance firms. The report identified regulation and bureaucracy as the primary constraints on adoption in these sectors.

Key findings from the report include:

• Financial services and insurance have established a DevOps foundation but progress toward more advanced adoption is slow. Compliance requirements, risk-aversion, and complex legacy infrastructure all contribute to this drag.
• Government is the slowest to remediate critical vulnerabilities: only 24% of government respondents can remediate critical vulnerabilities in under one day.
• By contrast, 53% of retail respondents can achieve the same remediation within a single day — more than double the rate of government agencies.

These figures illustrate that DevOps maturity is not purely a function of technical capability. It is equally a function of organizational structure, risk appetite, and the external pressures — regulatory or competitive — that shape engineering culture.

What Cross-Industry Comparisons Tell Us

The Puppet report’s industry breakdown offers a useful framework for understanding why DevOps adoption varies so widely. The bottlenecks are different depending on context:

For DevOps practitioners and engineering leaders, the takeaway is straightforward: benchmark your organization not just against elite technology firms, but against comparable industries facing similar regulatory and competitive conditions. Retail’s success shows that constraint — in this case, the absence of heavy regulation — can be a genuine structural advantage worth understanding and, where possible, replicating through internal policy decisions.

Key Takeaways for DevOps Teams

• Competitive pressure is a legitimate DevOps accelerant. If your organization lacks external urgency, look for ways to create internal accountability around deployment frequency and mean time to recovery.
• Security integration is a marker of DevOps maturity, not a separate track. Teams that have genuinely adopted DevOps principles tend to share security ownership across functions.
• Regulatory environments shape what’s possible. Engineering leaders in constrained sectors should focus on reducing internal bureaucracy wherever regulations don’t explicitly require it.
• Vulnerability remediation speed is a meaningful lagging indicator. The gap between retail (53% remediating critical issues in under a day) and government (24%) underscores how operational culture — not just tooling — drives security outcomes.

Source: Puppet 2019 State of DevOps Report, as reported by CIO Dive.

Microsoft’s Azure Kubernetes Service (AKS) has become one of the most widely used managed Kubernetes platforms. Like any infrastructure service, however, the responsibility for securing workloads is shared: Microsoft manages the control plane, but cluster operators must make critical security decisions — many of which cannot be changed after a cluster is created. Understanding these decisions upfront is essential to building a defensible AKS environment.

Cluster Design

Security-minded design should precede cluster creation, not follow it. Several important AKS security features can only be enabled at cluster creation time. If an existing cluster was not created with these features, the recommended approach is to provision a new cluster and migrate workloads rather than attempt to retrofit security controls.

Equally important is configuration consistency. All clusters — including those used for development and staging — should mirror the security settings of production. Identical environments allow you to validate your security posture and confirm that applications behave correctly under production-equivalent restrictions before they are promoted. Inconsistent configurations create dangerous assumptions and make automation unreliable.

Enable Kubernetes RBAC

Why it matters

Kubernetes Role-Based Access Control (RBAC) is the preferred authorization mechanism for the Kubernetes API. It controls what users and workloads can do within a cluster. AKS extends this by supporting integration with Azure Active Directory (Azure AD), allowing you to map Azure AD users and groups to Kubernetes roles. This integration can be enabled or updated at any time.

What to do

• RBAC must be enabled at AKS cluster creation time. It is enabled by default for new clusters — verify this has not been disabled in your provisioning scripts or infrastructure-as-code templates.
• Integrate Kubernetes RBAC with Azure Active Directory to centralise identity management and enforce least-privilege access for both human operators and service accounts.
• Audit RBAC bindings regularly to remove stale or overly permissive roles.

Enable Network Policies

Why it matters

By default, all pods in a Kubernetes cluster can communicate with each other without restriction. Kubernetes Network Policies act as firewall rules that control ingress and egress traffic between pods, namespaces, and external endpoints. Without network policies, a compromised workload can freely reach other services in the cluster.

What to do

Network Policy support can only be enabled at AKS cluster creation time. Your available options depend on the network plugin selected for the cluster:

• Kubenet (basic networking): Supports the Calico CNI for network policy enforcement.
• Azure CNI (advanced networking): Supports both Calico and Azure Network Policy Manager (azure-npm).

Both implementations honour standard Kubernetes NetworkPolicy manifest syntax, so you can use the same policy definitions regardless of the backend. Start with a default-deny posture and explicitly allow only the traffic each workload requires.

Use Private Clusters

Note: At the time of original publication (January 2020), private clusters were in preview. Check the current Azure documentation for the feature’s general availability status before using it in production.

Why it matters

Without private clusters, a cluster’s Kubernetes API server is reachable via a public IPv4 address, and all traffic to it — including traffic from the cluster’s own node pools — traverses public network space. A private AKS cluster places all control-plane components, including the API server, within a private RFC 1918 address space. This significantly reduces the attack surface and keeps API traffic entirely within Azure’s network fabric.

What to do

• Enable the private cluster option at cluster creation time — it cannot be added later.
• Plan for a bastion VM or Azure Bastion service, which is required to reach the API server from outside the cluster’s node pool VNet.
• Note that Azure charges for the Private Endpoint resource used to expose the Kubernetes API to connected VNets.
• Review current Azure documentation for any remaining limitations before adopting private clusters in production.

Container Images

Every Kubernetes workload is built on a container image. Securing those images is therefore foundational to the security of any AKS cluster. There are two complementary practices: building minimal, hardened images, and scanning images continuously for known vulnerabilities.

Build Secure Container Images

Why it matters

The tools and packages present in a container image directly determine its exploitability. Images that include Linux package managers, Unix shells, web clients like curl, or other general-purpose utilities give attackers far more options if they achieve code execution inside a container. Minimal images reduce the blast radius of a compromise.

What to do

• Use a minimal base image. Google’s Distroless images are purpose-built for this: they contain only the runtime dependencies for your application and exclude package managers, shells, and other exploitable tools.
• Install only what the application needs at runtime. Debugging tools, profilers, and test utilities should not appear in production images.
• Avoid embedding long-lived network tools. If you need a tool like curl only at pod start-up, use an init container instead of bundling it in the main image. Where possible, prefer Kubernetes-native delivery mechanisms such as ConfigMaps or Secrets.
• Remove package managers after installation steps. If you must use a package manager to install dependencies during the image build, use multi-stage builds to ensure the package manager itself is not present in the final image layer.
• Pin and update base image versions. Monitor for new releases of your base image and third-party tools and rebuild images promptly when security patches are released.
• Run containers as a non-root user. Configure your Dockerfile with a dedicated, unprivileged user and set USER accordingly.

Scan Images for Vulnerabilities

Why it matters

Even a carefully built image can contain known vulnerabilities in OS packages or third-party libraries. Ongoing image scanning against an up-to-date CVE (Common Vulnerabilities and Exposures) database is the mechanism that makes this visible. Scanning must cover not only OS-level packages but also language-specific dependencies — for example, Java libraries, Python packages, and npm modules — because application-layer vulnerabilities such as the Apache Struts flaw exploited in the Equifax breach would not be detected by an OS-only scan.

What to do

• Integrate scanning into your CI/CD pipeline. Images with high-severity, fixable CVEs should fail the build and generate an alert — do not allow them to be pushed to production registries.
• Choose a scanner that covers both OS and language-level dependencies. Azure Container Registry has a built-in scanning capability (verify current availability and feature scope in the Azure documentation). Open-source alternatives include Trivy and Grype; commercial options are also available.
• Establish a remediation policy. Define an SLA for patching serious, fixable vulnerabilities in images that are already deployed to clusters, not just in the build pipeline.
• Scan third-party images too. If your cluster runs upstream or vendor-supplied images, scan those as well. If a third-party maintainer is slow to address critical vulnerabilities, consider building and maintaining your own version of that image.
• Re-scan images on a schedule. New CVEs are published continuously. An image that was clean at build time may become vulnerable weeks later; periodic re-scanning of images in your registry addresses this.

Summary

Securing an AKS cluster starts before the first node is provisioned. The decisions made at cluster creation — enabling RBAC, selecting a network plugin that supports network policies, and opting into private cluster mode — cannot easily be undone. Equally, the discipline of building minimal container images and scanning them continuously forms the foundation upon which all higher-level workload security depends. Part 2 of this series will cover cluster hardening and runtime security controls.

Original source: Security Boulevard.