Overview

Origin Protocol has partnered with Google Cloud to bring its decentralised commerce platform — branded Dshop — to the Google Cloud Marketplace. The move gives Google Cloud’s global network of developers and merchants a straightforward path to deploying blockchain-powered e-commerce stores. The partnership also includes a data integration that surfaces publicly available on-chain product data inside Google BigQuery, making it easier to analyse and build on top of.

What Is Origin Dshop?

Dshop is Origin Protocol’s open-source, decentralised storefront product. Each store is built on two decentralised technologies:

• Ethereum — acts as the authoritative, tamper-resistant ledger for product listing data and transactions.
• IPFS (InterPlanetary File System) — stores and distributes store content in a censorship-resistant, peer-to-peer manner.

Key characteristics of a Dshop include:

• Fully customisable — merchants control the full seller experience and branding.
• Censorship-resistant — because data lives on-chain and on IPFS, no single authority can take a store down.
• Free to use — there are no platform fees charged by Origin for running a store.
• Flexible payments — stores accept Ethereum (ETH), ERC-20 tokens (including Origin’s own OGN token), traditional credit cards, and PayPal.
• Drop-shipping integrations — native connections to select drop-shipping providers simplify order fulfilment.

Google Cloud Marketplace Listing

By listing on the Google Cloud Marketplace, Origin makes it possible for merchants and developers already operating within the Google Cloud ecosystem to discover, deploy, and operate a Dshop without leaving a familiar environment. As a formal Google Cloud Partner, Origin will co-market the platform to a wider range of merchant verticals, including:

• Physical e-commerce goods
• Digital goods
• Rental marketplaces
• Service-based businesses

Origin co-founder Matthew Liu described the vision in a company blog post:

“We envision a future where thousands of Dshops across many different verticals (e-commerce, digital goods, rentals, other services) are powered by the Origin technology platform running on Google Cloud infrastructure. We look forward to working with the Google Cloud team to bring new technology integrations to the market in the near future.”

Matthew Liu, Co-founder, Origin Protocol

Google BigQuery Integration: Making Blockchain Data Queryable

One of the most technically significant parts of this partnership is the decision to pipe publicly available Dshop product data into Google BigQuery. This addresses a longstanding practical problem: blockchain data is inherently difficult to index and query at scale.

Because merchants who opt into publishing their listing data on-chain make that data fully public, anyone can read it in principle — but extracting meaningful insights from raw blockchain data requires significant tooling. Origin uses the Ethereum ETL (Extract, Transform, Load) library, a project that Google Cloud participates in, to extract on-chain data and load it into BigQuery’s familiar SQL-queryable environment.

The practical result is something analogous to applying a search and indexing layer on top of raw blockchain data. Once the data is in BigQuery, three groups of users benefit directly:

• Affiliates and marketers — can discover products across Origin’s merchant network to promote, driving additional sales without needing to navigate raw blockchain explorers.
• Data scientists — can write standard SQL queries to analyse which merchant categories and product types are growing on-chain, identify trends, and produce reports.
• Developers — can query the shared public data layer and build third-party applications — recommendation engines, price trackers, analytics dashboards — on top of live, verified product data.

Why This Matters for the Decentralised Commerce Stack

Pairing a decentralised storefront with a managed cloud hyperscaler’s data warehouse illustrates a pragmatic architectural pattern: use decentralised infrastructure (Ethereum, IPFS) for the properties it does well — censorship resistance, data integrity, trustless settlement — while routing analytics workloads through centralised, highly optimised tools (BigQuery) where speed and query flexibility matter most.

For DevOps and platform engineering teams evaluating Web3 commerce stacks, this integration is worth noting because it reduces the operational burden of building custom blockchain indexers and ETL pipelines from scratch. Leveraging Ethereum ETL and BigQuery as managed infrastructure lowers the barrier to delivering analytics on on-chain data.

Key Takeaways

• Origin Dshop is now listed on the Google Cloud Marketplace, simplifying deployment for merchants and developers in the Google Cloud ecosystem.
• Publicly available on-chain product data from Dshop merchants is queryable via Google BigQuery using the Ethereum ETL library.
• Dshops support crypto payments (ETH, ERC-20/OGN), credit cards, and PayPal, with drop-shipping provider integrations built in.
• The architecture demonstrates a hybrid pattern: decentralised data storage and settlement, centralised analytics and discoverability.

This article is based on reporting from channellife.com and an Origin Protocol blog post published in August 2020.

Sponsored For some time now, DevSecOps has looked like the solution to the puzzle of how to get cloud applications out the door without turning throwing security on to the fire. Instead of trying to retrofit complex security policies to work in a hierarchical development pipeline, security becomes a distributed problem that every coder is asked to address.

DevSecOps solutions are by nature designed to be preventative. The idea is to remove complexity by baking robust security methodologies into software development from the earliest stages. Get it right from the outset, and reactive firefighting is greatly reduced.

Conveniently, this model – “shifting security left” to the coder rather than the expert in a fixed hierarchy – also makes sense when developing on cloud platforms that assume rapid deployment and collaboration. There is no development team, security team, or IT deployment team because they are one and the same person. In theory, that’s how security misconfigurations can be caught before they do harm. However, when it comes to cloud development, “shift left” is more talked about than practised. This situation has crept up on organisations that haven’t realised how programming culture has changed rapidly in the cloud era.

“There is a lack of control in this model. With the shift into cloud development and the fact that coders can always get a better answer of Stack Overflow and GitHub, it’s become practically impossible to track the supply chain. It’s a governance problem,” says Guy Eisenkot, the co-founder and vice president of product for a new Israeli-USA start-up, Bridgecrew. Security is now becoming a focal point of continuous development, he says, and this is a work in progress alongside priorities such as performance and features. The problem is that it is not enough to rely on tools alone.

Advertisement

Eisenkot uses the example of an Elasticsearch cluster that has inadvertently been left in a publicly accessible state. Under today’s hierarchical model, security checking will flag this, and the issue is sent to a ticketing system where it will probably languish for hours until someone with the necessary access spots it. But it would be far more efficient to focus on prevention, with the misconfiguration as part of a CI or CD pipeline that immediately pushes the issue to the team that made the error. Armed with the alert, remediation can happen at compile time rather than runtime, which would mean scrambling back from a potentially serious mistake.

“It’s not simply that the tools are not enough, it’s the fact that too many of them are reporting alerts and sending them to Slack channels, Jira tickets and other queues instead of going to developer’s desktop and CI tools,” says Eisenkot.

This is where Infrastructure as Code (IaC), a methodology that makes it easier for security to be “everyone’s business”, comes in to play. However, “easier” does not necessarily mean “perfect”. Let’s take a closer look.

InterrogatingIAC

The issue of configuration has been brought into sharp focus by the rise of IaC and its implementation, using tools such as Terraform. IaC’s promise is to remove the need for manual configuration and a jumble of individual console tools, turning provisioning of cloud and data centre services into machine-readable code which is bundled into automated workflows or templates.

IaC configuration to a cloud platform such as AWS can be either push (direct to the server using a configuration tool such as Chef or Puppet) or pull in the case of Terraform via a configuration server to the provider’s infrastructure. In most cases, Terraform treats resources as ‘immutable’, that is, it wipes a resource and starts again rather than making a configuration change by fiddling with an existing setup.

In the cloud era where developers use multiple platforms and timescales that have shrunk to hours, DevSecOps still asks a lot of developers to get it right first time, argues Eisenkot.

“It suddenly doesn’t take six months to deploy a change to an application, it takes a few minutes. This speed is a blessing in disguise because it creates challenges when we deploy software very fast. Where do we make the compromises?”

As he explains in a separate article on the company’s approach to Infrastructure as Code (IaC) misconfiguration, just having security tools to spot and remediate problems is not the same as managing development risk. The first problem is that anyone with the job of managing compliance and risk cannot easily see what’s going on in an environment where developers are often handed amazing amounts of freedom.

“There are blind spots,” says Eisenkot. “How do you ensure you know what’s going on in your environment? The idea that we know everything that’s going on in our architecture is an assumption we can’t make any more.”

But at least four in ten IaC templates contain a misconfiguration, according to Bridgecrew’s analysis, which often slip through into runtime vulnerabilities that expose resources. The tools to provision but also misconfigure cloud security have been successfully decentralised, but leaving the expertise to manage this problem centrally managed where they are becoming ineffective. The upshot is that many organisations have adopted IaC while lacking the means to manage it securely.

Bridgecrew’s approach to this problem is to build a new type of platform that oversees the entire development pipeline and its effect on security. In essence the system sanity-checks what developers are doing and issues pull requests before problems arise. This is achieved through overlapping capabilities that integrate with Amazon AWS, Microsoft Azure, and Google Cloud Platform (GCP), as well as violations in CloudFormation, Kubernetes and Terraform.

The first element is the ability to scan for IaC and other cloud misconfiguration and policy violations – ideally during build time so that errors don’t make it to deployed infrastructure. This process can also generate compliance reports to meet standards such as PCI. Importantly, uncovering misconfiguration and unauthorised changes at this stage makes fixing them much quicker and easier.

“Bridgecrew is deployed by running a CloudFormation or Terraform template on the subject cloud account. The template creates a read-only role on the subject IaaS account. This role enables it to perform scheduled scans of configuration states and continuously evaluate their latest states,” says Eisenkot.

For some organisations, this can turn into an almost archaeological task that involves pulling out problems in templates dating back years. Eisenkot uses the example of encryption by default, which wasn’t enabled on some database packages until three years ago. Uncovering those issues are easy wins that can happen on day one.

The basic element of Bridgecrew’s fix strategy is playbooks, automation and remediation scripts that make it easy to address common problems across different cloud platforms that might otherwise require several manual steps. A useful starting point, yes, but they have limitations in real-world development, Eisenkot acknowledges. Today, cloud deployment is highly automated, which means there is a risk that changes made by a playbook can easily be undone by a subsequent change.

The company has also put time into open source tools such as Checkov, an IaC static analysis tool which can be used to spot misconfigurations in Terraform, CloudFormation, and Kubernetes. Other Bridgecrew open source tools include the AWS Least Privilege Terraformer AirIAM, which generates a template designed to limit permissions for identity and access management to those which are strictly necessary; and Terragoat, “a vulnerable-by-design learning tool for experimenting with building secure cloud configuration pipelines“.

If scanning IaC templates sounds straightforward, Eisenkot is candid about the challenges of building a platform that can do this without creating its own headaches.

“It becomes extremely complicated when trying to build a data model that depicts how configuration will eventually manifest based on the prescribed plan. It is imperative to extract its variables and dependencies against the entire code base. Without this step, scans could result in both false positives in the form of configurations that don’t extract all their dependencies or false negatives that are not identified due to misinterpretation of IaC plan,” he says.

Ultimately, handing developers a new platform to manage bad decisions turned out to be only part of the solution. “We learned that it’s not only about giving developers the panic button, but we also had to educate them on making the right decisions when building new infrastructure in the public cloud.” More fundamental still was to educate developers to avoid bad configurations before they happened.

“By making sure those end up at a developer’s pull-request or build report, we were able to provide actionable advice on how to troubleshoot bad configurations and prevent them from getting into production in the first place.”

In a decade, the cloud has gone from powerful resource to invisible problem and, more recently, a risky liability. Having acquired a new set of tools, developers have learned that they must impose some discipline on how they use it. The solution, then, is not more tools to fix security problems but better integration of security as an ethos.

Google Publishes Five-Year Open-Source Snapshot

Google released a “by the numbers” overview of its open-source activity spanning 2015 through 2019, giving developers and organizations a concrete look at how one of the world’s largest technology companies engages with the broader open-source ecosystem. The data covers contributions to both Microsoft-owned GitHub and Google’s own internal Git hosting service, git-on-borg, which is the primary host for large Google-led projects such as Android and Chromium.

Employee Participation: 12,500 Contributors in 2019

According to Google, more than 9% of Alphabet’s full-time employees actively contributed to public repositories across git-on-borg and GitHub in 2019. In absolute terms, that translates to just under 12,500 employees—up from approximately 10,000 in 2018 and around 5,000 in 2015, representing a roughly 2.5× increase over the five-year period.

The steady growth in contributor headcount suggests that open-source participation has become increasingly embedded in Google’s engineering culture, rather than remaining the domain of a specialist group.

Repository Footprint: 8,000+ Public Repos on GitHub

Google hosts more than 8,000 public repositories on GitHub and over 1,000 public repositories on git-on-borg. Combined, the company says it has doubled its total number of public repositories over the five years to 2019.

Beyond its own hosted repositories, Google employees were active in over 70,000 repositories on GitHub in 2019 and pushed commits or opened pull requests in more than 40,000 repositories—a figure that underscores the breadth of engagement outside Google’s own projects.

Contribution Volume: Issues, Pull Requests, and Push Events

Sophia Vargas, a researcher at the Google Open Source Programs Office, explained the metrics Google chose to highlight—and why they differ from raw commit counts:

“For contribution volume on GitHub, we chose to focus on push events, opened, and merged pull requests instead of commits, as this metric on its own is difficult to contextualize. Note that push events and pull requests typically include one or more commits per event.”

— Sophia Vargas, Google Open Source Programs Office

Using those metrics, Google’s 2019 GitHub activity included:

• 570,000+ issues created
• 150,000+ pull requests opened
• 36,000+ push events

Compared with 2015, the number of issues created and push events had doubled, while open pull requests had tripled. More than 80% of pull requests opened by Google employees were closed and merged into active repositories—a metric Vargas cited as evidence of contribution quality, not just volume.

Diversification Across Repositories

One of the more meaningful trend lines in the data is how Google’s contributions have spread across a wider set of projects over time. In 2015, the top 25 repositories absorbed approximately 40% of Google’s opened pull requests. By 2019, that figure had dropped to around 20%—meaning contributions were distributed far more broadly across the ecosystem.

“For us, this indicates a healthy expansion and diversification of interests, especially given that this activity represents both Google, as well as a community of contributors that happen to work at Google.”

— Sophia Vargas, Google Open Source Programs Office

How Google’s Metrics Compare to Microsoft’s

When Microsoft announced its acquisition of GitHub in 2018, it positioned itself as the most active organization on the platform, citing two million commits to projects. Google deliberately chose a different set of indicators—push events and pull request activity—arguing that raw commit counts are hard to interpret without context (a single pull request may contain dozens of commits, or a single commit may represent months of work).

The methodological difference matters for DevOps teams benchmarking their own contribution policies: commit volume can be gamed or inflated by automated tooling, while merged pull request rates and cross-repository breadth are harder to manufacture and arguably more meaningful signals of genuine community engagement.

Notable Google Open-Source Projects

GitHub’s 2019 State of the Octoverse report (published November 2019) ranked projects by contributor count. Microsoft’s Visual Studio Code topped the list with approximately 19,100 contributors, followed by Azure Docs (14,000 contributors). Google’s Flutter UI framework came in third with around 13,000 contributors.

Other high-traffic Google-originated projects included:

• TensorFlow – the machine learning framework widely used in AI/ML pipelines
• Kubernetes – the container orchestration system now governed by the Cloud Native Computing Foundation (CNCF)
• OSS-Fuzz – a continuous fuzzing service that integrates with open-source projects to automatically find security vulnerabilities and bugs

Vargas specifically highlighted OSS-Fuzz as an example of Google’s contributions to open-source security infrastructure—it is publicly available on GitHub and can be integrated by any project maintainer looking to harden their codebase against memory safety bugs and other low-level vulnerabilities.

Key Takeaways for DevOps and Engineering Leaders

• Commit count alone is a weak proxy for open-source contribution quality. Merged pull request rates and cross-repository breadth provide better signal.
• Employee participation scales with deliberate culture investment. Google’s contributor headcount growing from 5,000 to 12,500 in five years does not happen by accident—it requires tooling, policies, and management buy-in.
• Diversification of contributions reduces dependency on a small set of flagship projects and builds goodwill across the broader ecosystem.
• Security tooling is a form of open-source contribution. Projects like OSS-Fuzz provide compounding value well beyond Google’s own codebases.

Original reporting by ZDNet, August 2020. Data and quotes sourced from Google’s Open Source Programs Office.

Google Cloud recently announced that it will now be the cloud provider for Wipro Limited’s enterprise-wide systems applications and products in data processing (SAP) footprint.

The partnership will bring SAP applications and workloads to the cloud to support over 180,000 of Wipro’s employees.

Specializing in global information technology, Wipro will modernize and transform its enterprise resource planning (ERP) system to SAP’s flagship, which is the company’s leading product.

Dig Deeper
Google Cloud, Orange Partner to Boost AI, Edge Computing Services
Google, Box Extend Partnership to Transform Work in the Cloud
Google Cloud Launches Multi-Cloud Solution to Help Orgs Analyze Data
Wipro will then relocate SAP workloads onto Google Cloud Platform (GCP), Google officials said.

“Wipro is embracing digital transformation at speed and scale. By modernizing their core systems and technologies with Google Cloud, they have a powerful and scalable foundation to accelerate their strategic enterprise priorities and build for the future,” Thomas Kurian, CEO, Google Cloud, said in the announcement.

As part of the collaboration, Wipro will leverage G Suite for some of its employees as a workplace productivity platform. Wipro believes that G Suite has strong interoperability and security controls and features that allow for real-time collaboration, even in remote work environments.

“As a provider of digital transformation services to some of the world’s most impactful businesses, it is critical that our own core systems and technologies are running on intelligent and modern platforms that encompass the needs of the future,” said Bhanumurthy B.M, president and chief operating officer, Wipro Limited.

“This transformation program will help us to run our most business-critical workloads and applications with speed and agility, and to support our customers more effectively.”

Wipro’s industry-focused solutions, with Google Cloud technologies, enable enterprises to future-proof their IT investments, Google officials said. And Wipro’s Google Cloud practice also helps transform businesses and healthcare organizations as well.

This transformation includes application modernization, data analytics, artificial intelligence, SAP workload migration, and industrialized cloud migrations at scale.

Additionally, Wipro integrated Anthos, Google’s open platform for managing applications, into its services offerings to enable hybrid cloud deployments for customers.

Back in April 2019, Google launched Anthos, a platform to allow providers to run applications, unmodified, on existing hardware investments or in the public cloud.

Anthos allows healthcare organizations to manage workloads running on third-party clouds like AWS and Azure, to deploy, run, and manage applications on the cloud, without requiring administrators to learn different environments and APIs, Google officials said.

And in mid-July of this year, Google launched BigQuery Omni, a multi-cloud analytics platform designed to help customers to bring the power of BigQuery to data stored in Google Cloud, Amazon Web Services (AWS), and Microsoft Azure.

Through Anthos, BigQuery Omni aims to support enterprises with breaking down silos and creating actionable business insights at an affordable price.

“The ability to run the same database on multiple cloud/data center environments is an important consideration when selecting a new data platform,” said Matt Aslett, research director, data, AI and analytics, 451 Research, in a statement.

“As hybrid and multi-cloud adoption has become the norm, enterprises are increasingly looking for data products that provide a consistent experience and lower complexity of using multiple clouds, while enabling the ongoing use of existing infrastructure investments,” he added.

What Is Cloud Computing?

Cloud computing is the delivery of on-demand computing services—including servers, storage, databases, networking, analytics, and software—over the internet. Instead of owning and operating physical hardware in a private data centre, organisations consume those capabilities as a metered service from a cloud provider and pay only for what they use.

The analogy most practitioners reach for is a utility bill: you do not build a power plant to run your office; you plug in and pay per kilowatt-hour. Cloud computing applies the same logic to compute and storage resources.

How Cloud Computing Works

Cloud providers maintain massive, globally distributed data centres full of physical servers, networking equipment, and storage hardware. They virtualise those resources and expose them through APIs and management consoles. Customers provision what they need—a virtual machine, a managed database, a container orchestration cluster—without touching a single physical rack.

From a DevOps perspective, this means infrastructure can be defined as code, spun up in minutes, and torn down just as quickly—enabling rapid iteration, immutable deployments, and cost-controlled experimentation.

Cloud Deployment Models

Cloud computing is not a single architecture. Choosing the right deployment model is one of the first decisions a team must make, and it affects everything from cost to compliance posture.

Public Cloud

Resources are owned and operated by a third-party provider and delivered over the public internet. Customers share the same underlying physical infrastructure, isolated by virtualisation. Examples include AWS, Microsoft Azure, and Google Cloud Platform. Public cloud offers the highest elasticity and the lowest upfront cost.

Private Cloud

Infrastructure is dedicated exclusively to one organisation, either hosted on-premises or by a third-party provider in a single-tenant environment. Private cloud gives organisations maximum control over hardware, network configuration, and data residency—important for regulated industries such as finance and healthcare.

Hybrid Cloud

A hybrid model connects private and public cloud environments, allowing workloads and data to move between them based on policy, cost, or performance requirements. A common pattern is keeping sensitive data on a private cluster while bursting variable compute demand to a public cloud. Achieving genuine hybrid cloud requires consistent networking, identity management, and tooling across both environments.

Cloud Service Models

Beyond deployment topology, cloud services are also categorised by how much of the stack the provider manages:

• Infrastructure as a Service (IaaS) — The provider manages physical hardware and virtualisation. You manage the OS, runtime, and application. Example: an EC2 instance or a bare-metal server from a cloud provider.
• Platform as a Service (PaaS) — The provider manages the underlying infrastructure and runtime environment. You manage the application code and data. Example: a managed Kubernetes service or a cloud-hosted database.
• Software as a Service (SaaS) — The provider manages everything. You consume a fully operational application via a browser or API. Example: a project management tool or a hosted CI/CD platform.

Most real-world architectures combine all three layers depending on the workload.

Key Benefits of Cloud Computing

Cost Efficiency

Capital expenditure on hardware, cooling, and facilities is replaced by operational expenditure tied directly to usage. Teams can right-size resources, use spot or preemptible instances for batch workloads, and shut down non-production environments overnight—none of which is possible with owned hardware sitting idle in a rack.

Elastic Scalability

Cloud resources scale up or down in response to demand, either manually or automatically through auto-scaling policies. This means an application can handle a sudden traffic spike without pre-provisioning for peak load around the clock.

Global Reach

Major cloud providers operate regions across multiple continents. Deploying an application closer to end users reduces latency and improves reliability. Content delivery networks (CDNs) integrated with cloud platforms extend this reach further to the edge.

Operational Productivity

Managed services handle routine operations—hardware replacement, OS patching, database failover, TLS certificate rotation—that would otherwise consume engineering time. Teams can redirect that effort toward product development and reliability engineering.

Security and Compliance

Reputable cloud providers invest heavily in physical security, network security, and compliance certifications (SOC 2, ISO 27001, PCI DSS, HIPAA, and others). Customers inherit those controls for the portion of the stack the provider manages. That said, cloud security operates on a shared responsibility model: the provider secures the infrastructure; the customer is responsible for securing their workloads, access controls, and data within that infrastructure. Misunderstanding this boundary is one of the most common causes of cloud security incidents.

Common Cloud Computing Use Cases

Cloud computing underpins a wide range of workloads that DevOps teams routinely build and operate:

• Cloud-native application development — Building microservices and containerised workloads designed from the ground up to run on cloud infrastructure using tools such as Kubernetes, serverless functions, and managed queuing services.
• CI/CD pipelines — Running build, test, and deployment automation on ephemeral cloud compute, eliminating the need for a dedicated build server fleet.
• Data storage and backup — Using object storage (e.g., S3-compatible services) for durable, geo-replicated data retention at a fraction of the cost of on-premises SAN or NAS.
• Data analytics and machine learning — Spinning up large compute clusters for periodic analytics jobs or model training, then tearing them down when the job is complete.
• Disaster recovery — Replicating critical workloads to a secondary cloud region to meet recovery time and recovery point objectives without maintaining a full standby data centre.
• Software delivery (SaaS) — Delivering applications to end users over the internet without distributing or installing software on client machines.

Things to Consider Before Adopting Cloud

Cloud computing is not universally the right answer for every workload. Engineers and architects should evaluate:

• Data sovereignty and residency — Regulatory frameworks in some jurisdictions require data to remain within specific geographic boundaries. Confirm your chosen provider offers compliant regions.
• Vendor lock-in — Proprietary managed services accelerate development but can create tight coupling to a specific provider. Evaluate the trade-off against portability requirements.
• Total cost of ownership — Cloud costs can grow unexpectedly without disciplined tagging, budget alerts, and right-sizing. Implement cost governance from day one.
• Latency-sensitive workloads — Some real-time processing or industrial control workloads require compute at the edge or on-premises, and may not tolerate the variable latency of a public cloud region.
• Skill requirements — Moving to cloud shifts operational burden from hardware management to platform engineering. Teams need investment in cloud skills and tooling.

Summary

Cloud computing provides on-demand access to compute, storage, and networking resources over the internet, replacing owned hardware with metered services. The three deployment models—public, private, and hybrid—serve different security, compliance, and cost requirements. IaaS, PaaS, and SaaS describe how much of the stack the provider manages versus the customer. For DevOps teams, the practical value of cloud lies in elastic scalability, infrastructure-as-code workflows, managed operational burden, and the ability to ship and iterate faster than legacy infrastructure allows. Adopted thoughtfully, cloud computing is a force multiplier; adopted carelessly, it introduces cost and security risks that are difficult to unwind.

The Problem Kubera Solves

Kubernetes was created at Google to tame the complexity of developing, deploying, and decommissioning containers at scale. The irony is that Kubernetes itself has now become complex enough to require its own layer of operational tooling. MayaData, the open-source company best known for the CNCF storage project OpenEBS, built Kubera to address exactly that problem.

According to Murat Karslioglu, Head of Product at MayaData: “Kubera builds on our experience in supporting a community of thousands of OpenEBS users. Originally intended to be used only by our support team, we quickly learned that our users could benefit from Kubera as well.”

What Is Kubera?

Kubera is a cloud-delivered service focused on the operational management of Kubernetes environments, with particular depth around stateful workloads and persistent storage. It is designed for both individual developers and enterprise teams running Kubernetes in production.

MayaData CEO Evan Powell offered this analogy to explain where Kubera sits relative to OpenEBS:

“Whereas our OpenEBS is often compared to vSAN from VMware, Kubera provides the analytics, visualization, controls and automation for efficient operations of OpenEBS on Kubernetes — much like VMware’s vRealize Operations software provides similar capabilities to users of vSAN.”

Evan Powell, CEO, MayaData

Core Capabilities

Kubera’s feature set at launch covers four main operational areas:

• Stateful workload management: Simplified configuration, management, and monitoring of stateful applications on Kubernetes, including Kafka, PostgreSQL, Cassandra, and others.
• Backup and restore: Streamlined backup of stateful workloads whether they use OpenEBS or another storage backend.
• Dynamic visualisation and controls: Interactive visualisations of the full Kubernetes environment, with point-and-click controls for snapshotting, cloning, compliance checks, and alerting.
• Automated lifecycle management: Automated management of data-layer components, including the OpenEBS Enterprise Edition and underlying storage resources such as local disks and cloud volumes.

OpenEBS Integration

Kubera is closely integrated with OpenEBS, the CNCF open-source container-native storage project that MayaData sponsors. Alongside the Kubera launch, MayaData also made available an Enterprise Edition of OpenEBS, which is managed through the Kubera platform. However, Kubera’s backup and management features are not limited to OpenEBS storage — the service is designed to work with other storage backends as well.

Pricing and Plans

At the time of launch, MayaData offered three tiers:

• Free individual plan — available to individual developers exploring Kubera.
• Team plan — targeted at smaller teams requiring shared access and collaboration features.
• Enterprise plan — includes MayaData support for the full environment, covering OpenEBS Enterprise Edition and related components. Subscriptions started at $49 per user per month.

Context: Why Kubernetes Operational Management Matters

As Kubernetes adoption matured past initial pilots into production deployments, teams discovered that Day 2 operations — monitoring, storage management, backup, compliance, and cost visibility — were under-served by the core Kubernetes toolset. Stateful workloads in particular added complexity that basic kubectl workflows were never designed to handle at scale.

Tools like Kubera represent a broader industry effort to build opinionated management planes on top of Kubernetes, similar to the way enterprise virtualisation vendors built management layers over bare hypervisors. MayaData’s specific focus on storage-centric operations reflects their background in the OpenEBS project and the needs of the users who adopted it.

Whether you are running a small team on a single cluster or an enterprise fleet spanning multiple clouds, operationalising stateful Kubernetes workloads benefits from consolidated tooling that surfaces actionable signals rather than raw metrics. Kubera is MayaData’s answer to that gap.

The Gap Between DevOps Aspiration and Reality

According to the Atlassian 2020 DevOps Trends Survey, released on June 2, 2020, there is a measurable disconnect between how DevOps practitioners and organizational decision-makers perceive the state of their DevOps implementations. The survey was conducted by CITE Research and drew responses from 500 developers and IT decision-makers.

“The biggest surprise was the gap between practitioners and executives in how they perceived their DevOps implementations,” said Tiffany To, head of Agile and DevOps solutions at Atlassian, in comments to ITPro Today.

Key Survey Findings

• 62% of IT practitioners agree it is difficult to measure the impact of DevOps progress and success, compared with 49% of decision-makers.
• 58% of IT practitioners say their organization has no clear way to measure DevOps success, compared with 47% of decision-makers.
• Nearly half of all respondents reported an increase in collaboration with non-technical teams after adopting DevOps practices — a positive finding that Atlassian highlighted as evidence that the right tooling can extend DevOps culture beyond engineering.

“To us, that’s a clear sign that DevOps teams need the right tools and practices in place to collaborate beyond engineering,” To said.

Atlassian’s Platform-Wide Integration Updates

Alongside the survey, Atlassian released a set of new features spread across its cloud product portfolio — including Jira Software, Bitbucket Cloud, Opsgenie, and Confluence — with the goal of reducing context-switching and enabling a more seamless application development pipeline.

Jira and Bitbucket Cloud: A Unified Work Dashboard

One of the headline additions is a new work dashboard inside Bitbucket Cloud that surfaces assigned Jira Software issues directly within the Bitbucket interface. While Bitbucket Cloud and Jira Software have long been integrated, developers previously had to switch between tools to view their assigned issues.

“Prior to this, users would have needed to hop over to Jira to view them, taking the developer out of Bitbucket and waste time checking between tools,” To explained. “Now, the dashboard has been brought into Bitbucket, so developers can stay in one tool to view assigned work.”

Opsgenie: Incident Response Aligned with Collaboration Tools

Atlassian’s Opsgenie alerting service received improved integrations with collaboration tools, most notably Slack. The improvements address how teams communicate and coordinate during major incidents:

• When an incident occurs, teams can now launch a dedicated Slack channel directly from Opsgenie to begin collaborating immediately.
• All Slack communications from that channel are automatically saved to the incident details screen in Opsgenie.
• Those communications can be exported to a postmortem report in Confluence for structured review after the incident is resolved.
• A new integration with Bitbucket enables developer teams to investigate deployment-related incidents directly from Opsgenie.
• Users can now open a Jira issue from the incident details screen in Opsgenie and map it to a specific project so the right team members are notified.

Code Insights and the Incident Investigation Dashboard

Atlassian also announced integration of its Code Insights feature — which enables automated code scanning for potential vulnerabilities — with Opsgenie via a new Incident Investigation Dashboard.

Here is how the end-to-end workflow is designed to function:

1. A Code Insights scan runs against the codebase and detects a vulnerability.
2. The deployment is automatically paused.
3. A vulnerability report is surfaced to the developer directly inside Bitbucket — no need to switch to another tool.
4. The developer can convert vulnerabilities into Jira issues from within Bitbucket.
5. As issues are resolved, they are recorded in the project history.
6. When all issues are resolved, the deployment pipeline automatically resumes.

The intent of this workflow is to keep the developer in a single tool — Bitbucket — throughout the entire vulnerability detection, triage, and remediation cycle.

Atlassian’s Broader DevOps Strategy

The common thread across these updates is reducing friction caused by context-switching between disconnected tools — a practical pain point for engineering teams that the 2020 survey data underscored. Atlassian’s approach positions its integrated cloud portfolio as both an accessible entry point for teams beginning their DevOps journey and a customizable, extensible platform for mature teams looking to optimize their toolchains.

“We aim to provide an easy entry point to those trying to implement DevOps while still providing an open and highly customizable platform for those looking to extend their toolchain and practices in order to ship better quality software faster,” To said. “You will see us expand our offerings to fit even more use cases as we look to align DevOps with IT and business teams through a common understanding of work.”

Summary: What Changed in the Atlassian DevOps Platform (June 2020)

Source: ITPro Today / Atlassian, June 2020.

HCL and Google Cloud Expand Strategic Partnership

HCL Technologies and Google Cloud announced the expansion of their strategic partnership to bring HCL’s software portfolio — beginning with HCL Commerce — to Google Cloud infrastructure. Under the agreement, Google Cloud becomes the preferred cloud platform for HCL Commerce, providing global, secure, and elastic infrastructure to power enterprise eCommerce strategies at scale.

A key technical element of the partnership is HCL’s stated intention to leverage Google Cloud’s Anthos platform to enable multi-cloud and hybrid-cloud deployments of HCL Commerce — giving enterprise customers greater deployment flexibility without abandoning existing on-premises or multi-cloud investments.

What Is HCL Commerce?

HCL Commerce is a cloud-native eCommerce platform used by businesses across multiple industries worldwide. According to HCL, the platform drives more than $100 billion in annual client revenues. It is designed to support both business-to-business (B2B) and business-to-consumer (B2C) use cases on a single unified platform.

Key capabilities of HCL Commerce include:

• Scalability and performance: Designed to handle high transaction volumes and seasonal spikes without manual intervention.
• Merchandising flexibility: Enables businesses to rapidly create and iterate on merchandising strategies and launch new sales channels.
• Omnichannel support: Supports B2B and B2C operations from the same platform, reducing architectural complexity.
• Adaptability: Built to respond to evolving market conditions and extend beyond the initial transaction to the full customer lifecycle.

What the Partnership Delivers for Enterprises

Running HCL Commerce on Google Cloud is intended to give enterprises access to the combined strengths of both platforms:

• Global infrastructure: Google Cloud’s worldwide network of regions and points of presence provides low-latency delivery for customers in multiple geographies.
• Elastic scalability: Cloud-native elasticity allows commerce workloads to scale up or down automatically in response to demand.
• Security: Google Cloud’s security model, including encryption in transit and at rest, extends to HCL Commerce deployments.
• AI, ML, and analytics: Enterprises can leverage Google Cloud’s machine learning and data analytics capabilities — such as BigQuery and Vertex AI — to build data-driven customer experiences and personalisation engines on top of their commerce data.
• Anthos for hybrid and multi-cloud: Anthos allows HCL Commerce workloads to run consistently across on-premises environments, Google Cloud, and other cloud providers, reducing vendor lock-in risk.

Real-World Customer Outcomes

Several early customers provided commentary on results they attributed to the partnership:

DFS (UK Furniture Retailer)

Russ Harte, Chief Technology Officer at DFS, cited the ability to react quickly with functional deployments and noted a significant reduction in total cost of ownership after adopting HCL Commerce on Google Cloud.

Intertoys

Robin Tichler at Intertoys reported that the company went live with HCL Commerce on Google Cloud in 15 weeks and was able to scale to 3× its normal transaction volumes during a period of heightened consumer demand — a result attributed to the elastic infrastructure provided by Google Cloud.

Executive Perspective

Darren Oberst, Corporate Vice President and Head of HCL Software:
“The collaboration between Google Cloud and HCL Commerce is helping customers rapidly execute their digital transformation strategy that is rooted in the new normal. With the support of our global implementation partner ecosystem, we can now deliver a proven, comprehensive commerce solution across all industries, handling the challenges of today and in the future.”

Kevin Ichhpurani, Corporate Vice President, Global Ecosystem at Google Cloud:
“It is more important than ever for firms spanning all industries to deliver strong, customer-centric eCommerce experiences. We’re proud that Google Cloud infrastructure will power HCL Commerce, helping businesses leverage the elasticity and reliability of Google Cloud and ultimately delivering positive eCommerce experiences for customers around the world.”

Kalyan Kumar, CTO and Corporate Vice President, HCL Technologies:
“The HCL Google Cloud Business Unit is enabling product collaboration across HCL Software and Google Cloud. The launch of HCL Commerce on Google Cloud is the first among a number of planned joint offerings built around application modernization, data center and database value unlock.”

Background: HCL’s Google Cloud Business Unit and Native Labs

This 2020 announcement builds on a partnership that began in 2019, when HCL and Google Cloud launched the HCL Google Cloud Business Unit — a dedicated organisation focused on accelerating enterprise cloud adoption worldwide.

To support implementation and innovation, HCL established three Google Cloud Native Labs in the following locations:

• New York, USA
• London, UK
• New Delhi area, India

These labs provide business-focused design workshops, help customers build minimum viable products (MVPs) on Google Cloud, and develop industry-specific intellectual property to accelerate time-to-value for enterprise engagements.

Key Takeaways for DevOps and Platform Teams

• HCL Commerce’s move to Google Cloud as a preferred platform signals a continued industry shift toward cloud-native commerce architectures managed by specialised cloud providers.
• The use of Anthos is significant for teams managing hybrid or multi-cloud estates — it provides a consistent Kubernetes-based control plane across environments, reducing operational fragmentation.
• Enterprises evaluating eCommerce platforms should factor in Google Cloud’s AI and analytics ecosystem when assessing the total data value unlockable from a commerce deployment.
• The 15-week go-live timeline reported by Intertoys suggests meaningful investment in pre-built accelerators and deployment automation within the HCL/Google partnership, though individual results will vary by implementation complexity.

Bengaluru: DevOps Enabler & Co., the company behind an exclusive startup bundle for organizations that want to scale their operations, today announced it has attained a gold Microsoft DevOps And Cloud Platform competency, demonstrating a “best-in-class” ability and commitment to meet Microsoft Corp. customers’ evolving needs in today’s mobile-first, cloud-first world and distinguishing itself within Microsoft’s partner ecosystem.

DevOps Enabler & Co., the company behind an exclusive startup bundle for organizations that want to scale their operations, today announced it has attained a gold Microsoft DevOps And Cloud Platform competency, demonstrating a “best-in-class” ability and commitment to meet Microsoft Corp. customers’ evolving needs in today’s mobile-first, cloud-first world and distinguishing itself within Microsoft’s partner ecosystem.

To earn a Microsoft competency, partners must successfully complete exams (resulting in Microsoft Certified Professionals) to prove their level of technology expertise, and then designate these certified professionals uniquely to one Microsoft competency, ensuring a certain level of staffing capacity. They must also submit customer references that demonstrate successful projects, meet a performance (revenue and or consumption/usage) commitment (for most gold competencies), and pass technology and/or sales assessments.

The DevOps Enabler and Co. startup bundle provides customers with cloud migration and enablement, DevOps implementation, remote working security, and migration of their applications to containers.

DevOps Enabler & Co., an ISO 27001:2013 certified organization, provides software delivery automation to help companies grow their business. With expertise in cloud computing and DevOps, the organization helps its customers manage cloud platforms, provides DevOps automation, big data implementation, and management and staffing services. The Microsoft DevOps and Cloud Platform Gold Competency provides DevOps Enabler & Co. with access to Microsoft technical team members and advisors who can help it make the most of Microsoft technologies for its clients.

“This Microsoft Gold DevOps and Cloud Platform competency is a demonstration of our testament to providing nothing but the best to our customers, even in these uncertain times. It shows our commitment to the technology market and the skill and expertise of Microsoft products that we share,” said Ram Suresh, Vice President for DevOps Enabler & Co. “This gold competency shows how our teams have the knowledge and experience to accelerate our customers’ success. It is a major step in our journey, as it brings the power of DevOps and the cloud to our Windows community and especially our Microsoft-based enterprise customers.”

“By achieving a gold competency, partners have demonstrated the highest, most consistent capability and commitment to the latest Microsoft technology,” said Gavriella Schuster, corporate vice president, One Commercial Partner (OCP) at Microsoft Corp. “These partners have a deep expertise that puts them in the top of our partner ecosystem, and their proficiency will help customers drive innovative solutions.”

The Microsoft Partner Network helps partners strengthen their capabilities to showcase leadership in the marketplace on the latest technology, to better serve customers, and to easily connect with one of the most active, diverse networks in the world.

DevOps Enabler & Co. is focused on providing the best of DevOps services to help its customers in the best way possible. The startup bundle isn’t just a consultation; it’s a holistic growth solution designed for companies that want to scale quickly and tackle the challenges that come their way. DevOps Enabler & Co. provides software delivery automation, cloud enablement and management, and big data and staffing services to its customers.

Azure Quantum Opens to Select Developers

At its Build 2020 developer conference, Microsoft announced a limited preview of Azure Quantum, making its cloud-based quantum computing platform available to select developers and enterprises. The company positioned the release as the product of nearly two decades of internal quantum research, embedded across every layer of the Azure Quantum stack.

The limited preview gives participants access to an open ecosystem that spans quantum software, hardware, and solutions — sourced from both Microsoft and a set of launch partners.

Partner Ecosystem and Hardware Access

Azure Quantum launched with hardware and software contributions from four key partners:

• 1QBit — quantum software and optimization solutions
• Honeywell — trapped-ion quantum hardware
• IonQ — trapped-ion quantum processors
• QCI (Quantum Computing Inc.) — quantum-ready software solutions

By aggregating multiple hardware backends under a single cloud platform, Microsoft aims to give developers the flexibility to target different quantum architectures without having to manage separate vendor relationships or toolchains.

Quantum-Inspired Solutions for Classical Hardware

Alongside access to actual quantum processors, Azure Quantum also offers what Microsoft calls quantum-inspired solutions — optimization algorithms derived from quantum computing research that run on classical hardware. These pre-built solutions are designed to tackle complex optimization problems in logistics, finance, and scheduling without requiring a physical quantum machine, making them immediately practical for enterprise workloads.

The Road to a Scalable Quantum Computer

At the time of the announcement, Microsoft had not yet publicly demonstrated a general-purpose quantum supercomputer. Microsoft’s longer-term research program is focused on topological qubits — an approach the company believes will produce more stable and scalable quantum processors compared to competing qubit technologies. Researchers were described as actively developing the software infrastructure needed to support a future scalable quantum machine.

Microsoft expressed confidence that a scalable quantum machine could be achievable within a five-year horizon from the time of the announcement, though no firm timeline or performance milestones were committed to publicly.

Why Qubits Matter: A Quick Primer

Classical computers store and process information as bits — binary values that are either 0 or 1 at any given moment. This binary constraint limits throughput when processing combinatorially large problem spaces.

Quantum computers instead use qubits, which exploit quantum mechanical properties — specifically superposition and entanglement — to represent and process 0 and 1 simultaneously. This allows a quantum processor to evaluate many possible solutions in parallel, offering a theoretical advantage for specific problem classes such as:

• Cryptography and security
• Drug discovery and molecular simulation
• Climate modeling and clean energy research
• Materials design
• Large-scale optimization problems

It is important to note that quantum computers are not universally faster than classical machines — they offer advantages only for specific problem types where quantum algorithms apply.

Competitive Context

Microsoft’s announcement came in the context of a rapidly accelerating quantum computing race. Google had previously claimed to have demonstrated quantum supremacy with its Sycamore processor, reportedly completing a specific calculation in approximately 200 seconds that Google estimated would take classical supercomputers thousands of years — a claim that was subsequently disputed by IBM and others regarding the classical comparison baseline. IBM, Google, and Amazon (via Amazon Braket) were also offering quantum cloud services at the time, making Azure Quantum a direct competitive entry into an already active market.

What This Means for DevOps and Cloud Engineers

For DevOps practitioners and cloud engineers, the Azure Quantum preview represented a low-friction entry point into quantum development. Key practical takeaways from the announcement include:

• Unified access: Multiple quantum hardware backends accessible through the familiar Azure portal and SDK.
• Classical bridge: Quantum-inspired optimization tools that work today on classical infrastructure, without waiting for fault-tolerant quantum hardware.
• Open ecosystem: Microsoft’s stated goal of an open platform means developers are not locked into a single hardware vendor.
• Q# language: Microsoft’s domain-specific language for quantum programming, Q#, is the primary development interface for Azure Quantum workloads.

As quantum computing matures from research curiosity to cloud service, familiarity with hybrid classical-quantum workflows is increasingly relevant for engineers working in high-performance computing, AI infrastructure, and scientific computing domains.

What Is the Hybrid Cloud?

At its simplest, a hybrid cloud is a combination of on-premises and off-premises IT resources. More precisely, it refers to a computing environment made up of on-premises private cloud infrastructure combined with third-party public cloud services, integrated through some form of orchestration layer that allows workloads and data to move between the two.

The defining characteristic of a hybrid cloud is that workloads and data can shift between private and public environments in a flexible, policy-driven way. This allows organisations to respond to changes in demand, cost, and compliance requirements without being locked into a single infrastructure model.

Key Benefits of the Hybrid Cloud Model

Flexibility and Scalability

The primary advantage of the hybrid cloud is flexibility. On-premises infrastructure requires advance planning to expand capacity and carries significant capital cost. The public cloud, by contrast, can provision resources on demand with minimal lead time.

A pattern commonly associated with hybrid architectures is cloud bursting — the practice of temporarily offloading workloads to a public cloud when demand exceeds the capacity available in the private cloud. Typical use cases include:

• Seasonal traffic spikes — e-commerce platforms handling peak holiday demand, for example, can absorb excess load in a public cloud without over-provisioning private infrastructure for the rest of the year.
• Geographic or event-driven demand variations — sudden surges driven by location, marketing campaigns, or external events.
• Batch and analytics workloads — computationally intensive jobs that run periodically and do not justify permanent on-premises capacity.

For data storage specifically, on-premises private cloud storage typically offers the lowest latency and highest throughput for frequently accessed, performance-sensitive data. Data that is accessed infrequently, or that does not require the lowest possible latency, can be tiered to public cloud storage where it remains accessible but at a lower cost.

Cost Optimisation

The hybrid model allows IT teams to match workloads to the most cost-effective resource available. Public cloud removes the need for capital expenditure on hardware and reduces ongoing operational overhead. At the same time, retaining a private cloud component for predictable, steady-state workloads can be more economical than running those workloads in the public cloud long-term.

Services can be scaled up, redeployed, or scaled down as business needs change, avoiding the expense of idle on-premises capacity and reducing the risk of over-provisioning.

Data Control and Compliance

Regulated industries — financial services, healthcare, government — often face requirements that make it impractical to move all workloads to the public cloud. A hybrid model allows sensitive data and regulated workloads to remain on-premises or in a private environment that meets compliance requirements, while less sensitive workloads take advantage of public cloud economics and agility.

Limitations: When Hybrid Cloud Is Not the Right Fit

Hybrid cloud is not the right solution for every organisation or workload. Key limitations to consider include:

• Cost of private infrastructure — Setting up and maintaining on-premises private cloud infrastructure involves significant capital and operational expense. Smaller organisations operating on constrained IT budgets may find that an entirely public cloud solution is more cost-effective.
• Latency-sensitive applications — Applications that require the absolute lowest latency may not perform adequately when workloads or data must traverse the network boundary between private and public environments. The impact depends heavily on the specific workload type: latency tends to matter more for real-time compute workloads than for bulk data transfers.
• Complexity of management — Operating across two or more environments introduces integration, security, and governance complexity. Without the right tooling and skills, this overhead can outweigh the flexibility benefits.
• Workload analysis is essential — Hybrid cloud delivers the best results when each application and workload has been examined to determine the optimal placement — private cloud, public cloud, or traditional on-premises IT. Without that analysis, organisations risk placing workloads in sub-optimal environments, negating the cost and performance advantages.

Deciding Whether to Go Hybrid

The decision to adopt a hybrid cloud model should be driven by a structured assessment of your organisation’s workloads, compliance requirements, budget, and operational capabilities — not by industry trends alone.

A hybrid approach is likely worth considering if:

• You have workloads with highly variable demand that do not justify permanent on-premises capacity.
• You have regulatory or data-sovereignty requirements that constrain certain workloads to controlled environments.
• You maintain legacy systems that cannot be easily migrated to the public cloud but need to interoperate with cloud-native services.
• You want to modernise gradually rather than through a single, high-risk migration.

A purely public cloud model may be preferable if:

• Your organisation is small or has no existing on-premises infrastructure worth preserving.
• You have no compliance requirements that mandate private infrastructure.
• The cost and complexity of managing private cloud would outweigh the flexibility it provides.

Planning a Successful Hybrid Cloud Implementation

For organisations that do move forward with a hybrid cloud architecture, thorough planning is critical. Specific areas to address include:

• Workload classification — Categorise workloads by performance requirements, data sensitivity, compliance constraints, and cost profile before assigning them to an environment.
• Networking and connectivity — The performance characteristics of the link between your private and public environments will directly affect latency-sensitive workloads. Direct connectivity options (such as dedicated private links to major cloud providers) can mitigate this.
• Security and identity — A unified identity and access management approach across both environments reduces the risk of security gaps at the boundary.
• Orchestration and automation — Tools that provide a consistent operational model across private and public environments — for deployment, monitoring, scaling, and cost management — are essential for managing hybrid complexity efficiently.
• Governance and cost visibility — Without clear visibility into spending across both environments, cost optimisation is difficult. Implement tagging strategies and centralised cost management from the outset.

Summary

The hybrid cloud model offers genuine advantages — flexibility, cost optimisation, and the ability to bridge on-premises constraints with public cloud capabilities — but it is not universally the right answer. Its value depends on workload characteristics, organisational scale, compliance requirements, and the operational maturity needed to manage a more complex environment.

Organisations that approach hybrid cloud with a structured workload assessment and a clear integration strategy are well positioned to build an infrastructure that adapts to changing business demands while controlling costs and maintaining the control they need over critical data and systems.

What Is VMware Carbon Black Developer Day?

VMware Carbon Black Developer Day is an annual virtual event designed to connect intermediate and advanced security developers directly with Carbon Black platform experts. The focus is hands-on and practical: attendees learn advanced API usage, integration patterns, and workflow automation techniques for the Carbon Black security platform.

The 2020 edition took place on Tuesday, May 12, starting at 11 a.m. EST — the day before VMware Carbon Black’s Connect 2020 virtual conference. The event ran for approximately four hours.

Why Developer Day Matters for DevSecOps

A recurring challenge in DevSecOps is integrating security tooling into existing developer and operations workflows without creating friction. Developer Day addresses this directly by teaching engineers how to automate security operations through the Carbon Black API and by showcasing partner integrations that demonstrate real-world implementation patterns.

Sessions are delivered by the VMware Carbon Black developer relations team and by technology partners who have already built production integrations against Carbon Black APIs — giving attendees access to tested, practical knowledge rather than purely theoretical guidance.

Session Highlights: What Was Covered

The 2020 Developer Day agenda covered a range of topics spanning the Carbon Black Cloud platform and its ecosystem:

• Open-source security operations toolkit: How to build an open-source toolkit that leverages Carbon Black’s complete platform API to enable security operations at scale.
• Red Canary integration: Using Red Canary’s suite of tools in combination with Carbon Black to support a variety of security operations use cases.
• Latest platform capability demos: Live demonstrations of recently shipped features across the Carbon Black Cloud platform.
• Carbon Black Cloud Event Forwarder: A getting-started guide for the Event Forwarder, which allows teams to stream endpoint telemetry data to external SIEMs and data pipelines.
• Binary Analysis SDK: An introduction to the Binary Analysis SDK — described as the newest addition to the Carbon Black Cloud developer toolbox at the time — enabling programmatic file and binary analysis.
• VMware Carbon Black EDR + Lastline Defender integration: A demo of a bidirectional integration between Carbon Black EDR (Endpoint Detection and Response) and Lastline Defender, illustrating how two security products can share context in real time.
• Carbon Black Developer Network roadmap: A preview of what was coming next for the Carbon Black developer ecosystem and community.

Key Themes: APIs, Automation, and Integration

Several themes run through the Developer Day agenda that reflect broader trends in DevSecOps practice:

API-First Security

Carbon Black Cloud exposes a comprehensive REST API that allows security teams to query endpoint data, manage policies, and trigger response actions programmatically. Developer Day sessions taught engineers how to leverage these APIs to build custom tooling rather than relying solely on the console UI — a critical capability for teams operating at scale.

Bidirectional Integrations

The VMware Carbon Black EDR and Lastline Defender integration demo highlighted the value of bidirectional data sharing between security products. When an endpoint detection platform and a network threat analysis tool share enriched context in both directions, security analysts benefit from a more complete picture without manually correlating data across separate consoles.

Event Streaming and SIEM Integration

The Carbon Black Cloud Event Forwarder session addressed a common operational requirement: getting endpoint telemetry into centralized logging and SIEM platforms. This kind of event forwarding capability is essential for teams that use tools such as Splunk, Elastic, or cloud-native logging services alongside their endpoint security platform.

Leadership Perspective

Scott Lundgren, CTO of VMware Carbon Black, spoke with MediaOps Managing Editor Charlene O’Hanlon ahead of the event to discuss what attendees could expect from the four-hour program. Lundgren’s involvement underscored the strategic importance VMware Carbon Black placed on its developer community and API ecosystem.

Takeaways for Security Engineers and DevSecOps Teams

Even viewed retrospectively, the Developer Day 2020 agenda offers a useful snapshot of the capabilities and integration patterns that security engineering teams were building around endpoint security platforms in 2020. The focus on open-source tooling, SDKs, event streaming, and bidirectional partner integrations remains highly relevant for teams designing security automation pipelines today.

• Invest in API-driven workflows to reduce manual security operations toil.
• Use event forwarding to centralize telemetry and feed existing SIEM or data lake investments.
• Explore partner integrations before building custom connectors — production-tested integrations save significant engineering time.
• Contribute to and consume open-source security toolkits to accelerate internal tooling development.

For current documentation on the Carbon Black Cloud API and developer resources, refer to the VMware Carbon Black Developer Network.

TechGig and Google Cloud Partner on Cloud DevJam

TechGig, in collaboration with Google Cloud, launched Cloud DevJam — an interactive online upskilling program aimed at helping Indian IT professionals strengthen their cloud computing skills. The initiative was announced in May 2020, during a period when COVID-19 lockdowns made remote, self-paced learning especially relevant for the developer community.

The program was designed with a specific goal: enable working developers to build practical Google Cloud Platform (GCP) skills without leaving home, while also preparing them for formal Google Cloud certification.

What Cloud DevJam Covers

Cloud DevJam covers a broad range of Google Cloud Platform skill areas, including:

• Core infrastructure — foundational GCP services, compute, networking, and storage
• Data and machine learning — working with BigQuery, AI/ML APIs, and data pipelines
• Application development — building and deploying apps on GCP using services such as App Engine, Cloud Run, and Kubernetes Engine

The curriculum was structured to take participants from foundational knowledge through to more advanced, job-relevant GCP skills.

Program Format: Live Sessions, Labs, and Hackathons

Cloud DevJam is not a passive video course. The program combines several interactive learning formats to keep participants engaged and to validate learning outcomes:

• Live interactive sessions led by Google Cloud subject matter experts
• Multiple choice question (MCQ) tests to assess conceptual understanding
• Hands-on labs for practical, real-environment skill building
• Hackathons and skill tests to apply knowledge under realistic conditions

Participants who complete the program are also given the opportunity to pursue Google Cloud certification, providing a recognized, verifiable credential to add to their professional profile.

Why This Program Was Launched

The rationale behind Cloud DevJam reflects both the immediate context of the 2020 pandemic and longer-term workforce trends in India’s IT sector.

“The COVID-19 outbreak, and the social lockdown, has made it critically important for everyone to remain updated with the newer technologies. Today, the digital frontier — led by cloud-based technologies — is driving most initiatives in all the sectors. Cloud DevJam has been curated to help the developers learn and understand the fundamentals of Google Cloud and advance their skills in the process.”

— Sanjay Goyal, Business Head, TimesJobs and TechGig

“The Cloud DevJam is unique because it’s been conceptualized to enable developers to build their knowledge while at home, and companies will need to call on their skills in the immediate and long term to ensure business agility, resilience, and overall competitiveness.”

— Karan Bajwa, Managing Director, Google Cloud India

Context: Cloud Skills and the Indian IT Workforce

India has one of the largest concentrations of IT professionals in the world, and demand for cloud-certified engineers has grown significantly as enterprises across sectors accelerate their migration to cloud infrastructure. Programs like Cloud DevJam address a real skills gap: many developers have strong software engineering fundamentals but limited hands-on experience with managed cloud services, distributed data platforms, and cloud-native application patterns.

Structured programs that combine live expert instruction with lab environments and recognized certification paths offer a more effective upskilling route than self-directed study alone — particularly for professionals who need to demonstrate cloud competency to current or prospective employers.

Google Cloud Certification Pathway

One of the distinguishing features of Cloud DevJam is the direct link to Google Cloud’s official certification program. Google Cloud offers a tiered certification track, from foundational to professional and specialty levels. Relevant certifications for developers participating in a program like Cloud DevJam would typically include:

• Google Cloud Digital Leader (foundational)
• Associate Cloud Engineer
• Professional Cloud Developer
• Professional Data Engineer
• Professional Machine Learning Engineer

Earning a Google Cloud certification provides independently validated proof of skill that is recognized by employers across cloud-first and cloud-migrating organizations globally.

Where to Learn More

For current upskilling opportunities on Google Cloud, visit the Google Cloud Training portal. TechGig periodically runs similar collaborative programs; check TechGig.com for active challenges and learning initiatives.

A preview of an updated Azure VMware Solution was announced this week, marking another step in Microsoft and VMware’s joint effort to run VMware virtualization technology on the Azure cloud.

Azure VMware Solution is a first-party Azure service that’s built and supported by Microsoft and endorsed by VMware. The service is designed to let organizations run VMware workloads natively on Azure.

Though VMware now describes its relationship with Microsoft as “a long-standing partnership and a shared heritage in supporting our customers,” the development of the Azure VMware Solution has been fraught. A few years ago, VMware ripped a Microsoft “bare-metal” VMware stack that ran on Azure hardware, saying the effort was “neither certified nor supported by VMware.”

Adding to the friction between the two companies, VMware has also partnered with Microsoft rival Amazon Web Services (AWS) for a “VMware Cloud on AWS” solution.

Tensions may have cooled since then, however. The first iteration of Azure VMware Solution emerged just about a year ago. This week’s updated solution preview lets enterprises run their VMware technology — including VMware vSphere, HCX, NSX-T and vSAN — on Azure. Organizations can now completely migrate their existing on-premises VMware applications to Azure without the cost, effort or risk associated with needing to re-architect applications or retool operations, Microsoft said in its announcement.

“You can provision a full VMware Cloud Foundation environment on Azure and gain compute and storage elasticity as your business needs change,” according to the announcement. “Azure VMware Solution is VMware Cloud Verified, giving customers confidence they’re using the complete set of VMware capabilities, with consistency, performance, and interoperability for their VMware workloads.”

Microsoft said popular scenarios for the solution include:

Datacenter footprint reduction, consolidation and retirement: “Reduce your datacenter footprint with a one-time re-deployment of your VMware-based virtual machines. Lift and shift any vSphere-based workloads to Azure in a non-disruptive, automated, scalable, and highly available way without changing the underlying vSphere hypervisor.”
Datacenter expansion based on demand: “Seamlessly and elastically expand or augment datacenter capacity — and adjust your costs — on demand for short periods of time.”
Disaster recovery and business continuity: “Use a VMware stack deployed in Azure as a primary or secondary on-demand disaster recovery site for on-premises datacenter infrastructure.”
Application modernization: “Tap into the Azure ecosystem to modernize your applications without having to rebuild your VMware-based environments.”
For now, the Azure VMware Solution preview is available in U.S. East and West Europe Azure regions, with general availability — and more regions — expected in the second half of the year.

Containers and Cloud: A Natural Partnership

Containers have become a cornerstone of modern application development and deployment. Their value proposition is well understood: they package an application and its dependencies into a portable unit that can run consistently across development laptops, on-premises servers, and multiple cloud environments. This portability is especially important as enterprises pursue hybrid and multi-cloud strategies, moving workloads between providers or between cloud and on-premises infrastructure without costly re-engineering.

But building and operating a mature containerized environment at scale is not trivial. It requires specialized expertise in orchestration, networking, storage, security, and CI/CD pipelines. That skills gap has created real friction for organizations that want the benefits of containers without investing heavily in building internal platform teams from scratch.

What Is Containers-as-a-Service (CaaS)?

Containers-as-a-Service (CaaS) is a managed cloud service model that abstracts the underlying infrastructure required to run containers. Rather than provisioning and maintaining the orchestration layer — including the control plane, node management, networking, and storage — organizations consume these capabilities as a managed service from a cloud provider or platform vendor.

CaaS sits between Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS). Users retain significant control over how their containers are configured and deployed, but they offload operational responsibility for the underlying container runtime and orchestration platform. In practice, this usually means a managed Kubernetes service, a managed Docker environment, or both.

Common CaaS offerings from major cloud providers include:

• AWS Elastic Container Service (ECS) and Elastic Kubernetes Service (EKS)
• Azure Kubernetes Service (AKS)
• Google Kubernetes Engine (GKE)

CaaS Adoption Is Rising Fast

According to the Flexera 2020 State of the Cloud Report, CaaS is no longer a niche offering. Among the 750 IT executives surveyed, 53 percent reported using CaaS — placing it as the second-ranked PaaS category in use among cloud-driven enterprises, up from sixth place the previous year. Only Database-as-a-Service ranked higher, used by 62 percent of respondents.

In terms of year-over-year growth, CaaS ranked second among the fastest-growing cloud technologies, with 17 percent annual growth — just behind IoT services at 21 percent and level with machine learning and AI services.

Adoption of specific CaaS products reflects this trend:

• AWS ECS/EKS: 54 percent adoption (up from 44 percent the prior year), with another 24 percent planning adoption.
• Azure Container Service: 46 percent adoption (up from 28 percent).
• Google Kubernetes Engine: 24 percent adoption (up from 15 percent).

The survey authors attribute this acceleration to organizations’ growing interest in leveraging containers to speed deployment, scale operations, and increase workload efficiency in the cloud.

Why CaaS Matters: Balancing Speed and Control

One of the key value propositions of CaaS is that it preserves developer and operations control over container configuration while reducing the burden of managing the platform itself. As noted in an overview by Eric Olsson at Scalyr, the evolution toward containers is part of a broader acceleration in software delivery:

“Agile methodologies shortened the development and testing pieces while cloud computing has shortened the deployment piece. Continuous integration (CI) and continuous delivery (CD) further improved the time it takes to get a feature to customers. In addition to these, containers can give you a more powerful and flexible solution. But with all these pieces come additional configuration and complexity.”

Eric Olsson, Scalyr

CaaS helps manage that added complexity by delivering a pre-integrated platform for container orchestration, allowing teams to focus on writing and shipping software rather than maintaining Kubernetes clusters.

Key Challenges Slowing Container Adoption

Despite growing adoption, the Flexera survey identified several significant barriers that organizations still face when working with containers:

• Lack of internal expertise: Cited as a major challenge by 41 percent of respondents, with another 38 percent calling it a moderate challenge. Container orchestration, security, and networking require skills that many teams are still building.
• Migrating traditional applications: 34 percent identified this as a major issue. Containers are optimized for microservices architectures, while many existing enterprise applications are monolithic and were not designed with container portability in mind. Retrofitting these applications requires significant refactoring effort.
• Security concerns: Also cited as a major challenge by 34 percent. Container security encompasses image scanning, runtime protection, secrets management, and network policy — all areas requiring deliberate investment.
• Provider expertise gaps: More than one in four respondents (26 percent) noted that even their service providers lack sufficient expertise in container technology, suggesting that the ecosystem as a whole is still maturing.

The survey authors note that these challenges largely reflect the relative recency of widespread container adoption. As the tooling, training, and managed service options mature, many of these barriers are expected to lower.

Docker and Kubernetes Remain the Foundation

Underlying most containerization efforts are two technologies that have become de facto standards in the industry. According to the Flexera 2020 survey:

• Docker: Used by 65 percent of organizations surveyed, with another 14 percent planning adoption. Docker remains the dominant container runtime and image format.
• Kubernetes: Used by 58 percent of organizations, with 22 percent planning to adopt it. Kubernetes has become the leading container orchestration platform, and most CaaS offerings — including EKS, AKS, and GKE — are built on top of it.

The widespread use of these open-source technologies means that organizations investing in CaaS today are building on a well-supported, vendor-neutral foundation, which reduces lock-in risk compared with proprietary PaaS platforms.

Is CaaS the Right Choice for Your Organization?

CaaS is not a universal solution, but it is a pragmatic one for many organizations. Teams that are beginning their container journey and do not yet have deep Kubernetes expertise can use a managed CaaS offering to get running quickly, then build operational knowledge progressively. Organizations with strong platform engineering teams may prefer more control over their Kubernetes deployment, running self-managed clusters on IaaS infrastructure.

For enterprises running hybrid or multi-cloud workloads, CaaS offerings can also provide a consistent developer experience across environments — particularly when combined with tools like Helm, Terraform, or GitOps workflows that standardize deployments across providers.

The central question is not whether to use containers — at this point, the industry trend is clear — but how much of the operational platform you want to manage yourself versus delegate to a cloud provider. CaaS represents a sensible middle path for most enterprises: enough abstraction to reduce operational burden, enough control to maintain flexibility.

Conclusion

Containers have moved from an advanced practice to a mainstream enterprise requirement, and CaaS is emerging as the practical delivery mechanism for organizations that want container benefits without standing up their own orchestration infrastructure. Adoption data from the Flexera 2020 State of the Cloud Report confirms that CaaS is growing rapidly, driven by real demand across enterprises of all sizes. Challenges around expertise and application migration remain, but the managed service model is helping lower the barrier to entry — and that trend is likely to continue as Docker, Kubernetes, and the broader cloud-native ecosystem continue to mature.

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.

The Advertising Dependency Problem

Google entered 2020 with an enviable revenue base, but also a significant structural vulnerability: an overwhelming dependence on advertising. In Q1 2020, Google generated $33.8 billion in advertising revenue, representing approximately 82% of its $41.2 billion in total quarterly revenue. That share had already declined slightly from 84.5% in Q1 2019, but advertising still dominated the business.

CFO Ruth Porat acknowledged during the Q1 2020 earnings call that advertising results are highly correlated with macroeconomic conditions. She described “an abrupt decline” in March advertising revenue after strong January and February results—a direct reflection of the economic disruption caused by the COVID-19 pandemic. For a company whose innovation engine depends on stable, predictable cash flows, that volatility represented a serious strategic risk.

Cloud as the Resilient Counterweight

While advertising stumbled, Google Cloud proved notably resilient. Cloud revenue for Q1 2020 reached $2.8 billion—up 52% year-over-year and up approximately 6% from Q4 2019. A strong March performance drove much of that result, directly contrasting the collapse seen in the advertising segment during the same month.

This divergence illustrated a broader industry pattern: enterprise cloud spending tends to be more contractual and less immediately reactive to short-term economic shocks than digital advertising spend. For Google, which had been investing heavily to close the gap with AWS and Microsoft Azure, the pandemic created both urgency and opportunity to accelerate its cloud strategy.

Google’s Three-Pronged Cloud Growth Strategy

1. Continued Cloud Hiring Amid Broader Slowdowns

Even as Google outlined plans to slow overall headcount growth in the second half of 2020, Porat reiterated the company’s commitment to continued cloud hiring. This mirrored an approach taken by Microsoft, which reportedly exempted its Azure cloud division from a broader hiring freeze instituted in April 2020. The message was clear: cloud talent acquisition was non-negotiable, even as other parts of the business tightened spending.

2. Accelerating G Suite Adoption

Google moved quickly to leverage the remote-work surge by making Google Meet—part of its G Suite cloud productivity suite—available for free with no time limit. This was part of a broader push to grow G Suite’s enterprise footprint during the pandemic, as organizations of all types adapted to distributed work.

The results were significant:

• G Suite enterprise subscribers surpassed 6 million paying customers in March 2020, up from 5 million in February 2019, according to reporting by CNBC.
• Google Classroom doubled its active user base over the course of March 2020, reaching 100 million active users.
• Google Meet saw 25 times more daily users in April 2020 compared to the start of the year.

These growth figures underscored the role pandemic-driven adoption played in validating Google’s productivity cloud investments.

3. Aggressive Google Cloud Platform Acquisitions

Rather than pulling back on M&A activity, Google reportedly continued pursuing strategic acquisitions to strengthen Google Cloud Platform (GCP). In late April 2020, Axios reported that Google was in talks to acquire D2iQ—a company focused on Kubernetes-based cloud infrastructure and enterprise container management—for as much as $775 million. While the deal’s outcome was not confirmed in the original reporting, the disclosed negotiations signaled that Google’s acquisition appetite for cloud-native technology remained strong even during a period of broader financial caution.

GCP competes directly with Amazon Web Services and Microsoft Azure by offering cloud compute, storage, machine learning, and data analytics services on a subscription basis. Acquiring specialized cloud software companies is a proven mechanism for rapidly adding differentiated capabilities to such platforms.

The Bigger Picture: Diversification as a Survival Strategy

Google’s “Other Bets” segment—which houses long-term, capital-intensive ventures like Waymo (autonomous vehicles), Wing (drone delivery), and Verily (life sciences)—recorded a net loss of over $1.1 billion in Q1 2020 alone. These businesses are not expected to generate near-term returns; they depend on Alphabet’s core business generating sufficient surplus capital to fund speculative, long-horizon R&D.

That model works when advertising revenue is stable and growing. It becomes fragile when advertising is exposed to macroeconomic shocks—exactly the scenario that materialized in early 2020. A more diversified revenue base, anchored in recurring cloud subscriptions rather than cyclical ad spend, would provide Google with greater financial stability to sustain this innovation-through-subsidiaries strategy across economic cycles.

Key Takeaways for DevOps and Cloud Practitioners

• Enterprise cloud spending proved more recession-resistant than digital advertising during the early COVID-19 economic shock—a data point relevant to budget justification conversations in engineering organizations.
• Google’s investment in Kubernetes ecosystem acquisitions (such as the reported D2iQ talks) signals continued platform-level commitment to container orchestration as a core GCP differentiator.
• G Suite’s rapid growth during remote-work adoption demonstrated the compounding value of bundled productivity-plus-infrastructure cloud offerings for enterprises.
• Selective hiring protection for cloud teams—even during company-wide slowdowns—reflects how organizations prioritize strategic growth areas when economic pressure forces trade-offs.

Original reporting by Business Insider Intelligence, based on Google/Alphabet Q1 2020 earnings disclosures and industry analysis. Financial figures cited reflect Q1 2020 results as reported at the time.

Overview

In the early weeks of the COVID-19 pandemic, Google Cloud announced a wide-ranging set of programs aimed at helping individuals, businesses, healthcare providers, government agencies, and academic researchers navigate the crisis. The initiatives spanned cloud infrastructure support, product access, AI tooling, and direct financial commitments in the form of cloud credits.

Google Cloud CEO Thomas Kurian summarized the company’s position in a blog post at the time: “We’re all in the midst of an extraordinary moment — not only for our teams, colleagues, and customers, but for the world at large. All over the world, businesses and users depend on Google Cloud to help them stay connected and get work done. And we take this responsibility very seriously.”

$20 Million in Cloud Credits for COVID-19 Research

One of the most prominent commitments was a $20 million allocation of cloud-computing credits made available to academic institutions and non-profit research organizations investigating the coronavirus. Alongside the credits, Google Cloud offered free access to large-scale COVID-19 datasets to accelerate epidemiological and biomedical research.

Additional research-focused efforts included:

• Building tools to help researchers identify potential treatments and therapies
• Assisting hospitals in tracking the spread of the pandemic
• Developing remote patient monitoring capabilities for healthcare systems
• Deploying self-assessment tools for citizens in Spain
• Helping Australia build an app providing real-time public health information and guidance
• Supporting the Peruvian judiciary in continuing operations using Google Meet

AI-Powered Solutions for Government Agencies and Hospitals

With government call centers and health agencies overwhelmed by citizen inquiries, Google Cloud worked with partners to deploy AI-based chat and voice automation to help callers get critical information more quickly, reducing wait times and freeing up human agents for complex cases.

In Oklahoma, Google Cloud partnered to develop a remote patient engagement solution that allowed medical teams to assess and treat at-risk patients without requiring in-person contact — reducing exposure risk for both patients and healthcare workers. The solution was subsequently extended to additional US states.

Supporting Remote Work: A 25x Surge in Google Meet

From January 2020 onward, daily usage of Google Meet increased by approximately 25 times compared to pre-pandemic baselines — a demand spike that Google’s global network infrastructure absorbed without reported service disruptions. Advanced Google Meet features were made available at no charge to Google Workspace (then called G Suite) and G Suite for Education customers worldwide.

Real-world examples of rapid adoption reported at the time include:

• MACIF Group (France): 8,000 employees at the French insurer, already using G Suite for daily work, transitioned to Google Meet for video collaboration — logging approximately 1,300 video meetings per day.
• Breuninger (Germany): The luxury fashion retailer temporarily closed its 11 physical stores and shifted 5,000 employees to online operations. Google Cloud helped get more than 1,100 of those employees set up on G Suite within 48 hours. Breuninger subsequently explored using G Suite to maintain customer engagement.

Education: Connecting Millions of Students and Teachers

Google Cloud’s education-focused efforts during the pandemic were substantial in scale:

• New York City: Google Cloud infrastructure supported the connection of approximately 1.3 million students to Google Classroom for remote learning as schools closed.
• Khan Academy: Google Cloud infrastructure helped the non-profit handle a 2.5x increase in time spent on the platform, a 6x increase in new student and teacher registrations, and a 20x increase in new parent registrations — all within a compressed timeframe.

What This Illustrates About Cloud Infrastructure at Scale

From a DevOps and infrastructure perspective, the COVID-19 period offered a real-world stress test for cloud platforms at a global scale. The ability to absorb 25x demand spikes in video conferencing, rapidly provision workspace tooling for thousands of employees within 48 hours, and support sudden surges in educational platform traffic — all simultaneously — underscored the operational resilience of hyperscale cloud infrastructure.

For engineering teams, the pandemic period also accelerated adoption of several patterns that have since become standard: remote-first collaboration tooling, cloud-native contact center AI, and elastic infrastructure provisioning for unpredictable traffic. The Google Cloud initiatives described here served as early, large-scale public examples of these patterns in production.

Summary

Google Cloud’s COVID-19 response in early 2020 combined direct financial support ($20 million in research credits), infrastructure scaling for remote work and education, AI tooling for overwhelmed public agencies, and rapid deployment projects for enterprises forced to shift to digital operations overnight. The scope of these initiatives reflected both the maturity of Google Cloud’s global infrastructure and the operational demands that a global crisis can place on cloud platforms.

For the full list of initiatives, Thomas Kurian’s original blog post on the Google Cloud blog (published around March–April 2020) provides additional detail.

What Is Cloud AI Platform Pipelines?

Google announced the beta of Cloud AI Platform Pipelines, a managed service designed to help data scientists and ML engineers deploy robust, repeatable machine learning pipelines on Google Cloud. The service adds monitoring, auditing, version tracking, and reproducibility to ML workflows that would otherwise be difficult to operationalize at scale.

The core motivation is familiar to anyone who has moved an ML project from experimentation to production. As Ramesh and Unruh wrote in the original blog post:

When you’re just prototyping a machine learning (ML) model in a notebook, it can seem fairly straightforward. But when you need to start paying attention to the other pieces required to make an ML workflow sustainable and scalable, things become more complex.

Cloud AI Platform Pipelines is Google’s answer to that complexity — and its entry point into the broader practice of MLOps.

MLOps: DevOps Principles Applied to Machine Learning

MLOps (Machine Learning Operations) applies DevOps principles — automation, monitoring, version control, and continuous delivery — to the ML lifecycle. A typical ML workflow subject to MLOps practices covers:

• Data preparation and validation
• Feature engineering and analysis
• Model training and evaluation
• Model deployment and serving
• Ongoing monitoring and retraining

Cloud AI Platform Pipelines is designed to be the orchestration layer that ties these stages together in a repeatable, auditable manner.

Architecture: How It Works

Cloud AI Platform Pipelines runs on a Google Kubernetes Engine (GKE) cluster and is accessible through the Cloud AI Platform dashboard in the Google Cloud Console. The service has two major parts:

• Infrastructure layer: Deploys and runs structured AI workflows integrated with GCP services including BigQuery, Dataflow, AI Platform Training and Serving, and Cloud Functions.
• Pipeline tooling layer: Tools for building, debugging, and sharing pipelines and individual pipeline components.

Workflow Orchestration with Argo

Under the hood, the platform uses Argo, an open-source, container-native workflow engine for orchestrating parallel jobs on Kubernetes. Argo executes each pipeline on individual isolated pods within the GKE cluster. This architecture allows pipeline components to leverage managed Google Cloud services such as Dataflow, AI Platform Training and Prediction, and BigQuery. Pipelines can also include steps that run large-scale GPU and TPU computation directly in the cluster, taking advantage of GKE features like autoscaling and node auto-provisioning.

Automatic Metadata Tracking with ML Metadata (MLMD)

Every pipeline run benefits from automatic metadata tracking via the ML Metadata (MLMD) library. MLMD logs:

• Artifacts consumed and produced at each pipeline step
• Pipeline parameters used during each run
• Lineage linking input and output artifacts across steps

MLMD is included as part of the TFX SDK but can also be used independently in other contexts.

Choosing an SDK: KFP vs. TFX

Users can define their pipelines using one of two SDKs:

Regardless of which SDK is used, the compilation and submission process is the same: the SDK compiles the pipeline definition and submits it to the Pipelines REST API. The REST API server then stores and schedules the pipeline for execution. Google noted in the original blog post that the two SDK experiences were planned to converge over time.

Key Features for Enterprise ML Workloads

According to the announcement, customers using Cloud AI Platform Pipelines receive:

• Push-button installation directly from the Google Cloud Console
• Pipeline versioning to track changes to pipeline definitions over time
• Automatic metadata tracking of artifacts and executions via MLMD
• Cloud Logging integration and built-in visualization tools
• Seamless integration with BigQuery, Dataflow, AI Platform Training and Serving, Cloud Functions, and other GCP managed services
• Prebuilt pipeline components for common ML workflow steps, plus support for custom components

Portability: The Kubeflow Advantage

Because Cloud AI Platform Pipelines is built on Kubeflow Pipelines — which is open-source and runs on standard Kubernetes — workloads are not strictly locked into Google Cloud. A commenter on a Hacker News thread discussing the announcement noted:

Cloud AI Platform Pipelines appear to use Kubeflow Pipelines on the backend, which is open-source and runs on Kubernetes. The Kubeflow team has invested a lot of time on making it simple to deploy across a variety of public clouds, such as AWS and Azure. If Google were to kill it, you could easily run it on any other hosted Kubernetes service.

This is a meaningful consideration for teams evaluating cloud vendor lock-in risk in their ML infrastructure decisions.

Planned Features at Beta Launch

At the time of the beta announcement, Google outlined the following features on its near-term roadmap:

• Easy cluster upgrades
• Additional templates for authoring ML workflows
• Simplified UI-based setup of off-cluster storage for backend data
• Workload Identity support for transparent, credential-free access to GCP services
• Multi-user isolation — allowing each user to control access to their own pipelines and resources within a shared cluster

Context: Google’s Broader MLaaS Strategy

Cloud AI Platform Pipelines is part of Google’s broader Machine Learning as a Service (MLaaS) portfolio, which includes Cloud AutoML, Kubeflow, and AI Platform Prediction. The service positions Google more directly against competing managed ML platforms such as Amazon SageMaker and Azure Machine Learning.

For DevOps and platform engineering teams tasked with supporting data science organizations, Cloud AI Platform Pipelines represents a significant step toward treating ML workflows with the same operational rigor as software delivery pipelines — with versioning, auditability, and reproducibility built in from the start.

Further Reading

For implementation details, refer to the official Google Cloud AI Platform Pipelines documentation and the Kubeflow Pipelines project on GitHub. The original announcement was covered in depth by InfoQ.

What Is Cloud AI Platform Pipelines?

Google Cloud Platform (GCP) announced the beta launch of Cloud AI Platform Pipelines, a managed product for automating and orchestrating end-to-end machine learning (ML) workflows. The product is built on two open-source technologies: TensorFlow Extended (TFX) and Kubeflow Pipelines (KFP), and runs on a Google Kubernetes Engine (GKE) cluster.

The core problem Cloud AI Platform Pipelines addresses is the complexity of managing the full ML lifecycle — from ingesting raw data, through model training and evaluation, to serving predictions in production — in a repeatable, auditable way.

Key Features

• Repeatable ML pipelines: Define pipeline steps once and re-execute them consistently across runs.
• Artifact and lineage tracking: Track the history, versions, and provenance of data artifacts produced at each pipeline stage using ML Metadata (MLMD).
• Monitoring and auditing: Built-in observability for pipeline runs and model versions.
• GCP service integration: Native connectors to BigQuery, Dataflow, and other GCP services.
• Managed infrastructure: Google manages the underlying GKE cluster, reducing operational overhead for teams.
• Dual SDK support: Teams can use the higher-level TFX SDK or the lower-level KFP SDK; Google has stated plans to merge both into a single TFX SDK.

Architecture Overview

Understanding how Cloud AI Platform Pipelines works requires understanding its two foundational layers:

TensorFlow Extended (TFX)

TFX is a high-level abstraction layer for defining ML pipelines. The central concept is a pipeline — an ordered series of data transformation steps called pipeline components. Data passed between components are called artifacts. TFX also defines and manages an ML Metadata (MLMD) store, enabling version tracking and lineage for both pipeline runs and the artifacts they produce.

TFX was first documented publicly in a paper Google presented at KDD 2017, which described the internal ML platform Google built to cover all phases of the ML process: data analysis, transformation, training, evaluation, and production inference. The original execution engine was Apache Beam — itself derived from Google’s internal Flume system and the technology underpinning Google Cloud Dataflow. TFX continues to use Beam for defining data-parallel operations, and now also supports Kubeflow Pipelines and Apache Airflow as orchestration engines.

Kubeflow Pipelines (KFP)

KFP acts as the orchestrator. It schedules and executes each TFX pipeline component as a pod on the GKE cluster, coordinating execution order and passing artifacts between steps. Google open-sourced Kubeflow in 2018 as an ML-specific platform for Kubernetes. Spotify later adopted Kubeflow as their standard ML platform and open-sourced their Terraform templates for cluster provisioning.

Relationship to Other GCP Orchestration Tools

Before Cloud AI Platform Pipelines, Google had recommended Apache Airflow (and its managed GCP counterpart, Cloud Composer) for orchestrating ML workflows. Airflow and Cloud Composer are general-purpose workflow tools, not ML-specific. Cloud AI Platform Pipelines narrows the focus: it is designed specifically for ML pipelines and abstracts away cluster management entirely, removing a significant operational burden from data engineering and MLOps teams.

The Broader MLOps Ecosystem Context

The launch touches on a broader competitive dynamic in the ML infrastructure space. As one commenter noted in a Hacker News discussion on the announcement:

The battle of ML pipeline ecosystems is the engine — not so much the API. It had been Beam vs [Apache] Spark. Now, Google are changing tack and saying it is TensorFlow on Kubernetes with distributed processing vs Spark-based ML pipelines.

This framing is useful for teams evaluating ML platforms. Cloud AI Platform Pipelines represents Google’s bet on a Kubernetes-native, TensorFlow-centric execution model, in contrast to Spark-based ML pipeline approaches favored in other ecosystems (such as those built on Databricks or Amazon EMR).

What This Means for MLOps Engineers

• Reduced infrastructure overhead: Google manages the GKE cluster, so teams can focus on pipeline logic rather than cluster operations.
• SDK choice matters short-term: The TFX SDK is higher-level and more opinionated; the KFP SDK offers more flexibility. Google’s plan to merge them means teams should monitor SDK deprecation announcements.
• Kubeflow familiarity is transferable: Teams already working with open-source Kubeflow will find the concepts familiar; the managed offering primarily removes cluster setup and maintenance steps.
• Lineage and reproducibility are first-class: The MLMD integration makes this a stronger choice than generic workflow tools for teams that need audit trails for model versions and training data.
• GCP lock-in considerations: Deep integration with BigQuery and Dataflow increases productivity on GCP but should be weighed against multi-cloud or portability requirements.

Summary

Cloud AI Platform Pipelines (announced in beta in early 2020) brought a fully managed, ML-specific pipeline platform to GCP, combining the abstraction of TFX with the Kubernetes-native orchestration of Kubeflow Pipelines. For teams already invested in the GCP and TensorFlow ecosystem, it offered a significant reduction in operational complexity while providing enterprise-grade lineage tracking, reproducibility, and monitoring out of the box.