JFrog Takes swampUP Virtual for 2020

JFrog, the enterprise DevOps platform company behind the concept of “Liquid Software,” announced in June 2020 that its annual community conference — swampUP — would move entirely online in response to the COVID-19 pandemic. Rather than simply shifting the format, JFrog used the transition as an opportunity to give back: all registration proceeds were donated to COVID-19 charities.

The event was scheduled across two regional windows:

• Americas: June 23–24, 2020
• EMEA & APAC: June 30 – July 1, 2020

Conference Format: Training First, Then the Main Event

swampUP 2020 followed a two-day structure designed to balance practical skill-building with strategic thought leadership:

• Day 1 — Hands-On Training: Specialized instructor-led courses targeting DevOps and DevSecOps practitioners. Sessions were designed to give attendees immediately applicable skills in areas such as automation, container management, and security practices.
• Day 2 — Main Conference: An industry keynote followed by more than 30 breakout sessions organized into four tracks:
  • Cloud Native
  • DevSecOps
  • Enterprise DevOps
  • Digital Transformation

Speakers and contributors came from organizations including Google, Microsoft, and Adobe, among others.

Featured Speakers

JFrog assembled a roster of well-known DevOps practitioners and industry voices for the event, including:

• Kohsuke Kawaguchi — Co-CEO, Launchable, Inc., and creator of Jenkins
• John Willis — Vice President of DevOps and Digital Practices, Red Hat
• Wayne Chatelain — Senior Manager of Software Engineering, Capital One
• Jessica Deen — Azure Avenger (Microsoft cloud and developer advocacy)

DevOps With a Mission: Charitable Giving in Unprecedented Times

The decision to donate all registration proceeds to COVID-19 research was central to the 2020 event’s identity. JFrog co-founder and CEO Shlomi Ben Haim framed the initiative as an extension of the company’s community-first philosophy:

“Since JFrog’s inception, we’ve partnered with the community to bring top tools and methodologies to the market, always with the developer in mind. Community safety also means we can’t all be together in the usual way, but the need to share is still there. We wanted to partner again with the open-source and DevOps communities and deliver not only the top-shelf content they’re used to from swampUP, but also to give back to our global communities as we collectively accelerate the cure for this virus.”

— Shlomi Ben Haim, Co-Founder and CEO, JFrog

Key Topics Covered at swampUP 2020

The sessions were designed to address the state of modern software delivery, with particular emphasis on:

• Software distribution — Managing binaries and release artifacts at scale
• Container ecosystems — Docker image management, Kubernetes integration, and container security
• Automation — CI/CD pipeline design and toolchain integration
• Security (DevSecOps) — Shifting security left and integrating vulnerability scanning into the development lifecycle
• Package management — Universal artifact repository strategies using tools like Artifactory

About JFrog

JFrog is an enterprise DevOps platform company whose products — including Artifactory, Xray, and Pipelines — are used to manage, secure, and distribute software from code to production. The company describes its mission as enabling “Liquid Software”: a model in which software updates flow continuously and securely to end users with zero downtime. As of the 2020 announcement, JFrog reported serving more than 5,600 enterprise customers across industries. JFrog products are available as open-source and commercial editions, with cloud hosting options on AWS, Microsoft Azure, and Google Cloud Platform.

swampUP Session Playlist

Kubernetes Becomes the Default Target for Database Operators

Whether proprietary or open source, NoSQL or relational, database vendors are converging on Kubernetes as the deployment and operations platform of choice. The release of Couchbase’s Autonomous Operator 2.0 is the latest example of a major database vendor leaning into container orchestration — not as an afterthought, but as a first-class deployment strategy.

Couchbase is a document-oriented NoSQL database used by large enterprises including Amadeus, American Express, Cisco, and eBay. Its Autonomous Operator for Kubernetes 2.0 is engineered to let developers and database administrators deploy and manage Couchbase clusters across any cloud environment with minimal manual intervention.

What the Autonomous Operator 2.0 Actually Does

At its core, the Autonomous Operator extends the Kubernetes API via a Custom Resource Definition (CRD) that acts as a declarative blueprint for a Couchbase cluster. Perry Krug, Couchbase Director of Customer Success, described the capability:

“It allows you, with just a single click, to deploy a Couchbase cluster into Kubernetes. In some cases, you can deploy many nodes that will automatically cluster together having the same configuration.”

A key design goal is portability. The same CRD template works across:

• Vanilla upstream Kubernetes
• Red Hat OpenShift
• Amazon Elastic Kubernetes Service (EKS)
• Microsoft Azure Kubernetes Service (AKS)
• Google Kubernetes Engine (GKE)

This means a team can write a cluster definition once and deploy it consistently across on-premises, hybrid, or multi-cloud environments without rewriting configuration for each target platform — a meaningful reduction in operational overhead for teams managing geographically distributed workloads.

Reported Operational Gains

Couchbase has claimed that users of the Autonomous Operator reported a 95% reduction in operational complexity and cost when deploying the database in the cloud. The operator is also positioned as a tool to simplify hybrid cloud installations and reduce dependency on any single cloud vendor’s proprietary managed database services.

It is worth noting that this figure comes from Couchbase’s own customer reporting and has not been independently verified. Teams evaluating the operator should benchmark against their own operational baseline.

How Kubernetes Operators Change Database Operations

The Kubernetes Operator pattern encodes domain-specific operational knowledge — things a skilled DBA would do manually — into a controller that runs inside the cluster. For stateful workloads like databases, this changes the operational model in several concrete ways:

• Automated provisioning: Nodes are created, joined to the cluster, and configured to a defined spec without manual intervention.
• Consistent replication: The same declarative configuration can be applied to development, staging, and production environments.
• Self-healing: When a node fails, the operator can detect the failure and initiate recovery automatically, rather than waiting for a DBA to respond.
• Continuous reconciliation: Kubernetes monitors the actual cluster state against the desired state defined in the CRD and acts to correct drift.

Percona XtraDB Cluster 8.0: The Open-Source Parallel

Couchbase is not alone in this direction. Around the same time, Percona — the open-source database services company — released XtraDB Cluster 8.0, which includes a Kubernetes operator for MySQL-compatible clusters. Percona’s product marketing manager Rick Golba explained the operational model:

“It creates the nodes and it creates the connectivity between the nodes. It sets it all up to your standards and in a way that is very consistent and easily replicated to other environments. Similarly, when you’re running the environment, Kubernetes is going to be monitoring the environment.”

The node failure recovery use case is particularly significant for high-availability database clusters. Golba elaborated:

“In the past, if you had a node that failed in a three-node cluster, your environment would stay up and running and you could do all of the recovery from that, but that was a manual process. Now with Kubernetes, we have the capability to automate that whole entire process.”

The Broader Trend: Database Operators as Operational Infrastructure

The convergence of database vendors on Kubernetes operators reflects a broader shift: infrastructure teams increasingly expect stateful workloads to be managed through the same declarative, GitOps-compatible tooling as the rest of their application stack. Native Kubernetes integration means database lifecycle management — including provisioning, scaling, upgrades, and failure recovery — can be expressed as code, reviewed, and version-controlled alongside application configuration.

For DevOps and platform engineering teams, the practical implication is that the operational gap between managing stateless microservices and stateful databases is narrowing. Whether you are running Couchbase for document workloads or MySQL for transactional data, the Kubernetes operator model provides a consistent abstraction for cluster lifecycle management across cloud environments.

Key Takeaways

• Couchbase Autonomous Operator 2.0 enables declarative, single-CRD deployment of Couchbase clusters across vanilla Kubernetes, OpenShift, EKS, AKS, and GKE.
• The operator targets reduced manual DBA intervention and supports hybrid and multi-cloud deployments without configuration rewrites per platform.
• Couchbase reports a 95% reduction in operational complexity — a vendor-supplied figure that teams should validate against their own environments.
• Percona’s XtraDB Cluster 8.0 brings the same operator-based automation model to open-source MySQL workloads.
• The Kubernetes Operator pattern is becoming an expected standard for production database deployment, not a differentiating feature.

Rancher Labs on Tuesday announced the general availability of Rancher 2.4, the latest release of its popular Kubernetes management platform. The new release takes Rancher one step closer to its vision of running Kubernetes everywhere, with architectural support for one million clusters. It also includes updates related to security and general performance.

Rancher 2.4 specifically offers support for one million clusters in preview, while the GA product supports 2,000 clusters and 100,000 nodes. Those numbers will increase as Rancher continues higher-scale testing, said CMO Peter Smails.

FEATURED STORIES

New Windows 10 bug hits home working: Outlook, Office 365, Teams can’t access internet
Why are we all Zooming and not Skyping?
Best password managers for business in 2020: 1Password, Keeper, LastPass, and more
Here’s how you can still get a free Windows 10 upgrade
“Foundationally, it’s an architectural shift for us to build in that level of scalability,” he said.

The focus on scalability reflects the changing ways organizations are deploying Kubernetes, Rancher CEO Sheng Liang explained to ZDNet. While Kubernetes itself is quite scalable, supporting clusters with up to 5,000 nodes each, organizations are moving toward more, smaller clusters. In the enterprise, for instance, it makes sense to have development workloads and production workloads in different clusters or different teams in different clusters.

Meanwhile, the advent of edge computing is bringing cluster management to a whole new level of scale. A retailer could be running a cluster for each point of presence, or each surveillance camera, for instance.

“As the number of clusters go up, generally the size of clusters goes down,” Liang said. “They’re no longer big data center deployments, it’s just one server, one node at the edge.”

Rancher expects that trend to grow with the rollout of connected cars, connected factories, and other IoT use cases. With the coming 2.5 version of Rancher, the company plans to offer fleet management of clusters.

Rancher 2.4 also offers zero downtime maintenance for RKE, which should be valuable for organizations running workloads in production.

It also offers limited connectivity maintenance for K3s, Rancher’s certified Kubernetes distribution designed for production workloads in remote locations or inside IoT appliances. Limited connectivity maintenance is designed for clusters that may not have a fixed or stable network connection. Rancher 2.4 kicks off an upgrade remotely, while the process is then managed on local K3s clusters, allowing users to manage upgrades and patches locally. Once connectivity is restored, it will sync with the management server.

To improve security, Rancher 2.4 introduces CIS Scan, allowing users to run ad-hoc security scans of their RKE clusters against more than 100 benchmarks published by the Center for Internet Security. Users can create custom test configurations and generate reports on the results. The reports provide feedback in terms of corrective actions and remediation that users can take within Rancher.

Lastly, Rancher 2.4 is now available in a Hosted Rancher deployment. Customers can get a dedicated AWS instance of a Rancher Server management control plane. The deployment option provides a full-featured Rancher server, delivers 99.9% SLA, and provides upgrades, security patches, and backups. It’s not a fully-managed service — Rancher manages the server but not the control plane or downstream Kubernetes clusters.

What Was Announced

IBM announced the general availability of Red Hat Ansible Certified Content for IBM Z, enabling Ansible users to automate IBM Z (mainframe) applications and IT infrastructure using the same automation toolchain they deploy across the rest of their hybrid environment. The Certified Content is available through Red Hat Automation Hub for Ansible Automation Platform subscribers, with an upstream open-source version published on Ansible Galaxy under the collection name ibm.ibm_zos_core.

Why This Matters for Hybrid IT

Enterprise IT environments are rarely homogeneous. Organizations running IBM Z mainframes alongside x86 servers, private clouds, and public cloud services have historically needed separate automation stacks for each platform. This fragmentation increases operational overhead, slows down delivery pipelines, and creates inconsistencies between environments.

By bringing IBM Z into the Ansible ecosystem, organizations can manage their entire infrastructure — including z/OS workloads — through a single control plane. This removes one of the most persistent silos in enterprise IT: the gap between mainframe operations and the DevOps tooling used everywhere else.

What the ibm.ibm_zos_core Collection Includes

The initial release of the core collection ships with the following automation building blocks for z/OS:

• Connection plugins – Enable Ansible to communicate securely with z/OS hosts.
• Action plugins – Extend standard Ansible action handling for z/OS-specific workflows.
• Modules – Purpose-built modules covering common z/OS tasks, including:
  • Creating and managing data sets
  • Retrieving job output (JES spool)
  • Submitting batch jobs (JCL)
• Sample playbooks – Reference playbooks to accelerate onboarding and demonstrate best practices.

The collection is delivered as a fully supported, enterprise-grade Red Hat Ansible Certified Content Collection, meaning it carries Red Hat’s quality and support guarantees for Ansible Automation Platform subscribers.

Key Benefits for z/OS Operators and Developers

• Consistent automation language: Teams already writing Ansible playbooks for Linux, Windows, or cloud infrastructure can apply the same YAML-based syntax to z/OS tasks — no separate scripting language or mainframe-specific tooling required.
• Simplified configuration management: Automate configuration and resource access on z/OS using standard Ansible inventory and variable management.
• Leverage existing automation investments: Existing Ansible roles and workflows can be extended to include z/OS steps, rather than building parallel automation pipelines.
• Accelerated z/OS DevOps: Integrates with CI/CD pipelines using tools like Jenkins and Git, which IBM had already been introducing to the Z platform through projects like IBM Z Open Editor, IBM Developer for z/OS, and the Zowe open-source framework.
• Performance, scale, and security: Automation runs against a platform already known for its reliability and security characteristics, without sacrificing those properties.

Context: IBM Z’s Broader DevOps Push

The Ansible Certified Content announcement built on several earlier IBM Z modernization efforts:

• Zowe – An open-source framework (of which IBM is a founding member) that brings modern interfaces and APIs to z/OS.
• IBM Z Open Editor – A VS Code extension for editing COBOL, PL/I, and JCL on z/OS.
• IBM Developer for z/OS V14.2.1 – An IDE update aimed at improving developer productivity on the platform.
• Red Hat OpenShift on IBM Z – Announced in early 2020, enabling cloud-native containerized workloads to run on IBM Z hardware alongside traditional workloads.

Together, these initiatives represent IBM’s strategy of bringing industry-standard, open-source DevOps tooling to the mainframe rather than asking enterprises to choose between the mainframe and modern development practices.

Where to Get Started

There are three primary entry points depending on your subscription and preference:

1. Ansible Galaxy (ibm.ibm_zos_core) – Free, open-source version for evaluation and community use. Search for the collection on galaxy.ansible.com.
2. Red Hat Ansible Automation Hub – The fully supported, certified version for Ansible Automation Platform subscribers.
3. GitHub – Source code and documentation for the open-source upstream project, where community contributions and issue tracking are hosted.

Summary

Red Hat Ansible Certified Content for IBM Z closes a long-standing automation gap in hybrid enterprise environments. By allowing operations teams and developers to manage z/OS through the same Ansible playbooks, inventories, and control planes they use for the rest of their infrastructure, IBM and Red Hat have made it meaningfully easier to include mainframe workloads in modern DevOps and infrastructure-as-code practices — without requiring separate toolchains or deep mainframe scripting expertise for routine automation tasks.

Note: IBM’s statements regarding product direction are subject to change at IBM’s sole discretion and should not be taken as binding commitments.

What Is the DevSecOps Market?

DevSecOps — the practice of integrating security controls directly into the DevOps software development lifecycle (SDLC) — has moved from a niche discipline to a mainstream enterprise priority. Rather than treating security as a gate at the end of the release pipeline, DevSecOps shifts responsibility left, embedding security testing, policy enforcement, and compliance checks at every stage of development and operations.

Market research from Infoholic Research characterises the global DevSecOps market as one of the fastest-growing segments in the broader ICT industry, driven by escalating security breach incidents, wider cloud adoption, and the growing complexity of modern software supply chains.

Market Growth and Key Drivers

According to Infoholic Research, the global DevSecOps market was projected to grow at a compound annual growth rate (CAGR) of 33.7% over the forecast period 2020–2026. Several forces are cited as the primary demand drivers:

• Rising frequency and severity of security breaches — Attackers increasingly exploit vulnerabilities introduced during development rather than at the perimeter, making earlier security integration a business necessity.
• Need to reduce SDLC waste — Security defects caught late in the delivery pipeline are far more expensive to fix. DevSecOps tooling aims to surface issues early, reducing rework and accelerating release cycles.
• Increased investment activity — Venture capital and corporate M&A in security tooling have expanded the ecosystem of available platforms and integrations.
• Adoption of AI, automation, and cloud technologies — Automated static analysis, dynamic testing, container scanning, and cloud-native policy enforcement are becoming standard components of CI/CD pipelines.
• Regulatory and compliance pressure — Government mandates around data protection (particularly in the US, UK, Germany, and France) are pushing enterprises to formalise security practices within their development workflows.

Major Vendors and Competitive Landscape

The DevSecOps market is served by a broad mix of established enterprise software vendors, cloud platform providers, and specialist security tooling companies. Major players identified in the Infoholic Research report include:

• Broadcom — Enterprise software portfolio including CA Technologies security tools
• IBM Corporation — Application security testing and DevSecOps integrations within IBM Cloud and its broader security product family
• Micro Focus — Fortify static and dynamic application security testing (SAST/DAST) suite
• Synopsys Inc. — Black Duck software composition analysis and Coverity SAST
• Microsoft — Azure DevOps, Defender for DevOps, and GitHub Advanced Security
• Google — Cloud-native security tooling within Google Cloud Platform
• Palo Alto Networks — Prisma Cloud for container and cloud workload security
• Qualys Inc. — Cloud-based vulnerability management and compliance scanning
• Chef (Progress) — Infrastructure-as-code automation with InSpec for compliance-as-code
• Puppet — Configuration management and policy enforcement at scale
• Splunk Inc. — Security information and event management (SIEM) with DevOps pipeline integrations
• CyberArk Software Ltd. — Privileged access management within CI/CD pipelines
• Contrast Security — Runtime application self-protection (RASP) and interactive application security testing (IAST)
• Checkmarx Ltd. — SAST and software composition analysis
• Aqua Security Software Ltd. — Container and Kubernetes security
• Sumo Logic — Cloud-native log management and security analytics
• WhiteHat Security — Application security testing as a service
• AlgoSec — Network security policy management
• CloudPassage (Halo) — Cloud infrastructure security and compliance automation
• Continuum Security, Entersoft, Rogue Wave Software, 4ARMED LIMITED, DOME9 Security

Competitive Dynamics

The competitive landscape is characterised by two parallel trends. Larger vendors are pursuing partnerships and acquisitions to absorb specialist tooling capabilities and expand platform breadth. Simultaneously, smaller and emerging startups continue to attract customers with focused, developer-friendly tools that integrate easily into existing CI/CD pipelines. The net effect is a market where both point solutions and integrated platform offerings coexist, giving engineering teams a wide range of adoption strategies.

Regional Analysis

Americas

The Americas — led by the United States and Canada — represent the largest regional market. Factors cited include high baseline investment in advanced technology, stringent security regulations, and a mature enterprise software buying culture. The US in particular has a large installed base of regulated industries (financial services, healthcare, defence) with strong mandates for application security.

Europe

Europe is the second-largest region. The UK, Germany, and France are the primary revenue contributors. GDPR and national cybersecurity frameworks have created strong compliance-driven demand for tools that can demonstrate security controls within the development process.

Asia Pacific

Asia Pacific is highlighted as an important growth market. India, China, Japan, Singapore, and the Philippines show increasing enterprise interest in DevSecOps platforms, driven by rapid digitisation and a growing awareness of software supply chain risks. The region is positioned as a key expansion target for global vendors.

Middle East and Africa

MEA is characterised as an emerging market, with the primary growth window identified as 2020–2023 in the original report. Investment in digital infrastructure across the Gulf states is a contributing factor.

Deployment Models: Cloud vs. On-Premises

Most DevSecOps vendors offer both cloud-hosted (SaaS) and on-premises deployment options. Historically, large enterprises — particularly in regulated industries — preferred on-premises deployments to maintain data sovereignty and integrate with existing internal security tooling.

However, the trend is clearly towards cloud-native and SaaS delivery. The Infoholic Research analysis projected that the cloud deployment model would account for the larger share of market revenue over the forecast period, reflecting the broader enterprise migration to cloud infrastructure and the ease of integrating SaaS security tools into cloud-hosted CI/CD pipelines. Cloud providers in this space must still address concerns around data residency, multi-tenancy isolation, and supply chain trust.

Enterprise Segment Analysis

DevSecOps adoption spans enterprises of all sizes, but the dynamics differ significantly by segment:

Large Enterprises

Large enterprises currently lead market revenue. They have the budget to invest in comprehensive DevSecOps platforms, dedicated security engineering teams, and the organisational capacity to implement shift-left practices at scale. However, their complexity — legacy systems, large codebases, multiple teams — also makes full DevSecOps adoption a long-term programme rather than a quick deployment.

Small and Medium Enterprises (SMEs)

SMEs are disproportionately targeted by attackers precisely because they often lack dedicated IT security infrastructure and expertise. While SMEs currently represent a smaller revenue share, the report projects that this segment will grow its contribution significantly as affordable, cloud-delivered DevSecOps tooling lowers the barrier to adoption. Managed security service providers (MSSPs) and integrated SaaS platforms are key enablers for SME adoption.

Why DevSecOps Matters: The Security Case

The underlying premise of DevSecOps is straightforward: the growing surface area created by rapid software delivery creates more opportunities for vulnerabilities to be introduced and exploited. Traditional perimeter-focused security models are insufficient when the application itself — its code, its dependencies, its configuration, and its runtime environment — is the primary attack surface.

DevSecOps addresses this by making security a shared, continuous responsibility:

• Developers receive immediate feedback on security issues through IDE plugins and automated scanning in pull request workflows.
• Security engineers define policy as code, enabling consistent enforcement across all pipelines without manual review bottlenecks.
• Operations teams monitor runtime behaviour and feed threat intelligence back into the development process.

This collaborative model — often described as “security as code” — is what distinguishes DevSecOps from simply adding a security scan at the end of a pipeline.

Summary

The DevSecOps market is large, fast-growing, and intensely competitive. Established vendors like IBM, Microsoft, Synopsys, and Palo Alto Networks compete alongside specialist tools from Checkmarx, Aqua Security, and Contrast Security, with cloud platforms increasingly bundling security capabilities natively. For DevOps and platform engineering teams, this means a rich but complex tooling ecosystem to navigate.

The consistent message from market analysts is that enterprise investment in DevSecOps is not discretionary — it is a structural response to the reality that software supply chains have become a primary attack vector, and that security cannot be effectively outsourced to a team reviewing code at release time.

Original market data sourced from Infoholic Research via openpr.com (2020). Vendor portfolios and market positions may have changed materially since publication.

Google Cloud Buys Cornerstone Technology

Google Cloud acquired Cornerstone Technology, a firm specializing in mainframe-to-cloud migration services, with the explicit goal of helping enterprises running “Big Iron” workloads transition to private and public cloud infrastructure. The acquisition was announced in February 2020.

According to Howard Weale, Google’s Director of Transformation Practice, the core of Cornerstone’s value lies in its G4 platform — an automated toolchain that can decompose legacy mainframe programs written in COBOL, PL/1, or Assembler and recast them as cloud-native services running in managed, containerized environments.

“Through the use of automated processes, Cornerstone’s tools can break down your COBOL, PL/1, or Assembler programs into services and then make them cloud native, such as within a managed, containerized environment.”

Howard Weale, Director of Transformation Practice, Google Cloud

What the Cornerstone Platform Offers

Google stated that the Cornerstone technology would form the foundation of its future mainframe-to-Google Cloud product offerings. The platform is designed to address three common migration challenges:

• Migration roadmap assessment: Google will evaluate a customer’s existing mainframe environment and produce a structured roadmap toward a modern services architecture.
• Cross-language and cross-database conversion: The toolchain is designed to convert source code from one language to another (for example, COBOL to Java) and migrate data from legacy databases to modern equivalents.
• Automated workload migration: Automated pipelines move converted workloads onto Google Cloud infrastructure, reducing manual re-platforming effort.

Weale noted that a key use case is breaking apart mainframe monolithic applications into either Java monoliths or Java microservices — aligning legacy systems with contemporary service-oriented and microservices architectures that most enterprises now favor for new development.

Why This Matters for Google’s Enterprise Strategy

Mainframe workloads represent some of the most business-critical and deeply entrenched systems in industries such as banking, insurance, and government. Winning migration contracts in these sectors is a significant revenue opportunity — and a strong signal to large enterprises that a cloud provider can handle their most demanding requirements.

“Easy mainframe migration will go a long way as Google attracts large enterprises to its cloud.”

Matt Eastwood, Senior Vice President, Enterprise Infrastructure, Cloud, Developers and Alliances, IDC

The Cornerstone acquisition also positions Google Cloud more directly against competitors that already offer mainframe migration services, including Amazon Web Services, IBM/Red Hat, and Microsoft Azure. Each of these vendors has made investments in tooling or partnerships to help enterprises retire or re-platform mainframe workloads.

Analyst Caution: Mainframe Migration Is Not Always the Right Move

Despite the momentum behind cloud migration, Gartner issued a pointed warning — referenced in a report titled Considering Leaving Legacy IBM Platforms? Beware, as Cost Savings May Disappoint, While Risking Quality — advising organizations to scrutinize mainframe migration decisions carefully before committing.

“The value gained by moving applications from the traditional enterprise platform onto the next ‘bright, shiny thing’ rarely provides an improvement in the business process or the company’s bottom line. A great deal of analysis must be performed and each cost accounted for.”

Gartner, Considering Leaving Legacy IBM Platforms? Beware, as Cost Savings May Disappoint, While Risking Quality

Gartner’s core argument is that mainframes, while perceived as dated, continue to evolve. IBM and other vendors are actively integrating open-source tooling and modernizing hardware, making the platforms more accessible to developers. Application leaders were advised to re-evaluate the actual capabilities and total cost of ownership of their existing mainframe platforms before initiating a migration.

Key Takeaways for DevOps and Platform Engineering Teams

• Automated language conversion is the hard part. COBOL-to-Java conversion at scale has historically been error-prone and expensive. Evaluate any toolchain’s output quality rigorously before trusting automated conversions in production.
• Containerization is not free modernization. Wrapping a converted monolith in a container does not automatically make it cloud-native. Teams should plan for behavioral equivalence testing and performance validation post-migration.
• TCO analysis is essential. Mainframe licensing models differ fundamentally from cloud pricing. A detailed total-cost-of-ownership model, including staffing, testing, and ongoing cloud spend, is necessary before a business case can be made.
• Phased migration reduces risk. Rather than a full lift-and-shift, consider migrating lower-risk workloads first to validate tooling and build organizational confidence.
• Vendor lock-in trades. Moving from mainframe to a single cloud provider replaces one form of lock-in with another. Multi-cloud or abstraction-layer strategies should be considered where long-term portability matters.

Google Cloud’s acquisition of Cornerstone Technology signals serious intent to compete for enterprise mainframe migration budgets. However, as Gartner’s guidance underscores, the decision to migrate should be driven by rigorous analysis rather than vendor momentum — regardless of how compelling the automation tooling appears.

Major DevOps Tool Vendors (2020 Landscape)

The report identified the following companies as significant participants in the global DevOps tool market. They span configuration management, containerisation, collaboration, monitoring, and end-to-end platform categories:

• Puppet Labs – infrastructure automation and configuration management
• Chef (Progress) – policy-based infrastructure automation
• Docker Inc. – container runtime and image management
• Red Hat – enterprise Linux, Ansible automation, and OpenShift (Kubernetes)
• Atlassian – Jira, Confluence, Bitbucket, and Bamboo for collaboration and CI/CD
• SaltStack – event-driven infrastructure automation
• CA Technologies (Broadcom) – enterprise release automation and testing
• Rackspace – managed cloud and DevOps professional services
• XebiaLabs (Digital.ai) – release orchestration and value-stream management
• VersionOne (Digital.ai) – agile and DevOps planning
• Cisco – network automation and security tooling integrated with DevOps pipelines
• CollabNet (Digital.ai) – ALM and DevOps platform
• HP (Micro Focus) – enterprise testing and ALM
• IBM – UrbanCode Deploy and cloud-native DevOps services
• Microsoft – Azure DevOps (formerly VSTS), GitHub Actions
• Spirent Communications – network and application testing
• VMware – Tanzu portfolio for Kubernetes and multi-cloud DevOps

Consolidation was already a visible theme heading into 2020, with several vendors (XebiaLabs, VersionOne, CollabNet) merging under the Digital.ai brand, and Broadcom having completed its acquisition of CA Technologies in 2018.

Market Segmentation by Product Maturity

The report classified DevOps tool offerings into three maturity tiers, reflecting an organisation’s or product’s stage of DevOps adoption:

• DevOps Ready – Tools that provide foundational capabilities (version control, basic CI) but require significant manual configuration and cultural change to deliver full DevOps value.
• DevOps Enabled – Integrated toolchains that automate key pipeline stages (build, test, deploy) with moderate out-of-the-box integration between tools.
• DevOps Capable – Mature, end-to-end platforms offering automated governance, value-stream analytics, security scanning (DevSecOps), and AI-assisted operations (AIOps) built in.

Market Segmentation by Industry Vertical

DevOps tool adoption was not uniform across sectors. The report segmented demand by vertical application:

Key Market Growth Drivers (2020–2024)

Several structural forces were expected to sustain demand for DevOps tooling through the mid-2020s:

• Cloud-native adoption: Migration to AWS, Azure, and Google Cloud required automated provisioning and deployment tooling at scale.
• Container and Kubernetes growth: Docker and Kubernetes created demand for orchestration, observability, and security tooling.
• Shift-left security (DevSecOps): Organisations began integrating SAST, DAST, and dependency scanning directly into CI/CD pipelines.
• Remote work acceleration (post-2020): The COVID-19 pandemic accelerated digital transformation programmes that had previously been moving slowly, compressing multi-year roadmaps into months.
• Regulatory pressure: Sectors such as BFSI and government faced compliance mandates that rewarded auditable, automated deployment practices.
• Open-source momentum: Tools such as Jenkins, GitLab, and Kubernetes lowered entry barriers, expanding the total addressable market even as they pressured proprietary vendors on pricing.

Market Challenges and Restraints

Growth was not without friction. Analysts consistently highlighted the following inhibitors:

• Cultural resistance: Tool adoption without organisational change rarely delivers promised outcomes. Many enterprises purchased platforms but struggled to eliminate siloes between dev and ops teams.
• Toolchain sprawl: The average enterprise DevOps pipeline in 2020 involved dozens of discrete tools, creating integration overhead and hidden operational costs.
• Skills shortage: Demand for engineers with CI/CD, Kubernetes, and automation expertise consistently outpaced supply.
• Security and compliance complexity: Highly regulated industries faced friction reconciling rapid deployment cycles with change-management controls.
• Vendor lock-in concerns: Proprietary platforms offered integration convenience at the cost of portability, making organisations cautious about deep commitments.

Analytical Framework Used in Market Reports of This Type

Market research reports covering the DevOps tool sector typically apply the following analytical lenses. Understanding this framework helps practitioners evaluate reports critically before purchasing or citing them:

• SWOT analysis – Strengths, Weaknesses, Opportunities, and Threats for major vendors and the market as a whole.
• Porter’s Five Forces – Supplier power, buyer power, competitive rivalry, threat of substitutes, and barriers to entry.
• Value-chain analysis – From tool vendors and open-source communities through system integrators to end-user organisations.
• Regional breakdown – North America, Europe, Asia-Pacific, Latin America, and Middle East & Africa, each with distinct regulatory environments and adoption rates.
• Historical baseline + forecast – Typically anchored on a base year (2018 in this report) with a five-to-six-year forward projection.

How to Use Market Intelligence as a DevOps Practitioner

Market reports are most useful for practitioners in the following scenarios:

• Vendor selection: Understanding market-share trends helps you assess vendor viability and long-term support risk before committing to a platform.
• Business case construction: Industry-level CAGR figures (when verified) provide context for internal investment proposals.
• Competitive benchmarking: Knowing what tooling your industry peers use can inform your own maturity roadmap.
• M&A and consolidation awareness: The DevOps tool market has seen significant consolidation (e.g., Digital.ai, Broadcom/CA, Microsoft/GitHub). Tracking this protects against tool obsolescence.

Summary

The 2020–2024 period represented a maturation phase for the DevOps tool market. Foundational tooling categories — source control, CI/CD, configuration management, and containerisation — became commoditised, while differentiation shifted toward end-to-end platform integration, value-stream analytics, and security automation. The vendors that gained ground were those capable of demonstrating measurable business outcomes — faster lead times, lower change-failure rates, and improved deployment frequency — rather than feature lists alone.

For teams evaluating tooling investments, the most durable advice from this period remains consistent: start with the bottleneck in your delivery pipeline, automate incrementally, measure outcomes, and treat tool selection as a consequence of process design rather than a substitute for it.

Overview of the Global DevOps Platform Market (2019)

By the end of 2019, the DevOps toolchain and platform market had matured into a competitive, multi-billion-dollar segment of the broader enterprise software industry. Organizations across verticals were accelerating adoption of DevOps practices to shorten release cycles, improve system reliability, and reduce operational friction between development and operations teams. Market research conducted during this period typically examined historic growth trends, near-term forecasts through 2024, competitive positioning, and vertical-market penetration.

Standard analytical frameworks applied to this market included Porter’s Five Forces (to assess competitive intensity and barriers to entry), SWOT analysis (strengths, weaknesses, opportunities, threats per vendor segment), and PESTEL analysis (political, economic, social, technological, environmental, and legal factors shaping adoption).

Leading DevOps Platform Vendors

The 2019 market landscape included a broad mix of open-source projects, independent software vendors, and large enterprise technology companies. Key players identified by market researchers at the time included:

• Ansible – Red Hat’s agentless automation and configuration management platform
• Chef – Infrastructure-as-code and compliance automation (now Progress Chef)
• Jenkins – The dominant open-source CI/CD automation server
• TeamCity – JetBrains’ commercial CI/CD server popular in .NET and JVM shops
• Atlassian – Provider of Jira, Confluence, Bitbucket, and Bamboo for planning through deployment
• SaltStack – Event-driven automation and remote execution framework
• Vagrant – HashiCorp tool for reproducible development environments
• Splunk – Observability, log management, and security intelligence
• ServiceNow – IT service management and DevOps workflow integration
• Puppet Labs – Declarative infrastructure automation and compliance
• CA Technologies – Enterprise DevOps tooling (acquired by Broadcom in 2018)
• IBM – DevOps capabilities spanning UrbanCode, Cloud Pak, and Watson AIOps
• Rackspace – Managed cloud and DevOps professional services
• Red Hat – OpenShift, Ansible, and open-source middleware
• CFEngine – Lightweight, high-performance configuration management
• Cisco – Network-layer DevOps and infrastructure automation
• Clarive – Release orchestration and DevOps value stream management
• CollabNet – Application lifecycle management and CI/CD platform
• DBmaestro – Database DevOps and deployment automation
• Dell Technologies – Infrastructure and cloud enablement for DevOps pipelines
• Docker – Container runtime and image registry central to modern CI/CD
• HP (HPE) – Enterprise DevOps testing and delivery tooling
• Inedo – ProGet, BuildMaster, and Otter for artifact management and orchestration
• Infosys – DevOps consulting, managed services, and toolchain integration
• Microsoft – Azure DevOps (formerly VSTS), GitHub, and related services
• VersionOne – Agile and DevOps planning (now Digital.ai)
• VMware – vSphere automation, Tanzu application platform, and CI/CD integration

This vendor mix illustrates how the market spanned pure-play DevOps specialists (Jenkins, Chef, Puppet), cloud-native platforms (Docker, Atlassian, Microsoft Azure DevOps), and large enterprise incumbents extending into DevOps territory (IBM, CA Technologies, HPE).

Product Segment Analysis

Market researchers in 2019 typically categorized DevOps platform offerings into three broad product types:

• Developer-driven DevOps – Toolchains initiated and owned primarily by engineering teams, emphasizing source control, CI pipelines, testing automation, and artifact management. Examples include GitHub Actions, Jenkins, and GitLab CI.
• Operations-driven DevOps – Platforms emphasizing infrastructure automation, configuration management, monitoring, and incident response. Examples include Ansible, Puppet, SaltStack, and Splunk.
• Platform 2.5 environments – Hybrid or integrated platforms bridging development and operations concerns under a single pane of glass, often including value stream management capabilities. Atlassian, ServiceNow, and CA Technologies occupied this space.

Application (Vertical) Segment Analysis

DevOps platform adoption was not uniform across industries in 2019. The major end-user verticals identified by researchers were:

• IT Industry – The largest adopter, encompassing software vendors, SaaS companies, and managed service providers where DevOps practices originated.
• Banking, Financial Services, and Insurance (BFSI) – Rapid adoption driven by digital transformation, regulatory compliance automation, and competitive pressure from fintech. Security and auditability requirements shaped toolchain choices.
• Telecom – Network function virtualization (NFV) and software-defined networking (SDN) initiatives drove DevOps adoption in large carriers.
• Retail – E-commerce scalability demands, seasonal traffic patterns, and omnichannel delivery pushed retailers toward continuous delivery practices.
• Other end-users – Healthcare, government, manufacturing, and energy sectors showing early-to-mid-stage adoption.

Regional Market Dynamics

Geographically, the DevOps platform market in 2019 was analyzed across the following regions:

• North America – The most mature and largest revenue-generating region, driven by high cloud adoption, a large concentration of technology companies, and strong DevOps cultural penetration.
• Europe – Significant adoption in the UK, Germany, and the Netherlands, with GDPR compliance automation adding an additional driver for pipeline tooling investment.
• Asia-Pacific – The fastest-growing region, with China, India, Japan, and South Korea leading adoption. India’s large software services sector made it a particularly notable market for DevOps tooling and training.
• Middle East and Africa – Emerging adoption, particularly in the Gulf Cooperation Council (GCC) countries undergoing digital transformation.
• Rest of the World – Latin America and other markets in earlier stages of DevOps maturity.

Key Market Drivers and Restraints

Understanding why the DevOps platform market was growing — and what was slowing it — is more durable than any specific market-size figure. Common drivers identified in 2019 research included:

• Accelerating cloud migration creating demand for infrastructure automation tools
• Competitive pressure to reduce software release cycles from months to days or hours
• Growing availability of open-source tooling lowering the entry cost for DevOps adoption
• Enterprise DevOps culture maturity and executive sponsorship improving top-down investment
• Container and Kubernetes adoption expanding the scope of DevOps platforms

Common restraints and challenges included:

• Organizational silos and cultural resistance to cross-functional collaboration
• Skills shortages in areas such as Kubernetes, infrastructure-as-code, and site reliability engineering
• Complexity of integrating diverse toolchains across heterogeneous environments
• Security and compliance concerns, particularly in regulated industries
• Fragmented vendor landscape creating evaluation and standardization challenges

Competitive Landscape and Strategic Takeaways

By late 2019, several strategic patterns were visible in the DevOps platform market:

• Consolidation: Large vendors were acquiring point-solution specialists. Red Hat’s acquisition of Ansible (2015), Microsoft’s acquisition of GitHub (2018), and Broadcom’s acquisition of CA Technologies (2018) exemplified this trend.
• Open-source as a moat: Vendors like HashiCorp, Elastic, and GitLab built large communities around open-source cores before monetizing through enterprise features or hosted SaaS.
• Platform vs. best-of-breed: Organizations debated whether to standardize on integrated platforms (Azure DevOps, GitLab) or compose toolchains from specialized tools. Neither approach dominated.
• Cloud-native pressure: Managed CI/CD services from AWS (CodePipeline), Google (Cloud Build), and Azure were beginning to compete with on-premises or self-hosted alternatives.

Summary

The DevOps platform market entering 2020 was characterized by strong growth, rapid consolidation, and expanding scope — from CI/CD pipelines into value stream management, security (DevSecOps), and AI-assisted operations (AIOps). The vendors listed above represent a snapshot of the competitive field at the close of 2019. Many of these companies have since merged, pivoted, or significantly evolved their product offerings.

For practitioners evaluating DevOps tooling, the more durable takeaway from this period is the importance of assessing tools against your specific workflow needs, team skills, and integration requirements — rather than relying solely on market share rankings.

Note: This article is based on analysis originally published at searchitoperations.techtarget.com (circa late 2019). The competitive landscape has continued to shift since then; see the review notes at the end for key caveats.

Background: From PaaS to Container Ecosystems

Cloud Foundry began life as a comprehensive open source application platform. Its philosophy was to provide a complete development and deployment environment, with applications tightly tied to the PaaS framework it defined. Cloud Foundry originally used its own container orchestrator called Diego before eventually adopting Kubernetes as its orchestration layer.

Red Hat OpenShift similarly started with a proprietary orchestrator (GearD) before pivoting to Kubernetes. Over time OpenShift evolved into a generalized platform for deploying enterprise applications — stateful or stateless, cloud-native or legacy — through containers and Kubernetes. OpenShift no longer defines a programming model; it defines a deployment and operations ecosystem.

A further complication on the Cloud Foundry side: Pivotal, which was the dominant enterprise distributor of Cloud Foundry, was acquired by VMware in 2019. VMware’s Tanzu product suite now competes in the same space as both Cloud Foundry and OpenShift, adding uncertainty to Cloud Foundry’s long-term trajectory.

This history matters because there are two lenses through which you can evaluate these platforms: as a PaaS or as a Kubernetes/container ecosystem. For most enterprises running a diverse mix of application types and development models, a pure PaaS approach is too restrictive. The more relevant question is which platform provides the better Kubernetes ecosystem — and that is the frame for the comparison below.

Architecture

Cloud Foundry retains its PaaS DNA at the architectural level. Its software components are tightly integrated down to the deployment layer, which can force organizations toward Cloud Foundry’s own application development patterns. While Kubernetes now serves as Cloud Foundry’s orchestration layer — meaning containerized applications from any source can technically run on it — those applications are Kubernetes workloads, not Cloud Foundry workloads. The PaaS framework and the Kubernetes layer sit somewhat awkwardly alongside each other.

OpenShift takes a different approach: it is an integrated set of open source tools assembled around the application, not around a development framework. Developers write applications in whatever language and model suits them, then deploy through OpenShift. Any workload that can run in a container can deploy on OpenShift. Tools such as the Istio service mesh may require some application-level design consideration, but they are industry-standard open source components, not proprietary lock-in.

Advantage: OpenShift — its architecture imposes fewer constraints on application design and avoids proprietary lock-in.

Integration

Enterprises rarely move everything to the cloud. The practical value of Kubernetes is that it provides a universal model for running applications across cloud providers and on-premises data centers consistently — but realizing that value depends on how well supporting tools (monitoring, service mesh, security, CI/CD) are integrated into the platform.

Cloud Foundry supports the broader Kubernetes tooling ecosystem for monitoring, hybrid/multi-cloud management, and service mesh. However, these tools are not automatically integrated into a Cloud Foundry deployment; operators must wire them together themselves. Cloud Foundry’s native PaaS components are also predominantly stateless, which creates friction when integrating with the largely stateful applications that live in enterprise data centers.

OpenShift ships as a pre-integrated Kubernetes ecosystem. Monitoring, logging, service discovery, security, and workflow management tools are included and documented as a coherent whole. Operators may tune individual components for their environment, but the baseline integration work is done by Red Hat. This significantly lowers the operational burden for teams adopting the platform.

Advantage: OpenShift — pre-integrated tooling reduces operator effort and lowers the risk of misconfiguration between components.

Front-End and Cloud-Native Application Development

Cloud Foundry’s stateless PaaS model aligns naturally with cloud-native front-end development patterns. The platform includes specific support for building stateless applications and provides infrastructure virtualization that makes application components portable across public cloud and data center hosting environments. For teams building cloud-native application front ends within Cloud Foundry’s framework, this is a genuine strength.

The trade-offs are significant, however. Cloud Foundry carries a large resource footprint on public cloud infrastructure and can be complex to deploy. Teams that want to adopt a serverless or alternative stateless development model outside Cloud Foundry’s PaaS framework must manage that separately alongside the main platform. Cloud Foundry’s low-code/no-code support is also limited — at the time of this analysis, only the Mendix platform was cited as a supported option.

OpenShift does not offer built-in, opinionated support for front-end cloud-native development, but it also does not restrict developers’ choices. Teams can select any low-code/no-code tool, any serverless framework, or any development model and deploy the resulting workloads through OpenShift. This flexibility is more consistent with the diverse tooling realities of enterprise development organizations.

Advantage: OpenShift — platform flexibility outweighs Cloud Foundry’s specific front-end tooling support for most enterprises.

Vendor Outlook and Long-Term Viability

As of late 2019, Cloud Foundry’s vendor situation was uncertain. Pivotal’s acquisition by VMware raised questions about staffing continuity and product direction. The Cloud Foundry Foundation continued to support the project independently, but the loss of Pivotal as a primary commercial backer introduced real uncertainty. VMware’s Tanzu suite further complicated matters by competing in the same general space.

IBM completed its acquisition of Red Hat in 2019, and while the integration of Red Hat’s sales and go-to-market into IBM’s structure introduced its own uncertainties, IBM’s scale provided a substantial financial backstop for OpenShift. Red Hat had already established OpenShift as a flagship next-generation platform, and IBM has continued to invest in it as a centerpiece of its hybrid cloud strategy.

Advantage: OpenShift — stronger and clearer corporate sponsorship as of this analysis, though the landscape continues to evolve.

Summary: OpenShift vs. Cloud Foundry at a Glance

Verdict

For organizations evaluating a Kubernetes-centric container platform, OpenShift holds a clear advantage across architecture, integration, development flexibility, and vendor stability. Cloud Foundry’s PaaS heritage can be a genuine fit for teams building stateless, cloud-native applications within its framework — but for the broad mix of workloads and development models typical in enterprise environments, that framework becomes a constraint rather than an asset.

Existing Cloud Foundry users should monitor how VMware integrates (or doesn’t integrate) Cloud Foundry into its Tanzu strategy, and assess whether continued investment in the platform is justified by their specific use cases. For organizations starting fresh, OpenShift’s Kubernetes-native approach, pre-integrated tooling, and strong corporate backing make it the more pragmatic choice for most enterprise scenarios.

Video: OpenShift Overview

Why Openness Is a Marketing Strategy

Consumers want to trust the brands they support. Achieving that trust requires marketing that feels authentic, transparent, and genuinely engaging—not polished and one-directional. For Tim Yeaton, CMO of Red Hat, the answer is to market the same way Red Hat builds software: openly.

As Tomi Ahonen and Alan Moore observed in their book Communities Dominate Brands, communities of interest have permanently changed the relationship between brands and their customers. At Red Hat, those communities are visible and vocal—and they are watching everything the company does. That scrutiny has pushed Red Hat’s marketing team to adopt the same open methods and platforms that open source software communities rely on every day.

What Is GitHub, and Why Should Marketers Care?

GitHub is one of the world’s most widely used platforms for collaborative software development. Built on top of Git—a version control and source code management system—GitHub serves as a social and technical hub for open source communities worldwide, with tens of millions of registered users.

Git’s core workflow enables any contributor to:

• Fork a repository—create a personal copy of someone else’s project.
• Modify that copy independently.
• Submit a pull request to merge changes back into the original project.

This workflow is the engine of open source innovation. It enables transparent, meritocratic collaboration across organizational and geographic boundaries. For marketers, those same properties—transparency, community feedback, version history—translate into practical tools for building audience trust.

Three Ways Marketers Can Apply Open Source Principles on GitHub

1. Give Back by Sharing Valuable Resources

Modern marketing increasingly links brands to a spirit of giving. TOMS Shoes donates a pair of shoes for every pair sold; Warby Parker provides free or discounted eyewear alongside each purchase. These models build reputation because they extend genuine value beyond the transaction.

GitHub gives marketers a channel to do something similar with knowledge assets. By publishing content, datasets, templates, or design files openly, brands allow anyone to use, adapt, and build on those materials. That act of sharing fosters goodwill and demonstrates that a brand’s value proposition extends beyond its own revenue interests.

2. Build Authentic Connections Through Transparency

Research consistently finds that authenticity is a primary factor in consumer brand loyalty. GitHub’s version control history makes authenticity structural rather than aspirational: every change to a project is recorded, attributed, and visible. Audiences can follow along as content evolves, comment on individual changes, or propose their own modifications.

Red Hat’s own CO.LAB program—an on-site STEM engagement initiative for middle-school girls—demonstrates this in practice. CO.LAB publishes its curriculum source files on GitHub, so participants and observers can watch the material develop over time. Attendees don’t just receive a finished product; they contribute to one, and their contributions remain visible and reusable by others.

3. Harness Community Collaboration for Broader Reach

The deepest power GitHub offers marketers is the same power that drives open source software: structured community collaboration. Releasing early-stage marketing materials on GitHub invites communities to improve, remix, and redistribute them—extending the brand’s reach in ways a centralized content team never could.

A compelling example is Jim Whitehurst’s book The Open Organization, published in 2015. After the book’s release, a community of readers continued the conversation on GitHub—writing follow-up volumes that expanded on the original ideas. The project grew into a multi-volume series developed entirely in the open, transparently and collaboratively.

Breaking the Traditional Marketing Mold

Hosting marketing content on an open, third-party platform challenges conventional assumptions. Critics argue that publishing on GitHub diverts traffic away from a brand’s own website, which is typically the primary marketing vehicle. It’s a fair concern.

But Tim Yeaton draws a direct parallel to early objections about open source software itself. Decades ago, skeptics questioned how any company could profit by giving away code. Red Hat answered that question definitively: it was acquired by IBM for approximately $34 billion—a milestone that demonstrated that openness and commercial success are not mutually exclusive.

The same logic applies to marketing. Sharing resources and enabling community participation does not erode brand value—it builds the kind of trust that advertising alone cannot manufacture.

Key Takeaways for DevOps and Tech Marketers

• Transparency builds trust. Showing your work—and letting others comment on it—is more credible than polished one-way messaging.
• GitHub is not just for engineers. Its version control, forking, and community features are applicable to content, curricula, datasets, and design assets.
• Community collaboration scales reach. A meritocratic contribution model allows audiences to extend and amplify your content far beyond what an internal team can produce.
• Open source values translate to marketing strategy. The principles that have driven open source software adoption—sharing, transparency, iterative improvement—can differentiate a brand in saturated markets.
• Giving away value is not the same as losing value. Red Hat’s commercial trajectory is evidence that openness and business growth reinforce each other.

For tech marketers operating in communities that already live and breathe open source culture, adopting these practices is not just strategically sound—it’s a prerequisite for credibility.

Original insights: Tim Yeaton, Chief Marketing Officer, Red Hat. Source: MartechAdvisor.com (2019).

Overview of the Global DevOps Tools Market

The Global DevOps Tools Market Report (2019) offers a broad analysis of the worldwide DevOps tooling industry, examining both its current state and projected trajectory. The report covers market definition, competitive landscape, segmentation by maturity and vertical, and the key forces driving or restraining growth through 2024.

DevOps tools are software platforms and utilities that enable organizations to automate, integrate, and accelerate their software development and IT operations workflows. As enterprises continue to adopt DevOps practices, demand for these tools has grown steadily across nearly every major industry vertical.

Key Vendors Covered

The report profiles a wide range of established and emerging vendors in the DevOps tools ecosystem, including:

• Puppet Labs – Configuration management and infrastructure automation
• Chef – Infrastructure-as-code and compliance automation
• Docker Inc. – Container platform and runtime tooling
• Red Hat (Ansible) – Agentless IT automation and orchestration
• Atlassian – Collaboration, issue tracking (Jira), and CI/CD (Bamboo, Bitbucket Pipelines)
• SaltStack – Event-driven infrastructure automation
• CA Technologies – Enterprise DevOps and agile planning tools
• Rackspace – Managed cloud and DevOps services
• XebiaLabs – Release orchestration and DevOps intelligence
• VersionOne – Agile and scaled agile project management
• Cisco, CollabNet, HP, IBM, Microsoft, Spirent Communications, VMware, DBmaestro

This breadth of coverage reflects the diverse nature of the DevOps tools market, which spans configuration management, containerization, CI/CD pipelines, monitoring, collaboration, and database automation.

Market Segmentation

By DevOps Maturity Level

The report segments the market according to organizational DevOps maturity:

• DevOps Ready – Organizations beginning to adopt DevOps principles, typically focused on toolchain evaluation and cultural change.
• DevOps Enabled – Organizations with established automation pipelines and cross-functional teams actively using DevOps tooling.
• DevOps Capable – Mature organizations with end-to-end automation, continuous delivery, and measurable performance improvement embedded in their engineering culture.

By Industry Vertical

The geographical and vertical segmentation covers the following sectors:

• IT – The primary adopter, with high investment in automation and continuous delivery pipelines.
• BFSI (Banking, Financial Services, and Insurance) – Increasingly investing in DevOps to accelerate secure application delivery and regulatory compliance.
• Retail – Driven by e-commerce growth and the need for rapid feature deployment.
• Telecom – Adopting DevOps to modernize network functions and service delivery.
• Education – Growing adoption for learning management and student service platforms.
• Others – Includes healthcare, government, and manufacturing.

Key Questions the Report Addresses

Market research reports of this type are typically structured around a set of core strategic questions. For the 2019 DevOps Tools report, those include:

1. What is the projected market size and compound annual growth rate (CAGR) for DevOps tools through 2024?
2. What are the dominant market trends shaping tool adoption and vendor strategy?
3. Which factors are driving growth in the DevOps tools industry?
4. What barriers or restraints are limiting market expansion?
5. Who are the leading vendors and what is their competitive positioning?
6. What market opportunities and constraints do key vendors face?
7. How do leading vendors compare across SWOT and PESTEL dimensions?

Growth Drivers and Market Forces

Several structural trends were accelerating DevOps tool adoption as of 2019:

• Cloud-native adoption: The shift toward microservices and containerized workloads increased demand for tools like Docker, Kubernetes operators, and supporting CI/CD infrastructure.
• Agile transformation at scale: Enterprises scaling agile practices beyond individual teams required orchestration, release management, and portfolio-level tooling.
• Security and compliance pressure: The emergence of DevSecOps drove demand for tools that integrate security scanning and policy enforcement into existing pipelines.
• Talent and automation economics: Rising infrastructure complexity and engineering talent costs made automation tooling a cost-effective investment for operations teams.
• Multi-cloud strategies: Organizations managing workloads across AWS, Azure, and GCP needed vendor-agnostic automation and orchestration tools.

Regional Coverage

The report covers DevOps tool adoption and market sizing across major global regions, including:

• North America – The largest market, driven by technology-sector concentration and mature DevOps practices in the United States and Canada.
• Europe – Strong growth driven by GDPR compliance requirements and enterprise digital transformation initiatives.
• Asia-Pacific – Rapidly expanding market, particularly in India, China, and Australia, fueled by a growing software services industry and cloud adoption.
• Rest of World – Including Latin America, the Middle East, and Africa, where adoption is at earlier stages.

Methodology and Report Structure

Market reports of this type typically combine primary research (vendor interviews, surveys) with secondary research (public financial disclosures, analyst databases, and industry publications). Analysis frameworks such as SWOT (Strengths, Weaknesses, Opportunities, Threats) and PESTEL (Political, Economic, Social, Technological, Environmental, Legal) are applied to assess competitive positioning and external market forces.

Data is typically presented through a combination of quantitative charts, market share breakdowns, and qualitative narrative analysis to allow both executive and technical audiences to extract relevant insights.

Takeaways for DevOps Engineers and Architects

For practitioners evaluating toolchain investments, reports like this one can provide useful competitive context—helping teams understand which vendors are gaining market traction, which verticals are investing most heavily, and where the industry is heading. However, vendor-neutral technical evaluation (proof-of-concept testing, community health, integration ecosystem) should always complement market research when making tooling decisions.

Key vendors highlighted in this report—including Ansible, Docker, Atlassian, and Puppet—remain widely used in production environments, though the competitive landscape has continued to evolve significantly since 2019 with the rise of GitOps, platform engineering, and cloud-provider-native CI/CD services.

What Is the DevOps Platform Market?

The global DevOps platform market encompasses the tools, services, and integrated suites that organisations use to automate and accelerate software delivery pipelines — from source control and continuous integration through configuration management, container orchestration, and post-deployment monitoring. Market research covering the 2019–2026 period analyses this space in terms of vendor revenue (USD millions), regional adoption, vertical-industry demand, and competitive positioning.

Major Vendors Operating in the Market

The competitive landscape identified in research reports of this period includes the following organisations:

• Puppet Labs – configuration management and infrastructure automation
• Chef (Progress) – policy-based infrastructure automation and compliance
• Docker Inc. – container runtime, registry, and developer tooling
• Red Hat (Ansible) – agentless automation and OpenShift container platform
• Atlassian – issue tracking (Jira), CI/CD (Bamboo/Bitbucket Pipelines), and collaboration
• SaltStack – event-driven automation and remote execution
• CA Technologies (Broadcom) – enterprise release automation and Agile planning
• Rackspace – managed DevOps and cloud services
• XebiaLabs (Digital.ai) – release orchestration and deployment automation
• VersionOne (Digital.ai) – Agile and SAFe planning
• Cisco – network automation and AppDynamics APM
• CollabNet VersionOne – ALM and value stream management
• HP (Micro Focus) – ALM, load testing, and release management
• IBM – UrbanCode Deploy, cloud-native toolchain services
• Microsoft – Azure DevOps (formerly VSTS), GitHub
• Spirent Communications – network and application test automation
• VMware – Tanzu portfolio, vRealize automation
• DBmaestro – database DevOps and release automation

Market Segmentation

By Platform Maturity Type

Research reports of this period commonly categorise DevOps platform offerings along a maturity continuum:

• DevOps Ready – foundational tooling that supports initial adoption of DevOps practices (e.g., basic CI, version control integration).
• DevOps Enabled – platforms that provide end-to-end pipeline automation and cross-team collaboration features out of the box.
• DevOps Capable – advanced, fully integrated platforms supporting enterprise-scale release orchestration, security (DevSecOps), and value stream management.

By Industry Vertical

Demand for DevOps platforms cuts across multiple industries. Key verticals tracked in market analysis include:

• Information Technology – software vendors and IT service providers driving the largest share of adoption.
• Banking, Financial Services & Insurance (BFSI) – compliance-driven automation and rapid release cycles for digital banking applications.
• Retail & E-Commerce – continuous deployment of customer-facing applications and inventory systems.
• Telecommunications – network function virtualisation and rapid service delivery.
• Education – growing use of cloud-based learning platforms requiring agile delivery.
• Other verticals – healthcare, government, manufacturing, and media.

Regional Market Breakdown

Market reports segment global DevOps platform adoption across the following regions:

• North America (United States, Canada, Mexico) – historically the largest regional market, driven by early cloud adoption and a dense concentration of software vendors.
• Europe (Germany, France, United Kingdom, Russia, Italy) – strong growth driven by GDPR compliance tooling needs and widespread digital transformation programmes.
• Asia-Pacific (China, Japan, South Korea, India, Southeast Asia) – fastest-growing region during the forecast period, propelled by large-scale IT outsourcing industries and cloud investment.
• South America (Brazil, Argentina, Colombia) – emerging adoption, particularly in BFSI and retail.
• Middle East & Africa (Saudi Arabia, UAE, Egypt, Nigeria, South Africa) – nascent but expanding market linked to national digital transformation initiatives.

Key Market Drivers

Several structural forces drive sustained investment in DevOps platforms:

• Accelerating software delivery expectations – organisations face competitive pressure to release features faster without sacrificing stability.
• Cloud-native adoption – migration to public and hybrid cloud environments creates demand for integrated CI/CD, container orchestration, and infrastructure-as-code tooling.
• Security and compliance automation (DevSecOps) – regulated industries require security checks embedded into pipelines rather than bolted on at release time.
• Microservices and container proliferation – decomposed architectures require sophisticated orchestration and observability tooling.
• Remote and distributed engineering teams – collaboration tooling and asynchronous pipeline automation become critical for globally distributed workforces.

Key Market Restraints

• Cultural and organisational resistance – DevOps transformation requires process and people change, not just tooling purchase.
• Complexity of integrating heterogeneous tool chains – enterprises running legacy systems face significant integration costs.
• Skills shortages – demand for engineers proficient in automation, containers, and cloud-native practices outstrips supply in most markets.
• Vendor lock-in concerns – organisations worry about dependency on a single platform vendor for critical delivery pipelines.

Competitive Analysis Framework

Market research reports of this type typically apply the following analytical frameworks to evaluate vendors and market structure:

• Porter’s Five Forces – assesses the threat from new entrants (low to medium, given high integration complexity), supplier bargaining power (cloud hyperscalers hold significant leverage), substitute threats (open-source toolchains), buyer power (large enterprises can negotiate), and competitive rivalry (intense, with consolidation accelerating).
• SWOT Analysis – per-vendor assessment of strengths, weaknesses, opportunities, and threats.
• Value Chain Analysis – maps upstream (cloud infrastructure, open-source communities) and downstream (system integrators, end-user enterprises) participants.

Forecast Period and Historical Baseline

Reports covering this market typically use the following time frame:

• Historical data: 2014–2018
• Base year: 2019
• Forecast period: 2019–2026

Projections cover global and regional revenue, production and consumption volumes, import/export data where applicable, price trends, and segment-level growth rates (CAGR). Specific CAGR and revenue figures vary across research publishers and should be cross-referenced against multiple sources before being used for investment decisions.

How to Use This Type of Market Report

DevOps engineers and architects rarely make purchasing decisions based solely on market research reports. However, these reports can be useful for:

• Building internal business cases – market size and growth-rate data support budget requests for platform tooling.
• Competitive benchmarking – understanding where your organisation’s tooling maturity sits relative to industry peers.
• Vendor due diligence – SWOT and financial performance data help assess vendor viability before committing to a long-term platform contract.
• Strategic roadmap planning – regional and vertical adoption trends highlight where investment is concentrating and which capabilities are becoming table stakes.

Notable Market Developments Since 2019

The DevOps platform landscape shifted significantly after the base year of this report. Key developments that engineers should factor into any current analysis include:

• Microsoft’s acquisition of GitHub (completed 2018) and subsequent deep Azure DevOps integration expanded Microsoft’s share of the developer toolchain significantly.
• VMware’s acquisition of Pivotal and the subsequent launch of the Tanzu portfolio repositioned VMware as a cloud-native platform vendor.
• XebiaLabs and VersionOne merged under the Digital.ai brand, consolidating value stream management capabilities.
• HashiCorp’s growth in infrastructure-as-code (Terraform, Vault) made it a significant market participant not always captured in earlier reports.
• The rise of GitOps practices and tools such as Argo CD and Flux shifted some CD workloads away from traditional CI/CD platforms.
• Docker Inc. restructured in 2019, selling its enterprise business to Mirantis, significantly altering its market position.

Any organisation using a 2019-baseline report for current platform decisions should supplement it with up-to-date analyst coverage and direct vendor evaluation.

Introduction

DevOps is a discipline that evolves rapidly — practices, tooling, and cultural norms shift almost continuously. Looking back at 2019, several clear trends emerged that defined how engineering teams built, secured, and operated software at scale. Below is a structured breakdown of the ten most significant DevOps trends from that year, many of which continue to influence the industry today.

1. Pipeline Automation

Automation has always been central to DevOps philosophy, and 2019 saw it deepen further. Continuous integration and continuous delivery (CI/CD) tooling continued to proliferate, with GitHub’s introduction of GitHub Actions expanding the ecosystem of pipeline automation options available to teams.

Closely tied to CI/CD growth is the maturation of infrastructure as code (IaC). Tools such as Terraform, AWS CloudFormation, Azure Resource Manager, and GCP’s Deployment Manager became standard practice, allowing teams to provision and tear down environments programmatically — whether during local development, inside CI pipelines, or even in production delivery workflows.

2. Kubernetes Dominance

Kubernetes was virtually inescapable in 2019. Since its release in 2014 and general availability in 2015, it established itself as the leading container orchestration platform, accumulating far more community mindshare than competitors such as Apache Mesos or Docker Swarm.

Major enterprise vendors including Red Hat and VMware committed deeply to Kubernetes support, and an increasing number of software vendors began shipping their products with Kubernetes-native deployment as the default. While Kubernetes had not yet proven itself universally across every class of workload, the momentum behind it remained strong heading into 2020.

3. Service Meshes

As Kubernetes adoption expanded, so did conversations about service meshes. A service mesh is software that manages service-to-service communication within a distributed platform. Rather than requiring each application team to implement their own solutions for common concerns, a service mesh provides these capabilities at the platform level.

Typical service mesh capabilities include:

• Load balancing
• Mutual TLS encryption
• Authentication and authorisation
• Traffic proxying and routing
• Observability and tracing

By moving these concerns out of application code and into the platform layer, service meshes free development teams to focus on business logic rather than distributed systems boilerplate.

4. Observability

Observability is frequently conflated with monitoring, but the distinction is important. Monitoring is an activity — you monitor a system. Observability is a property of a system — it describes whether the internal state of that system can be reliably inferred from its external outputs.

The concept originates in control theory and real-world engineering. For software systems, high observability means that when something goes wrong, engineers can determine the root cause quickly from the data the system already emits — logs, metrics, and traces — without needing to instrument it further after the fact.

Related to observability is the concept of cardinality — the number of distinct values in a time-series dataset. Higher cardinality generally means more granular data, which supports more precise troubleshooting. However, high-cardinality data also carries storage and query costs, so teams must balance richness of data against operational overhead.

5. DevSecOps

Security traditionally sat outside the development pipeline — something applied as a gate at the end, or retrofitted after incidents. DevSecOps challenges this by integrating security practices directly into CI/CD pipelines and making security a shared responsibility across development, operations, and SRE teams.

Key developments in this space in 2019 included:

• Compliance as code tools such as InSpec, which allow security and compliance checks to be written, versioned, and run automatically as part of pipelines.
• Container image scanning tools such as Aqua Security and Sysdig, which inspect images for known vulnerabilities before they are deployed.
• Growing awareness of the need to embed security at every stage of the software delivery lifecycle rather than treating it as a final checkpoint.

The broader portmanteau “DevSecNetQAGovOps” was occasionally floated to describe even more holistic pipeline integration, though DevSecOps remained the dominant and most practical framing.

6. The Rise of Site Reliability Engineering (SRE)

Site Reliability Engineering (SRE) is a discipline that originated at Google in 2003 — predating the term “DevOps” entirely. It was later documented in Google’s book Site Reliability Engineering. The core idea is to treat operations as a software engineering problem: SRE teams write code to automate reliability, define error budgets, and maintain service level objectives (SLOs).

Unlike a traditional DevOps team structure where one team owns the full lifecycle, SRE acknowledges that at very large scale, a dedicated reliability engineering function may be necessary. At Google’s scale — hundreds of data centres, vast standardised infrastructure — a single cross-functional team owning every service end-to-end is not practical.

In 2019, job postings for “SRE Engineer” roles reportedly began to outnumber those for “DevOps Engineer” at many organisations. This reflects both the growing influence of the SRE model and a desire by organisations to signal a specific, engineering-focused operational capability.

7. Artificial Intelligence and Machine Learning in DevOps

The application of machine learning (ML) to DevOps tooling began gaining traction in 2019, though the space was still early-stage. Emerging use cases included:

• Anomaly detection: ML models trained on historical application behaviour to flag deviations that may indicate incidents before they escalate.
• Test optimisation: Using ML to determine which test cases are most likely to catch regressions on a given build, reducing CI pipeline duration without sacrificing coverage.
• Predictive infrastructure management: Google published research on using ML models to predict hardware failures ahead of time, enabling proactive remediation.

Products such as ScienceLogic’s SL1 were early entrants in the AI-assisted operations (AIOps) market. The category was still nascent, but directionally significant.

8. Serverless Computing

Serverless computing — popularised by AWS Lambda when it launched in 2014 — continued to grow in 2019 as other cloud providers and open-source projects expanded the ecosystem. The term “serverless” can be misleading: servers are still involved. What it actually means is that the developer does not manage server provisioning or scaling. The cloud provider handles infrastructure entirely; the developer deploys code and pays for execution time.

Key considerations for serverless adoption include:

• Vendor lock-in: Serverless applications are typically tightly coupled to the platform they run on, making portability a genuine concern.
• Cold start latency: Functions that have not run recently may incur startup delays.
• Use-case fit: Serverless suits event-driven, short-lived workloads well, but is less suited for long-running or stateful processes.

9. Shifting Left and Shifting Right in CI/CD

As release cycles shortened, the concepts of shift-left and shift-right testing gained wider recognition.

Shift left refers to moving quality checks earlier in the development process — catching problems as close to the point of authorship as possible. This includes not just unit and integration testing, but also code linting, static analysis, dependency vulnerability scanning, and security checks. The earlier a defect is caught, the cheaper it is to fix.

Shift right refers to testing in production or production-like environments, intentionally surfacing issues that only manifest at scale or under real user traffic. Techniques include canary deployments, feature flags, chaos engineering, and synthetic monitoring. The goal is to discover failure modes before users report them.

10. The CALMS Framework as a Unifying Lens

While not a new trend in 2019, the CALMS framework — standing for Culture, Automation, Lean, Measurement, and Sharing — provided a useful lens through which to evaluate all of the above trends. Each of the nine trends described above can be mapped to one or more of these principles:

• Culture: DevSecOps, SRE, and the organisational changes they require
• Automation: Pipeline automation, IaC, and serverless
• Lean: Shift-left testing, reducing waste in release cycles
• Measurement: Observability and AI-assisted monitoring
• Sharing: Kubernetes ecosystems, service meshes, and open tooling

Summary

The DevOps landscape in 2019 was characterised by the maturation of container orchestration, growing security integration, and the early application of machine learning to operational problems. Many of these trends — Kubernetes, observability, DevSecOps, and SRE — have since become foundational rather than emergent. Understanding where they stood in 2019 provides useful context for appreciating how far the discipline has evolved since.

The Infrastructure Complexity Problem for Data Scientists

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

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

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

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

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

Kubernetes Operators as the New Deployment Pattern

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

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

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

Diane Mueller, Red Hat Inc.

OperatorHub.io: A Shared Marketplace for Kubernetes Operators

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

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

Diane Mueller, Red Hat Inc.

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

The NVIDIA GPU Operator: Four Phases of Automation

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

Phase 1: Component Installation

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

Phase 2: Infrastructure Automation and Updates

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

Phase 3: Lifecycle Management and Self-Healing

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

Phase 4: Monitoring and Observability

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

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

Renaud Gaubert, NVIDIA Corp.

Why This Matters for AI/ML Teams

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

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

Further Resources

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

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

The Cloud Landscape Heading into 2020

The cloud computing market entered 2020 on the back of a transformative 2019. Forrester had predicted that enterprises would begin modernizing core business applications with cloud platforms, and that migration did accelerate. At the same time, major industry moves reshaped competitive dynamics: IBM completed its acquisition of Red Hat, VMware reabsorbed Pivotal, Oracle partnered with Microsoft on high-speed connectivity between Oracle Cloud and Azure, and VMware brought its Cloud Foundation to Google Cloud.

These moves signaled a market in flux — longtime competitors forming pragmatic alliances, and incumbents doubling down on their core strengths rather than fighting on all fronts simultaneously.

Market Size and Adoption Benchmarks

According to Forrester’s projections made in late 2019, the combined public cloud market — spanning SaaS (cloud applications), PaaS (development and data platforms), and IaaS (infrastructure services) — was forecast to reach $299.4 billion in 2020. While growth rates were expected to moderate, analysts framed this as a sign of a maturing, consolidating market on a trajectory toward half a trillion dollars within a few years.

Adoption figures at the time reflected broad enterprise commitment to cloud:

• 65% of North American enterprises relied on public cloud platforms.
• 66% ran internal private clouds.

Key Prediction 1: Hyperscalers Refocus — IBM, Oracle Retreat to Strengths While Alibaba Challenges Google

Forrester anticipated that neither IBM nor Oracle would exit the hyperscale public cloud market — then dominated by AWS, Microsoft Azure, Google Cloud, and Alibaba Cloud — but that each would strategically narrow their focus.

• IBM was expected to concentrate on helping enterprises use Red Hat’s OpenShift container platform to modernize core business applications across any cloud environment, rather than competing head-to-head with AWS or Azure on general-purpose infrastructure.
• Oracle was predicted to lean into its SaaS portfolio and autonomous database products, pointing customers toward Azure for general-purpose cloud services such as AI/ML, Kubernetes, containers, and IoT workloads. Analysts also expected Oracle to finalize high-speed connectivity agreements with AWS or Google to better serve its enterprise database customers.
• Alibaba Cloud was projected to generate approximately $4.5 billion in global cloud platform revenue, surpassing Google Cloud globally. However, Google was expected to retain its third-place ranking among North American clients due to Alibaba’s limited footprint in that region.

The broader theme: the hyperscale cloud wars were no longer purely about raw infrastructure competition. Specialization, strategic partnerships, and ecosystem control were becoming the primary battlegrounds.

Key Prediction 2: Open Source Cloud-Native Development Battles — Service Meshes and Serverless

With Kubernetes having effectively won the container orchestration category by 2019, Forrester turned its attention to the next wave of cloud-native technology battles: service meshes and serverless computing.

The cloud-native ecosystem was characterized by hundreds of competing open source projects and vendors. Two areas were expected to see concentrated competition in 2020:

• Service meshes promise advanced interservice networking, observability, and security for microservices architectures. Istio was identified as the standout project in this space.
• Serverless computing abstracts infrastructure entirely from developers, enabling event-driven programming models. Knative was considered a strong foundation for enterprise serverless adoption.

Forrester’s expectation was that neither Istio nor Knative would be adopted as standalone open source tools by most enterprises. Instead, both would most likely be consumed as components of integrated cloud-native development platforms offered by major vendors: AWS, Microsoft, Google, VMware/Pivotal, or IBM/Red Hat.

This pattern — open source innovation eventually absorbed into commercial platform offerings — was seen as the dominant adoption model for enterprise cloud-native tooling.

Key Prediction 3: Cloud Management Vendors Must Tackle Security

The Capital One data breach — which exposed over 100 million customer records stored in AWS — became a defining moment for cloud security in 2019. The incident demonstrated that misconfigured cloud environments, not necessarily flaws in cloud provider infrastructure, were a primary attack vector.

Forrester predicted that this breach, and others like it, would push cloud management vendors to elevate security from a secondary concern to a primary product focus. Specifically:

• Hyperscale cloud providers were expected to increase investment in native security tooling and services.
• Cross-cloud management vendors would need to go beyond traditional identity and access management (IAM), building or acquiring capabilities such as workload security, posture management, and runtime protection.
• VMware’s acquisition of Carbon Black in 2019 was cited as an early example of this shift — embedding security capabilities throughout cloud management, virtualization, and container products.

The underlying message: in an increasingly hybrid cloud world, security could no longer be bolted on after deployment. It needed to be integrated into the platforms that enterprises used to manage cloud infrastructure from the ground up.

Summary: Five Themes Forrester Identified for 2020

1. Hyperscale public cloud leaders would form more alliances while refocusing on core strengths.
2. Leading business application vendors would begin abandoning proprietary infrastructure stacks.
3. High-performance computing (HPC) adoption on cloud would accelerate.
4. The cloud-native development ecosystem would converge around service meshes and serverless platforms.
5. Cloud management vendors would shift focus to security in response to major breach events.

For DevOps teams and platform engineers, these predictions pointed toward several practical priorities: evaluating service mesh tooling before the market locked in, treating cloud security posture management as a first-class engineering concern, and watching how IBM, Oracle, and the hyperscalers redefined their platform boundaries in 2020.

Source: Forrester Research 2020 Cloud Predictions, as reported by ZDNet (November 2019).

The container orchestration tool Kubernetes continues to gain momentum as enterprises leap from pilot projects to production. Here’s how Bloomberg, News UK, and the travel data provider Amadeus are putting Kubernetes to work

Ever since it emerged out of the halls of Google five years ago, Kubernetes has quickly become one of the hot technologies of the decade.

Simply put, Kubernetes is now the undisputed platform of choice for composing and running applications comprised of microservices – small, independently deployable services that run in containers and work together to function as a larger application that can be ported across various types of infrastructure.

Kubernetes is an orchestration tool, which in this case means it enables developers to view, coordinate, and manage containerised workloads and services with the goal of running resilient distributed systems.

According to the latest figures from the Cloud Native Computing Foundation (CNCF), published in August 2018, 40 per cent of respondents from enterprise companies (over 5000 firms) are already running Kubernetes in production.

While that’s good progress for the open source project, it’s important to note that the vast majority of these organisations are running only a handful of applications with Kubernetes as they get to grips with the technology.

But the direction of travel is clear: Container-based microservices applications are the future and Kubernetes is their platform.

That’s why the big three cloud providers have all launched managed versions of Kubernetes – and Cisco, HPE, IBM/Red Hat, Microsoft, VMware/Pivotal, and others have incorporated Kubernetes into their core software offerings.

Kubernetes is enabling enterprises of all sizes to improve their developer velocity, nimbly deploy and scale applications, and modernise their technology stacks.

For example, the online retailer Ocado, which has been delivering fresh groceries to UK households since 2000, has built its own technology platform to manage logistics and warehouses. In 2017, the company decided to start migrating its Docker containers to Kubernetes, taking its first application into production in the summer of 2017 on its own private cloud.

The big benefits of this shift for Ocado and others have been much quicker time-to-market and more efficient use of computing resources.

At the same time, Kubernetes adopters also tend to cite the same drawback: The learning curve is steep, and although the technology makes life easier for developers in the long run, it doesn’t make life less complex.

Here are some examples of large global companies running Kubernetes in production, how they got there, and what they have learned along the way.

Bloomberg reaps the benefits of early adoption

Financial data specialist Bloomberg turned to Kubernetes in 2015, when the tool was still in alpha, before moving into production in 2017 once the necessary continuous integration, monitoring, and testing was proved out.

Bloomberg processes hundreds of billions of financial data points every day, with 14,000 different applications powering its ubiquitous Terminal product alone. The IT organization wanted to boost the speed at which it could bring new applications and services to users and free up developers from operational tasks.

After assessing various orchestration platforms, such as Cloud Foundry, Mesosphere Marathon, and various Docker offerings, Bloomberg opted for Kubernetes because it “had a good foundation and it was clear they were confronting the right problems. You could see a vision and roadmap as to how it would evolve that were aligned with what we were thinking,” explains Andrey Rybka, head of the compute infrastructure team at Bloomberg.

Over time Bloomberg has worked on a homegrown platform-as-a-service layer on top of Kubernetes to give developers the right level of abstraction to work effectively with the technology. This self-service web portal is essentially a command-line interface and REST API which integrates with a Git-based version control system, CI build system, and central artifact repository.

One of the key goals for Bloomberg was to make better use of existing hardware investments using the autoscaling capabilities of Kubernetes, along with the ability to self-provision and flex virtual compute, networking, and storage without having to issue tickets.

“With Kubernetes, we’re able to very efficiently use our hardware to the point where we can get close to 90 to 95 percent utilisation rates” at times of peak demand, Rybka said as part of a CNCF case study. Much of that efficiency comes from the ability to constrain resources for a given workload, so it doesn’t starve other workloads.

As is the case with most enterprises adopting Kubernetes in production, the main challenges arose around the use of YAML to write manifests, which specify how Kubernetes allocates resources. “These are powerful concepts in Kubernetes that require a steep learning curve,” Rybka said.

As Bower put it: “Kubernetes makes a lot of things easier but not necessarily simpler.”

As a result, Bloomberg started with basic manifests, limited to a small subset of criteria from which developers could scale up their usage as they got more comfortable with the technology, as well as running plenty of internal training programs.

“We have a lot of existing infrastructure and there is zero chance that will miraculously move to Kubernetes off big iron [mainframes],” he said. Instead the orchestration platform is being targeted at web-based applications and net-new systems.

In the data and analytics Infrastructure team, where Bower works, the initial approach was to stand up a new data science compute platform for the machine learning engineers to run complex workloads using tools like Spark and TensorFlow.

As his parting piece of advice, Rybka talked about the importance of building expertise. “You really have to have an expert team that is in touch with upstream Kubernetes and the CNCF and the whole ecosystem to have that in-house knowledge. You can’t just rely on a vendor and need to understand all the complexities around this,” he said.

News UK taps Kubernetes to scale on demand

The UK arm of media giant News Corp has been dabbling with Kubernetes since 2017, moving from their own custom Kubernetes clusters to the managed Elastic Kubernetes Service (EKS) from Amazon Web Services in 2018.

This makes up part of a stack that also includes a bunch of AWS services, including Elastic Container Service, the Fargate compute engine, AWS Batch, and Elastic Beanstalk.

KubeCon + CloudNativeCon 2019: The Cloud Native Ecosystem in Full Force

The Cloud Native Computing Foundation (CNCF) is responsible for governing the open source projects that form the critical building blocks of modern infrastructure. Its most prominent project, Kubernetes, has become the de facto standard for container orchestration at scale.

By 2019, CNCF had grown to over 20 hosted projects and 500 member organizations, representing one of the most active open source communities in the industry. KubeCon + CloudNativeCon 2019 saw a reported 50% increase in attendance compared to the previous year’s event in Seattle, drawing participants from traditional infrastructure incumbents like HPE and VMware through to early-stage startups.

More than 100 announcements emerged from the event. Below are ten of the most technically significant.

1. Helm 3 Is Launched

Helm — a CNCF incubating project and the most widely used package manager for Kubernetes — released its third major version at the event. Helm is maintained primarily by contributors from Microsoft, Google, Codefresh, and Bitnami.

The headline change in Helm 3 is the removal of Tiller, the server-side component that previously ran inside the Kubernetes cluster and was a persistent source of security and operational complaints. By eliminating Tiller, Helm 3 relies entirely on kubeconfig credentials and Kubernetes RBAC for access control, significantly simplifying the security model.

A migration path from Helm 2 to Helm 3 was published alongside the release to help teams upgrade existing chart deployments.

2. AWS, Intuit, and Weaveworks Collaborate on Argo Flux and the GitOps Engine

Two of the most prominent GitOps tools in the Kubernetes ecosystem — Argo CD (developed at Intuit) and Flux (developed at Weaveworks) — had significant functional overlap. At KubeCon 2019, the two teams announced a collaboration, informally referred to as Argo Flux, to converge their shared core logic into a common library called the GitOps Engine.

AWS added momentum to the collaboration by announcing it would integrate GitOps tooling based on this work into Amazon Elastic Kubernetes Service (EKS), and would use Flagger for canary deployments on AWS App Mesh.

The GitOps Engine project aimed to allow different CD tools to share a common, well-tested reconciliation layer, reducing duplication across the ecosystem.

3. Microsoft Brings Confidential Computing to Kubernetes

Microsoft announced support for confidential computing within Kubernetes, leveraging Intel Software Guard Extensions (Intel SGX). Confidential computing protects data in use — meaning data remains encrypted and isolated even while code is actively executing on the CPU, guarding against privileged-access attacks or compromised hypervisors.

Azure customers can create AKS clusters with SGX-capable nodes and install the confidential computing device plugin. Workloads built with the Open Enclave SDK can then be scheduled onto nodes that support Trusted Execution Environments (TEEs), enabling hardware-enforced isolation at the pod level.

4. Red Hat Launches CodeReady Workspaces 2.0

Red Hat’s CodeReady Workspaces, first announced in February 2019, is a browser-based, Kubernetes-native development environment built on the open source Eclipse Che IDE project. It is optimized for Red Hat OpenShift and RHEL environments.

Version 2.0 deepened the integration between the development environment and OpenShift production clusters, allowing developers to build and test applications in an environment that closely mirrors production. The goal is to eliminate the classic “works on my machine” problem by providing workspace definitions as code that all team members share.

5. Mirantis Launches Kubernetes as a Service (KaaS)

Mirantis announced a continuously updated, multi-cloud Kubernetes as a Service (KaaS) offering built on upstream, unmodified Kubernetes — without proprietary API extensions — to ensure application portability across cloud providers.

The announcement followed Mirantis’s high-profile acquisition of Docker’s enterprise business, signalling a strategic pivot toward Kubernetes-centric enterprise infrastructure.

6. O’Reilly Acquires Katacoda

Katacoda provides browser-based, interactive learning environments that spin up real Linux and Kubernetes infrastructure on demand — no local installation required. Users practice with the actual tools they would use in production, making it uniquely effective for hands-on DevOps and cloud native training.

O’Reilly’s acquisition of Katacoda extended its online learning platform with real-environment, scenario-based labs, enabling learners to move from reading about a technology to interacting with it without leaving the browser.

7. Portworx Launches PX-Autopilot

Portworx, a leading provider of container-native persistent storage, announced PX-Autopilot: a policy-driven automation layer that monitors storage consumption and automatically provisions additional block storage or resizes existing volumes when usage crosses a pre-configured threshold.

The product addresses a real operational pain point — stateful applications on Kubernetes that run out of disk space often fail in ways that are difficult to recover from. PX-Autopilot effectively brings autoscaling concepts, familiar from compute, to the storage layer in a cloud native context.

8. Diamanti Announces Spektra Hybrid Cloud Platform

Hyper-converged infrastructure vendor Diamanti announced Spektra, a hybrid cloud management platform designed to manage the full lifecycle of containerized workloads spanning on-premises infrastructure and public clouds.

Spektra provides a unified control plane — a single pane of glass — for managing storage across multiple registered Kubernetes clusters, and supports moving both applications and persistent data between clusters with minimal disruption. This addresses a key challenge for enterprises running workloads across heterogeneous Kubernetes environments.

9. Buoyant Announces Dive, a SaaS Control Plane for Kubernetes

Buoyant, the company behind the Linkerd service mesh, announced the private beta of Dive, a multi-tenant SaaS control plane for managing Kubernetes deployments at scale.

Dive is designed to make infrastructure changes auditable and collaborative: every change generates a permalink that teams can reference in Slack, issue trackers, or pull requests. Individual services get a dedicated homepage that can include SLOs, runbook links, and ownership metadata — effectively treating services as first-class objects with discoverable operational context.

Dive extends Linkerd’s observability and traffic management capabilities with a managed, multi-cluster control experience.

10. Rancher Announces General Availability of K3s for Edge Kubernetes

Rancher Labs announced the general availability of K3s, a lightweight, fully CNCF-certified Kubernetes distribution purpose-built for resource-constrained environments such as IoT devices, edge nodes, and ARM-based hardware.

K3s is distributed as a single binary with a minimal footprint, stripping out cloud-provider integrations and legacy features that are unnecessary at the edge. Rancher partnered with ARM to optimize K3s for ARM architectures, making it practical to run a conformant Kubernetes distribution on devices that would otherwise be unable to support a standard Kubernetes installation.

Key Takeaways

• Maturity of the ecosystem: Announcements like Helm 3 and the GitOps Engine reflect the community moving from experimentation to production-grade tooling with clearly defined operational models.
• Security is a first-class concern: Microsoft’s confidential computing integration shows hardware-level security entering the Kubernetes stack.
• Edge and IoT adoption: K3s from Rancher signals Kubernetes expanding well beyond the data centre.
• Storage automation closing the gap: PX-Autopilot and Spektra address persistent pain points around stateful workloads that have historically lagged behind compute automation.
• Developer experience investment: CodeReady Workspaces 2.0 and the Katacoda acquisition reflect growing investment in reducing friction for developers working in cloud native environments.

KubeCon + CloudNativeCon 2019 confirmed that Kubernetes has moved decisively from early adopter territory into mainstream enterprise infrastructure, with the surrounding ecosystem maturing rapidly to match.

What Is the Ansible Automation Platform?

The Ansible Automation Platform brings together several components under one umbrella:

• Red Hat Ansible Tower – the control plane for managing, scheduling, and delegating automation jobs
• Red Hat Ansible Engine – the core runtime that executes playbooks and modules
• Red Hat Network Automation – purpose-built automation for network infrastructure
• New SaaS capabilities – Ansible Content Collections, Automation Hub, and Automation Analytics

Whether an organization is just beginning its automation journey or looking to scale automation across additional use cases and domains, the platform is designed to reduce the time to value by providing reusable, certified building blocks instead of requiring teams to start from scratch.

Key New Capabilities

Three new features shipped with the Ansible Automation Platform launch address content management, certified content discovery, and operational visibility.

Ansible Content Collections

Ansible has one of the largest open-source automation communities in the world, producing a continuous stream of modules, plugins, roles, and playbooks from Red Hat engineers, independent contributors, and technology partners. Before Content Collections, distributing and consuming this content was tightly coupled to Ansible release cycles, making it difficult to ship or consume updates independently.

Ansible Content Collections introduce a new packaging format that decouples content distribution from core Ansible releases. A Collection bundles modules, plugins, roles, and playbooks into a single distributable unit, allowing contributors to publish updates on their own schedule and allowing consumers to adopt new content without waiting for a new Ansible Engine release.

Key benefits of Content Collections:

• Lowers the barrier to entry for new automation adopters by providing pre-built, ready-to-use content
• Reduces maintenance overhead by scoping updates to individual collections rather than requiring full platform upgrades
• Enables partners and contributors to ship certified automation content independently

Automation Hub

Automation Hub is the centralized, hosted repository where Red Hat and its certified partners publish Ansible Content Collections. For enterprise customers, it is the primary place to discover and consume content that has been tested and is backed by Red Hat support.

At the time of the platform launch, partners including Cisco, F5, Google Cloud, Microsoft, and NetApp announced plans to publish certified, supported Collections through Automation Hub. This gives teams a curated, trusted source of automation content for common infrastructure and cloud platforms, reducing the risk associated with using community-sourced modules in production environments.

The distinction between certified content (available through Automation Hub) and community content (available through Ansible Galaxy) is important for enterprises with compliance or support requirements: certified Collections carry Red Hat’s quality and support guarantee, while Galaxy content does not.

Automation Analytics

Automation Analytics provides operational visibility into how automation is performing across an organization’s Ansible Automation Platform deployments. Rather than treating automation as a black box, the feature surfaces data that helps teams understand and improve their automation programs over time.

Automation Analytics surfaces information such as:

• Which modules and resources are used most frequently across the environment
• The overall health and performance of automation jobs
• Automation activity broken down by internal team or group

An opt-in benchmarking feature allows organizations to share anonymized automation metrics with Red Hat in exchange for seeing how their automation maturity compares to industry peer groups. This can help identify gaps and prioritize where to invest further in automation.

Why This Matters for DevOps and Platform Engineering Teams

The Ansible Automation Platform represents a shift in how Red Hat positions Ansible for enterprises: from a task-automation tool to a full automation operating model. The integration of content management (Collections), a certified content marketplace (Automation Hub), and operational telemetry (Automation Analytics) addresses three common friction points that organizations encounter as they try to scale automation beyond individual teams:

• Content sprawl – teams reinventing automation for the same systems because there is no shared, trusted library
• Governance gaps – uncertainty about whether community modules meet security or quality standards for production use
• Visibility deficits – no consistent way to measure automation coverage, performance, or ROI across the organization

By addressing these challenges within a single platform, Red Hat is positioning Ansible not just as an automation engine but as the foundation for an organization-wide automation practice.

Original announcement sourced from e3zine.com (November 2019).

Overview of the Global DevOps Platform Market (2019)

By 2019, the DevOps platform market had matured from a collection of niche tooling experiments into a significant and competitive global industry. Organizations across every major vertical—from financial services to retail to telecommunications—were investing in platforms that could unify development, testing, deployment, and operations workflows. Market research published in 2019 reflected strong growth expectations driven by increasing adoption of cloud-native architectures, container orchestration, and infrastructure-as-code practices.

The research examined market structure, competitive dynamics, regional demand, and industry-vertical breakdown, using frameworks such as SWOT analysis to assess the strategic positions of leading vendors. Compound Annual Growth Rate (CAGR) projections were included to help enterprise buyers and investors model medium-term market trajectories.

Major DevOps Platform Vendors Covered

The 2019 report highlighted a broad ecosystem of vendors competing across different layers of the DevOps toolchain. Key players included:

• Puppet Labs – Infrastructure automation and configuration management
• Chef (now Progress Chef) – Policy-based infrastructure automation
• Docker Inc. – Container runtime and image distribution
• Red Hat (Ansible) – Agentless IT automation and orchestration
• Atlassian – Developer collaboration, issue tracking, and CI/CD (Jira, Bitbucket, Bamboo)
• SaltStack – Event-driven automation and remote execution
• CA Technologies – Enterprise DevOps lifecycle management
• Rackspace – Managed cloud and DevOps services
• XebiaLabs – Release orchestration and deployment automation
• VersionOne – Agile and DevOps planning
• Cisco – Network automation and infrastructure integration
• CollabNet – Agile ALM and DevOps toolchain integration
• HP (Micro Focus) – Enterprise testing and application lifecycle management
• IBM – Hybrid cloud DevOps and AI-assisted operations
• Microsoft – Azure DevOps (formerly VSTS), GitHub
• Spirent Communications – Network and application test automation
• VMware – Virtualization-layer DevOps and cloud management
• DBmaestro – Database DevOps and release automation

This breadth of vendors illustrates that by 2019 the DevOps platform space was not dominated by a single vendor. Buyers frequently assembled best-of-breed toolchains rather than purchasing an all-in-one suite, which drove integration and interoperability as key competitive factors.

Market Segmentation: Maturity Tiers and Industry Verticals

DevOps Maturity Segments

The report segmented adopting organizations by their level of DevOps practice maturity:

• DevOps Ready – Organizations that have assessed their readiness and initiated foundational tooling or training but have not yet transformed delivery pipelines end-to-end.
• DevOps Enabled – Organizations with established CI/CD pipelines, automated testing, and some degree of infrastructure-as-code in production.
• DevOps Capable – Fully mature adopters integrating security (DevSecOps), observability, and continuous feedback loops across the full software delivery lifecycle.

Understanding these tiers matters commercially because vendors must pitch different capabilities and price points depending on where a prospect sits on the maturity curve. A “DevOps Ready” buyer needs onboarding support and training; a “DevOps Capable” enterprise needs advanced analytics, compliance automation, and enterprise support SLAs.

Industry Vertical Segments

Demand was analyzed across the following verticals:

• IT & Technology – The natural early-adopter segment, driving platform innovation and setting procurement patterns that other verticals follow.
• BFSI (Banking, Financial Services & Insurance) – High compliance requirements created demand for audit trails, role-based access, and policy-as-code capabilities.
• Retail & E-Commerce – Seasonal release pressure and omnichannel demands pushed adoption of automated deployment and feature-flag tooling.
• Telecom – Network function virtualization (NFV) and 5G rollouts accelerated DevOps adoption for both software and infrastructure delivery.
• Education – Slower growth, but increasing demand for cloud-hosted learning platforms created pull for DevOps tooling among EdTech providers.
• Others – Healthcare, government, and manufacturing adoption was growing from a lower baseline.

Regional Market Breakdown

The 2019 research covered the following key regions and highlighted India specifically as a significant growth market within Asia-Pacific:

• North America (led by the United States) – The most mature and largest revenue-generating region, home to most major platform vendors and enterprise early adopters.
• Europe (Germany, France, United Kingdom) – Strong growth driven by digital transformation mandates, GDPR compliance automation needs, and a robust banking sector.
• Asia-Pacific (China, Japan, India) – The fastest-growing region overall. India in particular was highlighted as a significant market due to its large IT services sector, high developer workforce growth, and rapidly expanding domestic technology industry.
• Latin America (Brazil) – Emerging adoption driven by fintech growth and cloud infrastructure expansion.
• Middle East & Africa – Nascent but growing, with government-led digital transformation programs in the Gulf states leading demand.

Why India Was a Notable DevOps Market in 2019

India’s inclusion as a named market alongside established regions reflected several structural advantages: a large English-speaking developer population, a mature IT outsourcing industry already familiar with tooling standardization, and rapid growth in domestic SaaS and fintech companies needing modern delivery pipelines. Indian IT services firms were also under pressure from global clients to demonstrate DevOps capability as a delivery differentiator, creating both internal adoption and consulting revenue streams.

Key Analytical Frameworks Used in the Report

Market reports of this type typically apply several standard analytical frameworks that engineering and strategy teams should understand when consuming the findings:

• SWOT Analysis – Strengths, Weaknesses, Opportunities, and Threats assessed per major vendor and per region.
• CAGR Projections – Compound Annual Growth Rate estimates provide a single-number proxy for how fast a segment is expected to grow over the forecast period. These should be treated as directional, not precise.
• Upstream/Downstream Value Chain Analysis – Examines supplier dependencies (cloud infrastructure, open-source communities) and buyer relationships (enterprise IT buyers, system integrators).
• Competitive Landscape Mapping – Positions vendors by market share, product breadth, and geographic reach.

How to Use Market Research as a DevOps Practitioner

Vendor landscape reports like this one are most useful for practitioners in three scenarios:

• Toolchain evaluation – Understanding which vendors are established players versus emerging challengers helps prioritize evaluation shortlists.
• Budget justification – CAGR and market size figures can support internal business cases for DevOps investment by demonstrating that the practice is mainstream, not experimental.
• Competitive intelligence – If you work for a tooling vendor, understanding competitor positioning and regional demand patterns informs product and go-to-market strategy.

Treat any specific revenue figures or growth rate projections from third-party market research with appropriate skepticism. Methodology, definitions, and survey populations vary significantly across research firms, and projections made in 2019 should be validated against actual market outcomes before being cited in current strategic documents.

Summary

The 2019 global DevOps platform market represented a diverse, competitive ecosystem spanning infrastructure automation, CI/CD, container management, and application lifecycle tooling. North America led in maturity and revenue, while Asia-Pacific—and India specifically—was identified as a high-growth region. The vendor landscape included both specialist tools (Puppet, Chef, Ansible, SaltStack) and broad platform players (Microsoft, IBM, Red Hat). Organizations evaluating DevOps platforms in this period needed to align vendor selection to their own maturity tier and vertical-specific compliance requirements rather than defaulting to the largest or most-marketed option.

Red Hat Inc., has announced Red Hat OpenShift 4.2, the latest version of Red Hat’s trusted enterprise Kubernetes platform designed to deliver a more powerful developer experience. Red Hat OpenShift 4.2 extends Red Hat’s commitment to simplifying and automating enterprise-grade services across the hybrid cloud while empowering developers to innovate and enhance business value through cloud-native applications.

Red Hat OpenShift 4.2 aims to make cloud-native technologies easier to use and more accessible for developers via capabilities that automate the set-up and management of Kubernetes environments. This enables developers to focus on building the next-generation of enterprise applications without requiring deep Kubernetes expertise.

The latest version of OpenShift also adds ready-to-use developer services that address needs around service mesh, serverless execution and cloud-native continuous integration/continuous delivery (CI/CD) pipelines, all of which are designed to help fuel developer productivity around Kubernetes-based applications:

·  Red Hat OpenShift Service Mesh, based on the Istio, Kiali, and Jaeger projects and enhanced via Kubernetes Operators, is designed to simplify the development, deployment, and management of microservices-based applications on OpenShift. 

·  Red Hat OpenShift Serverless, based on Knative and available as a Technology Preview, helps to lower costs by running applications that can scale down to zero while remaining responsive to user requests and then scaling up on-demand. 

·  Red Hat OpenShift Pipelines, in Developer Preview and available as a Kubernetes Operator, runs each step of the CI/CD pipeline in its container, allowing each step to scale independently to meet changing demands.

This release brings OpenShift closer to developers with Red Hat CodeReady Containers, which enables developers to install a pre-built OpenShift environment on a laptop for local development. This provides a framework that ties together container development tools with a local cluster, making it easier to build cloud-native applications locally and, when ready, deploy to a full OpenShift environment.

Cloud simplicity, wherever OpenShift runs

Enterprise IT has never been a homogenous, static series of deployments, and modern computing is not an exception. Hybrid deployments using components of on-premise infrastructure and cloud-based services are frequently being pursued by IT decision-makers and, to help ease the transition to the hybrid cloud, Red Hat OpenShift 4.2 is designed to deliver a more consistent, unified experience across disparate IT estates, adding:

·  Simplified, automated and faster installations of OpenShift Container Platform across public clouds, including AWS, Azure and Google Cloud Platform (GCP), and private clouds like OpenStack, backed by a consistent enterprise experience.

·  Migration tooling to help customers upgrade from OpenShift 3 to 4, offering a simpler, faster and more automated way to copy workloads from one OpenShift cluster to another. 

·  Container Storage Interface (CSI) drivers that provide a more consistent way for third party storage providers to plug into the Kubernetes ecosystem. This release also supports OpenShift Container Storage 4, currently in beta.

The industry’s most comprehensive enterprise Kubernetes platform

As organizations look to use enterprise Kubernetes to drive digital transformation, roadblocks can appear due to stringent internal and regulatory security standards. These requirements often limit the connectivity of sensitive data and workloads, requiring “air gaps” or being disconnected from the broader enterprise network. While good for security, it makes migrating and updating the applications and services used by these systems a challenging, manual process with dozens of steps. 

To help improve the OpenShift experience across heterogeneous deployments and systems, including those that handle sensitive information, Red Hat OpenShift 4.2 adds installer enhancements across environments, including support for disconnected installs. This enables customers to more easily deploy the latest version of the industry’s most comprehensive enterprise Kubernetes platform in environments that are not accessible via the Internet or those that are connected but maintain strict image testing policies.

Red Hat OpenShift 4.2 will be available in the coming weeks.

Supporting Quotes

“More and more organizations across industries and around the world trust Red Hat OpenShift to run their most critical business applications. We continue to prioritize making the next generation of enterprise open source technologies like Kubernetes even more accessible to developers while also keeping administrator priorities in balance. With these goals in mind, OpenShift 4.2 delivers on features to help customers accelerate application development and delivery,” said Ashesh Badani, senior vice president, Cloud Platforms, Red Hat.

“As Kubernetes-based container platforms for microservices evolve, new end-to-end toolchains are needed that can deliver code quickly and with fewer errors. The latest suite of OpenShift developer tools, especially OpenShift Pipelines, enables end-to-end CI/CD that automates code delivery to Kubernetes container platforms,” said Tom Petrocelli, research fellow, Amalgam Insights.

“At Google Cloud, we are committed to providing customers with the flexibility to deploy all types of enterprise workloads on GCP. Google and Red Hat share a long-standing collaboration across Kubernetes, support for the open-source community, and a mutual belief that open standards and open innovation are good for customers. We look forward to helping OpenShift customers leverage the power of Google Cloud through this partnership,” said Rayn Veerubhotla, director, partnerships at Google Cloud.

“We are excited to see the 4.2 release bringing new tooling and local development experiences to OpenShift users. Azure offers a range of OpenShift solutions including Azure Red Hat OpenShift, a fully managed OpenShift service jointly operated by Red Hat and Microsoft. With Red Hat OpenShift Container Platform 4 now generally available on Azure, enterprises can create hybrid cloud environments that can meet their current needs and also evolve to handle future requirements,” said Gabe Monroy, director of program management for the Azure Application Platform, Microsoft.

“As a company transitioning to containers and Kubernetes, we wanted to work with Red Hat given their deep expertise in Kubernetes for enterprises. In adopting Red Hat OpenShift 4, we can focus on our business of IT cybersecurity — our developers get to focus on code, while administrators can work with a trusted platform that can be easier to manage thanks to automated updates,” said Sean Muller, enterprise architect & technology leader, LiquidIT.

“We use Red Hat OpenShift as our Kubernetes solution, running a number of our critical systems in our private cloud environment. Using the automation in Red Hat OpenShift, we can continually deliver better functionality for our customers from our teams with short time-to-market and low risk,” said Alv Skjellet, head of IT platforms, Norsk Tipping.

“With our focus on the commercial transportation industry, we have been working with Red Hat given their expertise in cloud-native technology to power our fleet management solutions for transportation and logistics companies. Red Hat OpenShift 4 is already helping us to unify our work on this trusted enterprise Kubernetes platform across our hybrid cloud environment. Each cluster can be deployed using a single command. Kubernetes Operators help to enable “one-click” upgrades and lifecycle management. Operators provide automation for our application teams to move easily to an as-a-service model. We look forward to maximizing our use of the tools that are especially powerful for our developers so they can focus on innovations on our applications,” said Justin Newcom, vice president of Global Information Technology, Omnitracs.