PLEASANTON, Calif., June 7, 2021 /PRNewswire/ — SpringML, Inc. (“SpringML”), a leader in machine learning and advanced data analytics services, is proud to announce that it has achieved the Security Specialization in Google Cloud Partner Advantage. By earning the Partner Specialization, SpringML has proven their expertise and success in building customer solutions in the Security field using Google Cloud technology.

Partners with this specialization have demonstrated significant success securing customer infrastructure and workflows to Google Cloud. Areas of expertise for SpringML include data encryption management, identifying and masking confidential data, role based access control and network security access to data for internal and external users – all critical components to help lay a secure foundation for data driven transformation.

“We’re pleased that SpringML has achieved the Security Specialization in the Google Cloud Partner Advantage Program,” said Nina Harding, Chief of Global Partner Programs & Strategy at Google Cloud. “Acquiring this specialization is evidence of SpringML’s expertise in building security infrastructure solutions and their continued commitment to helping our customers throughout their digital transformations.”

“SpringML is an agent of change to help enterprises rapidly deploy data-driven digital transformation projects,” said Girish Reddy, CTO of SpringML. “Using Google Cloud tools, we can ensure that security and privacy compliance are maintained at the highest levels throughout a project implementation.”

As enterprises look for new ways to engage with customers, providing creative digital experiences is key. SpringML’s portfolio showcases its ability to deliver data-driven digital transformation projects having built applications for enterprises with an agile, iterative, and incremental delivery model.

Spring ML, Inc.

SpringML delivers data-driven digital transformation outcomes with an experimentation and design thinking mindset. We provide consulting and implementation services and industry-specific analytics solutions that deliver high-impact business value from data. SpringML is a premier Google Cloud partner with capabilities to plan, assess, deploy, and manage data-driven engagements. We have been awarded Google Cloud specializations based on our expertise and customer portfolio for Security, Data Management, Application Development, Data Analytics, Machine Learning, and Marketing Analytics.

Veeam Puts Kubernetes and Cloud-Native Backup in the Spotlight

Data protection and management vendor Veeam used its VeeamON 2020 virtual conference—held June 17–18, 2020, as an online event due to the COVID-19 pandemic—to lay out its strategy for Kubernetes container backup and cloud-native data protection on Amazon Web Services (AWS) and Microsoft Azure.

The announcements came at a time when enterprise adoption of containers was accelerating and customers were beginning to ask hard questions about how to protect workloads running in Kubernetes environments—a gap that only a handful of vendors had seriously addressed.

The Kasten Partnership and the Kubernetes Opportunity

In the weeks before VeeamON 2020, Veeam announced a partnership with Kasten, a Kubernetes-native backup specialist headquartered in Los Altos, California. The partnership signalled Veeam’s intent to move beyond traditional VM and file-based workloads and tackle stateful containerised applications.

Channel partners took notice. Manny Punzo, Director of Data Protection and Management at Technologent—an Irvine, California-based solution provider and Veeam channel partner—described the wider market context:

“There are only a handful of niche data protection players talking Kubernetes. Not many of the major players are really talking about it except for maybe Dell Technologies and Commvault. I’ll be looking to see what Veeam does. Customers are now talking about containers and how to protect container data.”

Manny Punzo, Director of Data Protection and Management, Technologent

Punzo also wanted clarity on differentiation: “There’s so much competition in this industry. Backup is backup. Disaster recovery is disaster recovery. I’m looking to see how Veeam differentiates itself.”

Veeam Availability Suite v10 and Cloud-Native Capabilities

A central theme at the conference was Veeam Availability Suite v10, released in February 2020. Highlights of the release relevant to cloud-native workloads included:

• Native backup support for cloud-native applications running on AWS and Microsoft Azure
• Backup coverage for Microsoft 365 data
• A roadmap preview covering additional capabilities planned for the second half of 2020 and beyond

Danny Allan, Veeam’s Chief Technology Officer, described the company’s broader data management vision as resting on five core pillars:

1. Data protection — backup, recovery, and replication
2. Cloud mobility — moving workloads across on-premises and cloud environments
3. Data visibility and monitoring — insight into data assets and backup health
4. Orchestration — automating recovery workflows end-to-end
5. Governance and compliance — meeting regulatory and audit requirements

“All five will be highlighted at the conference. We already have capabilities in all five. But we will also be highlighting additional capabilities that were both introduced in the first half of 2020 and will be introduced in the second half of 2020 and into the future.”

Danny Allan, CTO, Veeam

2020 Data Protection Report: Key Findings

VeeamON 2020 also served as the launch platform for Veeam’s annual data protection report. Jim Kruger, Veeam’s Chief Marketing Officer, shared headline statistics from a survey of 1,500 global enterprise executives (approximately 5% of whom were existing Veeam customers at the time):

• 49% of respondents were already backing up data to public cloud or backup-as-a-service (BaaS) providers at the time of the survey.
• 77% expected to use cloud or BaaS backup within the next two years—split between 34% planning self-managed cloud backups and 43% planning to use managed BaaS offerings.
• The average cost of unplanned downtime was reported at US$68,000 per hour for enterprise organisations.
• Cyberthreats, including ransomware, were cited as the number one data protection challenge facing enterprises.

Conference Scale and Channel Participation

By the opening of the event, VeeamON 2020 had attracted more than 23,000 registered attendees, including approximately 12,000 strategic channel partners and members of the Veeam Cloud and Service Provider (VCSP) programme. The shift to a virtual format following the cancellation of in-person tech events appears to have broadened participation significantly compared with previous years.

Strategic Context: Insight Partners Acquisition and U.S. Headquarters Move

Punzo’s comments about differentiation also touched on a significant corporate development: earlier in 2020, private equity firm Insight Partners acquired Veeam, and the company subsequently relocated its global headquarters from Baar, Switzerland to the United States. The move was widely interpreted as positioning Veeam to deepen relationships with major U.S.-based public cloud hyperscalers and to compete more aggressively in the North American enterprise market.

Why This Matters for DevOps and Platform Teams

For DevOps engineers and platform architects, the key takeaways from Veeam’s VeeamON 2020 announcements are practical:

• Kubernetes backup is no longer optional. As stateful workloads—databases, message queues, persistent volumes—move into Kubernetes, protecting them requires purpose-built tooling. Generic VM backup tools do not understand Kubernetes resource definitions, namespaces, or persistent volume claims.
• Cloud-native backup differs from cloud-hosted backup. Backing up a VM that runs in AWS is different from protecting a cloud-native application composed of managed services (RDS, DynamoDB, S3, Lambda). Veeam was signalling awareness of this distinction.
• Ransomware is a backup architecture concern. The survey finding on cyberthreats reinforces the need for immutable backup targets, air-gapped copies, and tested recovery runbooks—not just scheduled backup jobs.
• BaaS adoption is accelerating. The projected jump from 49% to 77% cloud/BaaS backup adoption in two years reflects the operational overhead of managing on-premises backup infrastructure and the appeal of consumption-based models.

Rubrik’s Case for Unifying Data Management and DevOps

At its FORWARD Digital Summit event, Rubrik made a public case for converging data management and DevOps practices. While the company is best known as a data protection vendor, president Dan Rogers positioned Rubrik as a broader data management platform provider — one whose API-first architecture could soon make it a first-class tool for DevOps teams, not just IT operations.

New Cloud Coverage: GCP, Amazon RDS, and OneDrive

Rubrik announced several platform expansions to its Polaris Data Management Platform, delivered as a SaaS offering:

• Google Cloud Platform (GCP): Polaris can now protect workloads running on virtual machines in GCP, adding to existing support for Amazon Web Services (AWS) and Microsoft Azure.
• Amazon Relational Database Service (Amazon RDS): AWS data protection support was extended to cover managed relational databases running on RDS.
• Microsoft OneDrive: Cloud file storage on OneDrive is now covered, complementing the existing Microsoft Office 365 integration.

These additions bring Rubrik closer to comprehensive multi-cloud data protection across the three dominant cloud providers and their managed services.

Polaris as an API-First Platform for DevOps

The more strategically significant announcement at the summit was Rubrik’s articulation of how Polaris fits into DevOps workflows. According to Rogers, Polaris is built from the ground up using REST APIs and rich metadata, making it programmatically accessible — a key requirement for DevOps-style automation.

Today, most Polaris users are IT operations teams accessing it through a graphical user interface (GUI). That GUI-driven approach allows the platform to serve traditional IT operations while also being accessible to DevOps teams who want to automate data access and protection through code. Rogers suggested it is only a matter of time before DevOps teams start invoking Polaris APIs directly to access the large volumes of data their applications depend on.

Data Protection as a DevOps Enabler

Rogers highlighted two specific ways data protection platforms already support application development cycles:

• Development and testing environments: Developers need rapid recovery capabilities when an application crashes mid-development. A robust backup and restore platform reduces the cost of failure during iterative development cycles.
• Cloud migration: IT teams are actively using data protection and backup tooling to migrate datasets from on-premises environments into the cloud — a use case that aligns naturally with DevOps-driven modernization initiatives.

Beyond Backup: Data Governance, Compliance, and Metadata

Rubrik’s broader platform strategy extends beyond backup and recovery into adjacent data management capabilities, including:

• Data governance and compliance tooling
• Metadata management
• SaaS delivery of traditionally on-premises data management functions

Rubrik is not alone in this space; other vendors also deliver data management capabilities as SaaS. However, Rubrik’s pitch is a phased replacement of on-premises data protection with a cloud-native alternative that gradually adds higher-order management capabilities.

COVID-19 as an Accelerant for SaaS Adoption

Rogers also addressed the impact of the COVID-19 pandemic on IT platform decisions. With IT operations teams working remotely for an extended — and in some cases potentially permanent — period, organizations are accelerating their shift toward cloud-delivered management platforms that can be accessed from anywhere without requiring physical presence in a data center.

This trend benefits SaaS-delivered platforms like Polaris directly. The pandemic effectively compressed a multi-year adoption timeline into months, as organizations that had deferred cloud migrations were pushed to act by the operational realities of distributed teams.

Key Takeaways for DevOps and Platform Engineers

• Rubrik’s Polaris platform now covers all three major clouds (AWS, Azure, GCP) for VM workload protection.
• Amazon RDS and Microsoft OneDrive are newly supported data sources.
• The REST API-first architecture of Polaris positions it as an automation target for DevOps pipelines — though widespread DevOps adoption of data management APIs remains nascent.
• Data protection platforms increasingly serve dual roles: operational resilience for IT teams, and data access infrastructure for development and testing workflows.
• Remote work pressures are accelerating SaaS platform adoption across IT operations broadly.

Below is a breakdown of the core competencies you should develop to become a competitive candidate in cloud computing roles.

1. Cloud Platform Proficiency

No cloud computing career starts without hands-on familiarity with at least one major cloud platform. The three dominant providers are:

• Amazon Web Services (AWS) – the market share leader, with a broad and mature service catalogue covering compute, storage, databases, machine learning, networking, and more.
• Microsoft Azure – a strong choice for organisations with existing Microsoft infrastructure; tightly integrated with Active Directory and enterprise tooling.
• Google Cloud Platform (GCP) – increasingly popular for data analytics and machine learning workloads.

Understanding a single platform deeply is more valuable early in your career than a shallow knowledge of all three. Most cloud providers offer free-tier accounts that let you experiment without cost. Study the core services—compute instances, managed databases, object storage, identity and access management (IAM), and networking primitives—before expanding to specialised services.

Vendor certifications (AWS Certified Solutions Architect, Microsoft Azure Administrator, Google Associate Cloud Engineer) are widely recognised by hiring managers and provide a structured learning path.

2. Cloud Storage Concepts

Data is central to everything that runs on the cloud, so understanding how it is stored, retrieved, and protected is fundamental. Cloud storage falls into several broad categories:

• Object storage – suited for unstructured data such as images, videos, and backups (e.g., Amazon S3, Azure Blob Storage, Google Cloud Storage).
• Block storage – low-latency storage attached to compute instances, similar to a traditional hard drive (e.g., Amazon EBS, Azure Managed Disks).
• File storage – shared file systems accessible by multiple instances simultaneously (e.g., Amazon EFS, Azure Files).
• Public, private, and hybrid cloud storage – architectural decisions about where data lives and who controls it.

Understanding storage tiers (hot, cool, archive), replication strategies, and cost trade-offs will make you a more effective designer of cloud architectures and help you advise organisations on data placement decisions.

3. Networking Fundamentals

Cloud environments are fundamentally networked environments. Whether you are configuring a Virtual Private Cloud (VPC), setting up load balancers, or designing hybrid connectivity between an on-premise data centre and a cloud region, networking knowledge is non-negotiable.

Key networking concepts every cloud professional should understand include:

• IP addressing, subnetting, and CIDR notation
• DNS resolution and how it behaves in cloud environments
• Virtual networks, subnets, route tables, and security groups
• Load balancing (Layer 4 vs. Layer 7)
• VPN gateways and dedicated interconnect options (e.g., AWS Direct Connect, Azure ExpressRoute)
• Content delivery networks (CDNs) and edge caching

Cloud engineers are often responsible for designing networks that automatically adjust to demand—using auto-scaling groups, traffic policies, and health checks—so a solid networking foundation is essential even if you are not a dedicated network engineer.

4. Cloud Security

Security is not optional in cloud computing—it is a shared responsibility between the cloud provider and the customer. The provider secures the underlying infrastructure; you are responsible for securing what you build on top of it. Misunderstanding this model has been the root cause of many high-profile data breaches.

Skills to build in cloud security include:

• Identity and Access Management (IAM) – least-privilege policies, roles, and service accounts
• Encryption – data at rest and in transit, key management services
• Compliance frameworks – understanding SOC 2, ISO 27001, GDPR, and how cloud services support compliance
• Security monitoring – cloud-native tools such as AWS GuardDuty, Azure Security Center, and Google Security Command Center
• Network security – firewalls, security groups, web application firewalls (WAF)

The Certified Cloud Security Professional (CCSP) credential, offered by (ISC)², is a well-regarded certification for professionals who want to specialise in cloud security. It covers architecture, governance, risk, compliance, and operations across cloud environments.

5. Data Management and Databases

Organisations move to the cloud partly because it makes managing large volumes of data easier and cheaper. As a cloud professional, you will frequently work with managed database services, data pipelines, and analytics platforms.

Skills to develop include:

• SQL – querying relational databases remains a baseline skill regardless of your role
• NoSQL databases – document stores (MongoDB, DynamoDB), key-value stores, and wide-column databases are common in cloud-native applications
• Big data processing – tools like Apache Hadoop and Apache Spark are used for large-scale batch processing; managed equivalents exist on every major cloud platform
• Data warehousing – services like Amazon Redshift, Google BigQuery, and Azure Synapse Analytics are central to analytics workloads
• Data lifecycle management – understanding retention policies, archiving, and deletion is important for both cost control and compliance

6. Serverless Architecture

Serverless computing lets developers run code without provisioning or managing servers. The cloud provider dynamically allocates compute resources and charges only for actual execution time. This model can significantly reduce operational overhead and infrastructure costs for appropriate workloads.

Popular serverless platforms include:

• AWS Lambda – the most widely adopted Function-as-a-Service (FaaS) platform
• Azure Functions – Microsoft’s equivalent, with deep integration into Azure services
• Google Cloud Functions / Cloud Run – event-driven functions and containerised serverless workloads

To work effectively with serverless architectures, you should understand event-driven programming models, API gateways, function cold starts and their performance implications, and how to connect serverless functions to other cloud services such as queues, databases, and storage buckets.

AWS provides official Lambda documentation and tutorials. Third-party resources such as the Serverless Framework and courses on platforms like A Cloud Guru, Linux Foundation, and Coursera also offer structured learning paths.

Additional Skills Worth Developing

The skills above form a solid foundation, but the cloud computing field is broad. Depending on the role you are targeting, you may also want to build expertise in:

• Infrastructure as Code (IaC) – Terraform, AWS CloudFormation, or Azure Bicep for repeatable, version-controlled infrastructure
• Containers and orchestration – Docker and Kubernetes are now standard components of cloud-native deployments
• CI/CD pipelines – automating build, test, and deployment processes using tools like GitHub Actions, GitLab CI, or AWS CodePipeline
• Monitoring and observability – logging, metrics, and tracing with tools such as CloudWatch, Prometheus, Grafana, or Datadog
• Scripting and automation – Python, Bash, or PowerShell for automating routine cloud operations tasks

Getting Started

The best approach for breaking into cloud computing is a combination of structured study and hands-on practice. Create free-tier accounts on AWS, Azure, or GCP and build real projects—even simple ones like a static website hosted on object storage or a serverless API—to develop genuine experience. Pair this with a recognised certification to signal your knowledge to employers.

Cloud computing is not a single job description. Roles range from cloud infrastructure engineer and cloud security specialist to data engineer and site reliability engineer (SRE). Identifying which area aligns with your existing background and interests will help you focus your learning more effectively.

What Is NetApp Project Astra?

In April 2020, NetApp announced Project Astra, a vision for a software-defined platform being developed in collaboration with the Kubernetes community. The goal: deliver enterprise-class storage and data services for stateful, cloud-native applications running on any Kubernetes distribution, on any cloud.

At the time of announcement, Project Astra was still in active development. NetApp positioned it as the next major evolution of its Kubernetes data management capabilities, building on existing products such as NetApp Trident (the open-source dynamic storage provisioner for Kubernetes) and NetApp Kubernetes Services.

The Problem Project Astra Was Designed to Solve

Kubernetes adoption accelerated rapidly in enterprise environments in the late 2010s, but stateful workloads—applications that depend on persistent data—exposed a significant gap in the ecosystem. While Kubernetes excels at making stateless applications portable and resilient, data portability for stateful applications remained difficult to achieve reliably.

IT teams and site reliability engineers (SREs) were expected to meet enterprise-grade standards for data governance, protection, and replication—but without a unified, Kubernetes-native toolset to do so. Specifically, the challenges included:

• Lack of reliable data services: Many organizations running Kubernetes lacked robust, enterprise-class storage services tightly integrated with their workloads.
• Limited data portability: Application containers could move freely across environments, but their associated persistent data often could not.
• Operational complexity: Managing storage and data protection across hybrid and multi-cloud Kubernetes deployments required disparate tools and significant manual effort.
• Stateful application support: Data-rich, stateful applications were treated as second-class citizens compared to stateless microservices in most Kubernetes frameworks.

Project Astra’s Core Capabilities

NetApp described Project Astra as a platform that would allow teams to:

• Discover applications running on any Kubernetes distribution, whether on-premises or in public cloud environments.
• Integrate and unify application and data management into a single, consistent workflow.
• Deliver data services as built-in capabilities, surfacing NetApp’s expertise in storage management directly within Kubernetes-native tooling.
• Extend true portability to stateful, data-rich workloads—not just stateless containers.

The platform was designed to leverage NetApp’s public cloud partnerships and augment them with Kubernetes-native data service integrations, meaning storage and data operations would be tightly coupled with the application lifecycle rather than managed as a separate infrastructure concern.

Architecture Approach: Software-Defined and Distribution-Agnostic

A key architectural principle behind Project Astra was distribution agnosticism. Rather than tying data services to a specific Kubernetes flavor, NetApp aimed to build a software-defined layer that could plug into any Kubernetes distribution and management environment.

Anthony Lye, then Senior Vice President and General Manager of NetApp’s Cloud Data Services business unit, stated at the time:

“Project Astra represents the next major step in the evolution of storage and data services for Kubernetes. We are making a decisive and long-term commitment to addressing the data challenges of Kubernetes, together with the communities and platforms that use it. Project Astra will provide a software-defined architecture and set of tools that can plug into any Kubernetes distribution and management environment.”

Anthony Lye, SVP and GM, NetApp Cloud Data Services

Community Collaboration and NetApp’s Kubernetes Lineage

NetApp emphasized that Project Astra was being built with the Kubernetes community, not just for it. The project was intended to benefit Kubernetes developers and operations managers who needed better data management tooling as a natural extension of their existing workflows.

Eric Han, Vice President of Product Management for NetApp’s Cloud Data Services business unit, brought notable credentials to the initiative, having served as an early product manager for Kubernetes at Google. He commented:

“In a few short years, Kubernetes has become the de facto choice in orchestrating container environments. Yet there is still potential, and a need, to further evolve. With Project Astra, NetApp is delivering on the true promise of portability that professionals working with Kubernetes require today and is working in parallel with the community and our customers to make all data managed, protected, and portable, wherever it exists.”

Eric Han, VP Product Management, NetApp Cloud Data Services

Foundation: NetApp Trident and NetApp Kubernetes Services

Project Astra was not a greenfield effort. It was explicitly built on NetApp’s existing Kubernetes data management foundation:

• NetApp Trident: An open-source, dynamic storage provisioner for Kubernetes that automates the creation and management of persistent volumes backed by NetApp storage systems. Trident supports the Container Storage Interface (CSI) standard and had already enabled customers to manage large volumes of container data before Project Astra was announced.
• NetApp Kubernetes Services (NKS): A managed Kubernetes service that provided a unified control plane for deploying and managing Kubernetes clusters across multiple cloud providers.

Project Astra was positioned as the logical next layer—adding application-aware data management, protection, and portability on top of the storage provisioning capabilities Trident already provided.

Why This Announcement Mattered for DevOps Teams

For DevOps engineers and platform teams in 2020, Project Astra addressed a real and growing pain point. As Kubernetes usage expanded beyond stateless microservices into databases, message queues, and other stateful workloads, the lack of enterprise-grade, Kubernetes-native data management tooling was a meaningful operational risk.

Key implications for practitioners included:

• Simplified disaster recovery: Application-integrated data management means backup, restore, and replication policies can be defined alongside workload manifests rather than as separate infrastructure-level configurations.
• Multi-cloud portability: A distribution-agnostic platform reduces lock-in risk and makes it easier to migrate stateful workloads between cloud providers or between on-premises and cloud environments.
• Developer self-service: Surfacing data services as Kubernetes-native capabilities opens the door to self-service data management for application teams, reducing the operational burden on centralized storage teams.
• Compliance and governance: Enterprise-class data services include audit trails, access controls, and policy enforcement—capabilities that are difficult to bolt on after the fact in most Kubernetes environments.

Project Astra’s Evolution: Astra Data Store and Astra Control

Following the initial announcement, NetApp continued to develop the Project Astra vision. The project eventually materialized as the NetApp Astra portfolio, which included products such as Astra Control (for application-aware data management and protection) and Astra Trident (the rebranded evolution of NetApp Trident). Teams evaluating NetApp’s Kubernetes data management solutions should refer to current NetApp documentation for the latest product names, features, and availability, as the portfolio has continued to evolve after this original 2020 announcement.

Summary

Project Astra represented NetApp’s strategic commitment to solving one of the most persistent challenges in enterprise Kubernetes adoption: making stateful application data as portable, protected, and manageable as the applications themselves. By building a software-defined, distribution-agnostic platform in close collaboration with the Kubernetes community, NetApp aimed to bridge the gap between the rapid growth of container adoption and the enterprise-grade data management capabilities that production workloads require.

What the Report Covers

The Global EMEA Container Technology Market report, released in early 2020, provides a structured analysis of the container technology sector across Europe, the Middle East, Africa, and adjacent global regions. The study draws on primary and secondary research sources, expert interviews, data triangulation, and historical data to profile market size (in USD million), volume, revenue, and growth rates for the period 2020 to 2029.

The report is aimed at strategic planners, investors, and technology leaders who need a structured view of where container adoption is heading, who the dominant vendors are, and which application categories are driving spend.

Key Vendors Profiled

The report includes competitive profiles of the following organisations active in the container technology space:

• Apcera – container policy and orchestration platform
• Amazon Web Services (AWS) – Amazon ECS, EKS, and Fargate
• Chef – infrastructure automation, including container workflows
• Cisco – enterprise networking and container security integrations
• Cloud Foundry – open-source platform-as-a-service with container support
• ClusterHQ – container data management (note: ceased operations in 2016)
• CoreOS – container-optimised Linux and rkt runtime (acquired by Red Hat in 2018)
• Docker – the dominant container runtime and toolchain
• EMC – storage and data management for containerised workloads
• HashiCorp – Nomad, Vault, Consul for container scheduling and secrets management
• Joyent – SmartOS-based container infrastructure
• Mesosphere (now D2iQ) – DC/OS and Kubernetes enterprise platform
• Microsoft – Azure Kubernetes Service (AKS) and Windows container support
• OpenStack – open-source cloud infrastructure with Magnum container service
• Rackspace – managed cloud and container hosting services

Market Segments by Container Runtime Type

The report categorises the market by the underlying container runtime technology:

• Docker – the most widely deployed container runtime, using the OCI-compatible containerd engine
• rkt (Rocket) – CoreOS’s pod-native container engine, now archived
• LXC and LXD – Linux system containers providing a lightweight VM-like experience
• containerd – the CNCF-graduated container runtime now embedded in Docker and Kubernetes
• FreeBSD Jails – OS-level virtualisation predating Linux containers
• Others – including gVisor, Kata Containers, and proprietary runtimes

Market Segments by Application Area

On the application side, the report breaks spend and adoption into five functional categories:

• Container Monitoring – observability tooling for resource usage, health checks, and alerting across container fleets
• Container Provisioning – orchestration, scheduling, and lifecycle management (e.g., Kubernetes, Nomad)
• Container Security – image scanning, runtime policy enforcement, and secrets management
• Container Data Management – persistent storage, volume management, and backup for stateful containerised workloads
• Container Networking – CNI plugins, service meshes, ingress controllers, and network policy enforcement

Regional Breakdown

Despite the “EMEA” label, the report covers all major global regions:

Key Questions the Report Addresses

For DevOps teams and engineering leaders evaluating container strategy, the research is structured around questions such as:

1. What are the primary growth drivers, opportunities, and risks in the container technology market?
2. Which consumer or enterprise segment drove the highest container technology sales in 2020?
3. What business risks and regulatory factors affect market growth?
4. Which application categories (monitoring, security, networking, etc.) show the highest growth potential?
5. Which geographic region presents the most immediate commercial opportunity?
6. Which container runtime types are seeing the greatest enterprise adoption?
7. What are the primary challenges — skills gaps, security concerns, storage complexity — facing adopters?

Report Structure

The full report table of contents includes the following sections:

• Market Overview and Size Estimation
• Manufacturer and Vendor Profiles
• Competitive Landscape by Key Company
• Regional Analysis (Global, EMEA, North America, Asia-Pacific)
• Country-Level Breakdowns for South America, Middle East, and Africa
• Market Segmentation by Runtime Type
• Market Segmentation by Application Category
• Market Forecast: 2020–2029
• Research Conclusions and Recommendations

Context for DevOps Practitioners

Market research reports like this one are most useful to practitioners when mapped against real technology decisions. A few contextual notes worth keeping in mind when interpreting a 2020-vintage container market study:

• Kubernetes has become the de facto orchestrator. By 2020, Kubernetes had consolidated its position as the dominant container orchestration platform, making orchestration choice less of a market differentiator and shifting competition to the management, security, and developer experience layers.
• Some listed vendors no longer exist in their original form. ClusterHQ ceased operations in 2016; CoreOS was acquired by Red Hat (now IBM) in 2018; Apcera was acquired by Ericsson and later wound down. Treat vendor lists in older reports with caution.
• Container security became a top-tier concern. The period 2020–2024 saw significant growth in image scanning tools, supply-chain security standards (SLSA, SBOM), and runtime security products — trends that a 2020 forecast may have underweighted.
• Serverless containers grew substantially. AWS Fargate, Google Cloud Run, and Azure Container Apps changed the provisioning segment significantly after this report was written.

Source: janmorganmedia.com / Wired Release, January 8, 2020. Original report covers the global EMEA Container Technology market for the period 2020–2029.

The Core Problem: Test Data Instability Breaks DevOps Pipelines

Having access to stable, predictable test data is widely regarded as the single biggest challenge to effective test automation in most organizations. In a DevOps context—where fast feedback loops and continuous delivery are non-negotiable—the cost of poor test data management is amplified significantly. Flaky tests caused by bad data slow pipelines, erode team trust in automation, and ultimately undermine the entire DevOps practice.

Too many organizations are struggling with test automation—and by extension, with DevOps—because they have not established clear processes for managing test data. This problem is especially acute for teams implementing DevOps against legacy or monolithic systems, where data is often tightly coupled and difficult to control.

The relationship is straightforward: you cannot succeed in DevOps without effective test automation, and you cannot have effective test automation without properly managed test data.

Understanding the Test Data Challenges in DevOps

To succeed in DevOps, your pipeline needs a reliable set of automated tests that confirm a given build is ready to advance to the next stage. Reliability depends on tests having access to a consistent, predictable dataset. Here are the two most common failure modes teams encounter:

1. Keeping Tests and Data in Sync

When test inputs or expected outputs no longer match the current state of the system under test (SUT), automated tests produce frequent false positives. Teams then waste significant time triaging failures that are caused by stale data rather than genuine defects. Common causes include:

• Data modified by other activity in a shared test environment
• Data that has an expiration date (e.g., user credentials, insurance policies) changing between test runs
• Application schema changes that render existing test records invalid

2. Insufficient Data for Complex Integration Testing

Integration tests often require data to exist in specific states across multiple system components or third-party services simultaneously. Setting up that data manually across systems is time-consuming and error-prone. When the overhead becomes too high, teams simply skip this testing—leaving large categories of risk unchecked.

Define Your Test Data Requirements First

Before you can manage test data effectively, you need to understand exactly what your automated tests require. For each data element a test depends on, define the following six dimensions:

1. Type

Is the data input supplied by the test itself, or is it existing data that the system is expected to read or act upon? Distinguishing these two types drives very different management approaches.

2. Value

What specific value—or class of values—does the test require? A test might need a specific account number, or any account of a particular type. Documenting this precisely prevents over-constraining tests to a single brittle record.

3. Time

How does the data element change over time? Time-sensitive data (expiring credentials, date-bounded policies, contracts with end dates) is a frequent silent cause of tests that pass consistently for weeks and then suddenly begin failing without any code change.

4. Reuse

Can the same data record be used across multiple test executions, or does each run consume or mutate it? For example, a shared test account can be reused to place orders in an e-commerce system, but the specific order record created by one test run cannot reliably be reused by the next.

5. Volume

How much data is needed? Volume is most critical for load and performance testing—for instance, requiring a pool of user accounts to simulate concurrent sessions. It also matters for functional tests that check inventory thresholds, credit limits, or pagination behavior.

6. Source

Where does the data originate? It might reside in a relational database in a specific environment, arrive through an external data feed, or be generated at runtime. Knowing the source determines how the data can be controlled or substituted.

Test Data Management Techniques

Once you have documented your data requirements across these dimensions, you can select the right management techniques. Because the combination of technologies, team structures, and system architectures varies enormously, no single recipe fits every situation. Instead, treat the following techniques as a toolkit to mix and match.

System/Application-Level Techniques

Data Partitioning

Designate specific data objects—certain accounts, product SKUs, geographic regions, or even an entire warehouse—exclusively for automated test use. When test data is partitioned away from data used by manual testers, developers, or production processes, the risk of unexpected mutation is greatly reduced. Partitioning is a low-cost technique with a high reliability return.

Data Refresh

Copying data from production (or a known-good snapshot) into a test environment is one of the most widely used strategies. However, full or partial refreshes are often too slow for DevOps cadences. A synchronized reset across integrated systems can be complex and error-prone. Where a refresh is feasible, combine it with data partitioning: seed dedicated test records into production before the refresh so they are always available after a restore. This limits the blast radius of refresh delays.

Test Suite-Level Techniques

Pre-Test Data Setup

Have the test suite create or update the data it requires as part of a setup phase before execution begins. This is most effective when you can drive setup through APIs or direct data access rather than through the UI—UI-driven setup is slow and inherits the same reliability risks as UI-level test automation. Combine pre-test setup with data partitioning to keep test-created records isolated from other activity.

Post-Test Data Cleanup

Mirror of pre-test setup: after a test completes, run teardown tasks to reset data (add, modify, or delete records) back to a known baseline. Like setup, this should be done via API or direct data access wherever possible. Consistent cleanup prevents data from accumulating across runs and causing subsequent tests to fail.

On-Demand Data Generation

Build your test framework to recognize data generation tags in test cases instead of hard-coded values. At runtime, the framework generates appropriate data dynamically. This is particularly useful for date-sensitive values—rather than hard-coding a specific date that will eventually expire, a tag like {{TODAY+30}} always produces a valid future date. This eliminates the maintenance burden of refreshing date values before every test run.

Dynamic Data Handling

Similar to on-demand generation, but uses static tags that map to values stored in a central location (a configuration file, a database table, or a secrets manager). When a value changes—such as a rotating API key or a changing threshold—you update it in one place and all tests pick up the new value at runtime, without touching individual test cases.

External Techniques

Test Doubles (Stubs, Mocks, and Service Virtualization)

When it is difficult or impossible to control the data returned by an external dependency, replace that dependency with a test double—a stub, mock, or virtualized service—that returns predictable responses. This technique works best when there is a clean API boundary to intercept. It is harder to apply in legacy or monolithic systems where dependencies are tightly coupled internally.

Test Data Management (TDM) Platforms

Dedicated TDM tools provide capabilities such as data generation, data masking (to protect PII in non-production environments), data sub-setting (producing a representative slice of production data), and automated provisioning. Both commercial and open-source options exist. Their applicability depends heavily on the target technology stack and data storage layer, so evaluate tools against your specific environment before committing.

Avoiding Test Data Technical Debt

Most organizations begin thinking about test data management only after reliability problems force the issue—by which point a significant backlog of test data technical debt has already accumulated. Retrofitting a data strategy onto an established test suite is significantly more expensive than designing it in from the start.

The right time to address test data is before you write the first automated test. At that stage you can identify data requirements, constraints, and dependencies as first-class design concerns rather than afterthoughts.

One useful planning tool is the Test Suite Canvas, a technique originally developed by Katrina Clokie, an engineering manager at the Bank of New Zealand. The canvas helps teams get a holistic view of everything required to build and sustain an automated test suite—including data, environments, tooling, and ownership. Applying it early surfaces test data risks before they become embedded problems.

Key Takeaways

• Stable test data is a prerequisite for reliable test automation, which is itself a prerequisite for effective DevOps delivery.
• Understand your data dimensions (type, value, time, reuse, volume, source) before choosing a management technique.
• No single technique solves every problem. Build a toolkit—data partitioning, pre/post-test setup, on-demand generation, test doubles, and TDM platforms—and apply techniques based on specific test requirements.
• Prefer API-driven data setup and teardown over UI-driven approaches for speed and reliability.
• Plan for test data from day one. Retrofitting a strategy is far more costly than designing it in at the start.
• Use tools like the Test Suite Canvas to make data requirements visible to the whole team during planning.

What Is Fog Computing?

There is an IT architectural concept that combines roots stretching back to the 1800s with some of the most pressing infrastructure challenges of the modern era—and most engineers have never heard of it. It is called Fog Computing, and it has attracted founding consortium members including Dell Technologies, Cisco, Intel, and Microsoft.

In the simplest terms: Fog Computing is an IT systems architectural model that distributes computing, storage, and networking throughout the device-to-cloud landscape based on economic and physical constraints. Rather than routing all data from connected devices to centralised cloud endpoints, fog computing inserts a hierarchy of compute resources between the device and the cloud—closer to where data is actually generated.

Why Cloud-Only IoT Architectures Hit a Wall

Researchers at Cisco are widely credited with identifying the core problem: there is not enough public network capacity for tens of billions of devices to continuously stream data to a handful of large cloud providers. Physics and economics both get in the way.

Consider what a cloud-only IoT model requires at scale:

• Bandwidth: Projections for connected devices now exceed 50 billion. Sending raw sensor data from all of them to centralised cloud endpoints would require network capacity that simply does not exist today—and public networks are already under growing pressure from streaming media and entertainment.
• Latency: Many IoT applications—industrial monitoring, autonomous systems, healthcare devices—require near-real-time analysis. A round-trip to a distant cloud data centre introduces latency that can make responses too slow to be useful or safe.
• Reliability: Cloud-only models create a single dependency chain. If network connectivity is interrupted, edge devices lose their ability to act on data.
• Security: Transmitting sensitive sensor data across public networks to remote endpoints increases the attack surface significantly.

The conclusion is straightforward: IoT applications will need to compete for public network capacity on economic terms, and the economics increasingly favour computing resources located closer to where devices are installed.

A Concept With Deep Historical Roots

Remote monitoring and control of machines and environmental factors is not a new idea. Wikipedia’s article on Telemetry references an 1847 example in which French engineers built a network of weather and snow-depth sensors on Mont Blanc that transmitted real-time information to Paris.

Translated into modern fog terminology, that 19th-century system maps almost directly onto contemporary IoT architecture:

• The weather and snow-depth sensors → IoT endpoint devices
• A ruggedised local computer on the mountain → an edge gateway
• A private network connection → a low-latency, reliable link to a fog node
• The data centre in Paris → a fog node or cloud back-end for long-term analysis

The same pattern emerges across many related disciplines: machine-to-machine (M2M) communication, mesh computing, mobile edge computing, and dew computing. Each has its own standards bodies, communities, and best practices. Fog computing aims to serve as a unifying architectural umbrella for all of them.

How Fog Computing Works in Practice

Fog computing introduces a hierarchy of compute, storage, and networking resources between cloud data centres and end devices. This hierarchy typically looks like this:

1. Endpoint devices – Sensors, actuators, meters, cameras, and other IoT hardware that generate data.
2. Edge gateways – Local compute nodes (often ruggedised hardware) that aggregate data from nearby devices, apply filtering, run lightweight analytics, and pass only relevant data upstream.
3. Fog nodes – Mid-tier servers or clusters, potentially located at the network edge or in regional data centres, that perform more complex analytics, store intermediate data, and coordinate with both gateways and the cloud.
4. Cloud back-end – Centralised infrastructure reserved for long-running analytics, machine learning model training, archival storage, and management of the wider system.

By processing data at the appropriate tier, fog architectures reduce the volume of data that must traverse public networks, cut round-trip latency for time-sensitive decisions, and improve resilience when connectivity is intermittent.

Why Fog Computing Matters for DevOps and Platform Engineering

For DevOps and platform engineers, fog computing is not just an academic concept—it has direct operational implications:

• Pipeline design: Data pipelines must be designed to route data to the right processing tier, not just to a central cloud endpoint.
• Deployment targets: CI/CD pipelines may need to deliver software updates to edge gateways and fog nodes, not just cloud services.
• Observability: Monitoring and logging must span all tiers. An alert generated at an edge gateway that never reaches the cloud is invisible to centralised monitoring tools.
• Security posture: Each tier must be hardened independently. Edge devices running in uncontrolled physical environments require a different security model than cloud-hosted services.
• Interoperability: With many existing standards bodies and protocols in play—from industrial automation to consumer IoT—platform engineers must manage integration complexity across heterogeneous ecosystems.

The Road Ahead

The growth of IoT is real, rapid, and—under cloud-only architectural assumptions—unsustainable. Fog computing offers a principled, layered approach to distributing computation where it is physically and economically rational to do so.

The current landscape of related but fragmented disciplines (M2M, mesh computing, mobile edge computing, and others) each contribute valuable thinking, but lack the critical mass to rapidly scale IoT deployments to the level envisioned. A unified fog framework, implemented with open and interoperable standards, is a necessary foundation for any infrastructure team serious about building systems that can handle tens of billions of connected devices.

If you are designing IoT infrastructure today, the question is not whether fog computing principles apply to your architecture—it is how deliberately you are applying them.