Remote work went from an occasional perk to a widespread operational requirement almost overnight. While many technology organizations already had some work-from-home policies in place before 2020, the COVID-19 pandemic forced a full-scale, unplanned shift that exposed gaps in tooling, process, and team communication across the entire software delivery lifecycle.

For DevOps and development teams specifically, the impact has been significant — and not entirely negative. Constraints have driven innovation in areas that were previously handled through physical proximity and informal collaboration. Below we explore the key ways remote work has reshaped DevOps practice and what the longer-term implications look like.

New Trends Emerging in DevOps Under Remote Conditions

Revisiting Mature DevOps Programs: The Push Toward DevOps 2.0

Organizations that adopted cloud-native DevOps practices several years ago are discovering that those implementations need to be revisited. Standards, tooling, and security expectations have evolved considerably since the early wave of cloud-native adoption. When remote work removed the informal, in-person coordination that many teams relied on, gaps in automation and process maturity became visible.

This has prompted a wave of what some practitioners are calling DevOps 2.0 — a deliberate re-evaluation and modernization of existing DevOps programs. For teams that went cloud-native four or five years ago, this typically involves:

• Re-platforming: Moving workloads to more current infrastructure or container orchestration approaches that better support distributed teams.
• Re-defining pipelines: Updating CI/CD configurations to reduce manual handoffs that previously depended on physical presence or informal desk-side conversations.
• Re-developing internal tooling: Replacing bespoke scripts and tribal-knowledge processes with documented, automated, reproducible workflows.

The underlying driver is straightforward: a DevOps program designed around open-plan offices, co-located teams, and impromptu whiteboard sessions needs structural changes to function well when team members are geographically distributed.

DevOps for Firmware: A Particularly Difficult Remote Work Problem

Software-only teams can move most of their workflow online with relatively little friction. Firmware development teams face a harder problem: the work involves physical hardware. Applying DevOps principles — continuous integration, automated testing, and continuous delivery — to firmware requires bridging the gap between the software pipeline and real devices.

In a co-located environment, the traditional process is straightforward: a developer flashes a new firmware build onto a device, passes it to a QA engineer who validates it, and the cycle continues with everyone in the same room. Remote work breaks that physical handoff entirely.

Several challenges emerge in a distributed firmware development context:

• A firmware developer may take a device home, but may not be the person who normally handles flashing or physical provisioning.
• QA engineers and beta testers working remotely need access to devices running the latest builds, including bug fixes and new features.
• Hardware-in-the-loop testing that previously happened on a shared bench now needs to be reproducible without physical co-location.

The practical response has been increased adoption of Over-the-Air (OTA) firmware delivery mechanisms, which allow updated firmware builds to be pushed to development and test devices remotely. When combined with a properly automated CI/CD pipeline, OTA delivery enables QA engineers and beta testers to receive new builds without requiring anyone to physically touch the device. This is not a new technology, but remote work accelerated its adoption as a first-class part of the firmware development workflow rather than a production-only concern.

Collaboration and Communication: What Remote Work Changed

One of the less-discussed effects of full-time remote work on DevOps teams is the change in communication overhead. In an office, many coordination tasks happen informally — a quick question across a desk, a two-minute whiteboard sketch, a hallway conversation that prevents a misunderstanding from becoming an incident. Remotely, every one of those interactions requires a deliberate action: opening a chat message, scheduling a video call, or writing up a comment in a ticket.

This has two observable effects on DevOps teams:

• Increased reliance on documentation and asynchronous communication: Teams that previously operated on shared context and informal knowledge transfer have had to invest in wikis, runbooks, architecture decision records (ADRs), and more detailed pull request descriptions.
• Meeting fatigue: The volume of scheduled video calls tends to increase to compensate for lost informal interaction, creating cognitive load and reducing deep-focus time for engineering work.

The net result is that many DevOps teams have improved their written documentation and process formalization as a direct consequence of remote work — improvements that will benefit future team members regardless of where they sit.

Will Remote Work Become Permanent for DevOps Teams?

The widespread shift to remote work has demonstrated that most software development and DevOps work can be performed productively outside of a traditional office. Video conferencing, cloud-based development environments, shared CI/CD platforms, and chat tools have made distributed engineering teams viable at scale.

However, the evidence also suggests that most engineers do not want a fully remote arrangement indefinitely. Common reasons cited for wanting at least some in-person time include:

• The social dimension of working alongside colleagues.
• Faster resolution of complex, ambiguous problems through in-person whiteboarding and discussion.
• Clearer boundaries between work and home life when commuting to a separate location.
• Reduced video call fatigue by allowing quick, informal in-person exchanges.

The most likely long-term outcome for many DevOps and software engineering teams is a hybrid model: a defined number of in-office days per week combined with the flexibility to work remotely the remainder of the time. This approach attempts to capture the productivity and autonomy benefits of remote work while preserving the collaboration and social advantages of physical presence.

Lasting Process Improvements Driven by Remote Work

Regardless of where teams ultimately land on the remote versus in-office spectrum, several process improvements triggered by the forced remote work period are likely to persist:

• Greater automation of manual handoffs: Steps in deployment pipelines that relied on physical presence or informal coordination have been automated, reducing toil and increasing reliability.
• Improved asynchronous communication practices: Better written documentation, clearer ticket descriptions, and more structured code review processes benefit distributed and co-located teams alike.
• Expanded OTA and remote provisioning capabilities: Firmware and embedded teams that built remote delivery infrastructure out of necessity now have capabilities that improve their overall development velocity.
• More inclusive meeting practices: Teams accustomed to running effective remote meetings tend to run better hybrid meetings, reducing the disadvantage for participants who dial in from other locations.

Key Takeaways for DevOps Teams

The shift to remote work was disruptive, but it served as a forcing function for DevOps maturity in many organizations. Teams that invested in automation, documentation, and remote-friendly tooling came through the transition in better shape than those that relied heavily on co-location and informal process.

• Audit your CI/CD pipeline for steps that still depend on manual, location-dependent actions and automate them.
• If your cloud-native DevOps implementation is several years old, treat it as a candidate for modernization — tooling and best practices have moved on.
• For firmware teams, evaluate OTA delivery infrastructure as a standard part of your development pipeline, not just a production deployment concern.
• Invest in written process documentation now; it pays dividends whether your team is remote, hybrid, or fully co-located.

The future of work for engineering teams remains in flux, but the teams best positioned to adapt are those that treat process resilience and automation as core engineering values — not optional extras.

The Core Problem: A Failure to Communicate

If DevSecOps is not gaining traction in your organization, the root cause is usually not a tooling gap—it is a communication gap. Development, security, and operations teams have historically worked in silos, each convinced the others do not understand their constraints or priorities. The result is friction, finger-pointing, and security treated as a late-stage gate rather than a shared responsibility.

DevSecOps addresses this by integrating security into every phase of the software development life cycle (SDLC). But integration requires collaboration, and collaboration requires a cultural shift. That shift does not happen by mandate—it happens through enablement, training, and structural changes to how teams work together.

Why DevSecOps Still Struggles in Many Organizations

DevSecOps has been an active area of practice for several years, yet many organizations still treat security as an afterthought bolted onto the end of a CI/CD pipeline. Several structural factors contribute to this:

• Team isolation: Development, security, and operations teams often have separate reporting lines, separate toolchains, and separate incentives.
• Security staffing ratios: Security teams are significantly outnumbered. Industry estimates suggest that for every 100 developers in a typical DevOps environment, there may be roughly 10 operations staff and as few as one security professional—making it structurally impossible for security to review everything.
• Late-stage security reviews: Finding a vulnerability during a pre-release security scan is far more expensive to remediate than catching it at the code-writing stage. Rework costs increase significantly the later a defect is discovered in the SDLC.
• Language barriers: Security professionals speak in terms of threat models and CVEs; developers speak in terms of features and deadlines. Without a shared vocabulary, neither side communicates effectively.

Two Tiers of Security Training to Accelerate DevSecOps Adoption

One of the most practical approaches to closing the communication and capability gap is a two-tier security training model: baseline secure coding training for all developers, and a deeper security champions program for a motivated subset of those developers.

Tier 1: Baseline Secure Coding Training for All Developers

The goal of baseline training is not to turn every developer into a security engineer. It is to give developers enough security awareness that they make fewer critical mistakes during day-to-day coding. Any developer who cares about code quality should find this framing compelling: security is a dimension of quality, not a separate discipline.

Good starting points for curriculum include publicly available, well-maintained references:

• OWASP Top 10: The Open Web Application Security Project’s ranked list of the most critical web application security risks. Updated periodically, it covers issues such as injection, broken authentication, and security misconfiguration.
• CWE Top 25: MITRE’s list of the most dangerous software weaknesses, useful for understanding vulnerability classes at the code level.

Core topics that baseline training should cover include:

• Injection attacks (SQL, command, LDAP)
• Authentication, authorization, and access control failures
• Sensitive data exposure and proper handling
• XML External Entity (XXE) processing risks
• Security misconfiguration
• Cross-Site Scripting (XSS)
• Insecure deserialization
• Insufficient logging and monitoring
• Use of components with known vulnerabilities

Training formats that tend to work well in engineering cultures include hands-on labs, capture-the-flag (CTF) exercises, and integrating security scenarios into existing code review workflows—rather than passive slide-deck presentations.

Tier 2: Security Champions Program

A security champions program identifies a small number of developers within each team who receive deeper security training and serve as the primary security liaison between their development team and the central security team. The concept is grounded in a straightforward insight: a peer is more effective at communicating security concepts to developers than an outsider.

Key design principles for an effective security champions program:

• Volunteer-based: Security champions should self-select based on genuine interest in security. Conscripting reluctant participants undermines the program’s credibility and the champion’s effectiveness.
• Career development framing: Position the role as a professional growth opportunity. Security knowledge is increasingly valued, and developers who build it become more marketable.
• Structured training and support: Champions need ongoing education—not just a one-time course. This might include access to advanced training, regular syncs with the security team, and participation in threat modeling sessions.
• Defined responsibilities: Champions should have a clear remit, such as conducting first-pass security reviews of pull requests, running secure coding workshops for their team, or triaging security scanner output.
• Recognition: Acknowledge champions’ contributions publicly within the organization to reinforce the value of the role.

Given typical staffing ratios, even one engaged security champion per development team can meaningfully extend the reach of a small central security team.

Shifting Left: Building Security Into the SDLC from the Start

Training initiatives are most effective when paired with process changes that embed security earlier in the development workflow—a practice commonly called “shifting left.”

Practical ways to shift security left in a CI/CD pipeline include:

• Static Application Security Testing (SAST): Integrate SAST tools into the IDE or as a pre-commit hook so developers receive feedback on vulnerable code patterns before a pull request is even opened.
• Software Composition Analysis (SCA): Automatically scan dependencies for known vulnerabilities as part of the build process.
• Threat modeling during design: Involve security champions or the security team in architecture and design reviews, not just post-implementation audits.
• Security in definition of done: Add security acceptance criteria to user stories and sprint definitions so security is a standard part of the completion checklist.
• Automated security gates in CI/CD: Configure pipelines to fail builds that introduce high-severity vulnerabilities, creating an immediate feedback loop.

When developers catch and fix security issues at the point of introduction, the number of vulnerabilities that escalate to the security team drops substantially. This reduces the single largest source of conflict between development and security teams: the back-and-forth cycle of security rejecting a release and sending fixes back to developers under deadline pressure.

The Cultural Shift Is the Hard Part

Tools and training are enablers, but the underlying challenge is cultural. DevSecOps works when development, security, and operations are not treated as separate organizational units with competing priorities, but as different specializations within a unified team sharing a single goal: delivering secure, high-quality software efficiently.

Practically, this means:

• Security metrics should be visible to the whole team, not just the security function.
• Post-incident reviews should involve developers and operations, not just security responders.
• Security should be present in sprint planning and backlog grooming conversations, not just at release gates.
• Leadership should recognize and reward security contributions from developers, not only feature delivery.

The principle that guides this entire approach is worth stating plainly: make the secure way the easier way. When developers have the knowledge, the tools, the peer support, and the process scaffolding to write secure code without significant extra effort, security becomes a natural output of good engineering rather than an obstacle to it.

Summary

Championing security in DevOps is less about buying the right scanner and more about changing how teams think and communicate. A two-tier training approach—baseline secure coding education for all developers combined with a well-structured security champions program—gives organizations a practical path toward DevSecOps maturity. Pair that with left-shifted security tooling in the CI/CD pipeline and a deliberate cultural commitment to shared ownership of security, and the result is faster delivery of software that is also genuinely more secure.

What Is Contour?

Contour is an open-source Kubernetes ingress controller that routes external traffic to applications running inside a cluster. It is simple to deploy, highly scalable, and purpose-built for the single task of ingress — without the complexity of a full service mesh.

Under the hood, Contour deploys Envoy as a reverse proxy and load balancer, and communicates with it using the Envoy xDS API for fully dynamic configuration updates. This means you can change routing rules without restarting the proxy — a critical capability in production environments.

CNCF Incubation: A Significant Milestone

Originally created in late 2017 by engineers at Heptio, Contour reached version 1.0 in late 2019. By the time of this announcement, it had grown to a community of 600+ Slack members, 300+ contributors, 90+ committers, and five maintainers. Production adopters included enterprises such as Adobe, Kinvolk, Kintone, PhishLabs, and Replicated.

Based on that proven production usage and community maturity, the Cloud Native Computing Foundation (CNCF) accepted Contour directly as an incubating project, bypassing the sandbox stage. Incubation status signals that a project has demonstrated sustainable governance, a healthy contributor base, and alignment with the broader cloud-native ecosystem.

For users and organizations evaluating Contour, CNCF incubation provides an important assurance: the project operates under vendor-neutral governance, meaning no single company controls its roadmap. Any contributor can help shape the project’s direction.

Why Contour? A Focused Approach to Kubernetes Ingress

Kubernetes offers many ways to handle ingress traffic, including service meshes such as Istio or Linkerd. However, deploying a service mesh to solve a pure ingress problem introduces significant operational overhead — additional control plane components, sidecars on every pod, and a steep learning curve.

Contour’s design philosophy is deliberate narrowness: do one thing and do it well. Key capabilities include:

• Dynamic configuration updates: Route changes propagate to Envoy without downtime or restarts.
• Multi-team cluster support: Designed with multitenancy in mind, enabling different teams to manage their own ingress rules safely within a shared cluster.
• Advanced load balancing: Leverages Envoy’s rich set of load balancing algorithms and health-checking strategies.
• Security-first design: TLS termination, certificate management integration, and isolation between tenants are first-class concerns.
• Service mesh compatible: Contour can operate alongside a service mesh if your architecture requires it, but does not require one.

This focused scope makes Contour an approachable on-ramp for teams that need reliable ingress today and want room to grow into more sophisticated routing patterns over time.

How Contour Works

Contour introduces a custom resource called HTTPProxy (formerly IngressRoute), which extends the standard Kubernetes Ingress object with richer capabilities — including delegation of routing authority between namespaces, which is critical for safe multi-team deployments.

The architecture has two main components:

1. Contour (control plane): Watches Kubernetes API objects (Ingress, HTTPProxy, Services, Endpoints) and translates them into Envoy configuration via the xDS gRPC API.
2. Envoy (data plane): Receives configuration from Contour and handles all actual traffic forwarding, TLS termination, and load balancing.

Because the control plane and data plane are separated, each can be scaled and updated independently, improving resilience.

Roadmap Highlights

At the time of the CNCF incubation announcement, the Contour team outlined several near-term priorities driven by community demand:

• External authentication support: A long-requested feature allowing Contour to integrate with external identity and access management systems.
• Expanded Envoy configurability: Exposing more of Envoy’s configuration surface through Contour’s API objects.
• Rate limiting support: Protecting upstream services from traffic spikes and abuse.
• Official Helm chart: Simplifying installation and upgrades via Helm.
• UDP support exploration: Extending Contour beyond HTTP Layer 7 to support protocols like VoIP and telco applications that rely on UDP.

The team also expressed intent to contribute learnings from Contour back to the broader Kubernetes community — particularly around the next generation of Kubernetes Gateway API, which aims to standardize and extend how traffic routing is expressed across the ecosystem.

Getting Started with Contour

Contour can be deployed to any Kubernetes cluster. The quickest path is using the official manifests or Helm chart (see the project’s documentation for current instructions). A minimal deployment provisions an Envoy DaemonSet or Deployment and the Contour control plane, exposed via a Kubernetes LoadBalancer service.

Once running, you define routing rules using the standard Ingress resource or the more powerful HTTPProxy custom resource. For example, a basic HTTPProxy routing all traffic for example.com to a backend service looks like this:

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: example-proxy
  namespace: default
spec:
  virtualhost:
    fqdn: example.com
  routes:
    - conditions:
        - prefix: /
      services:
        - name: my-service
          port: 80

Community and Contributing

The Contour project maintains several channels for community engagement:

• Slack: The #contour channel in the Kubernetes Slack workspace is the primary real-time discussion forum.
• Weekly community meetings: Held on Tuesdays and recorded for those who cannot attend live.
• Mailing list: For announcements, design discussions, and longer-form feedback.
• Office hours: Regular sessions where maintainers are available to answer questions or review pull requests in real time.
• Good First Issues: Tagged issues on GitHub for contributors new to the project.

The project follows a monthly release cadence, ensuring that bug fixes, security patches, and new features reach users regularly without long waits between versions.

For official documentation, source code, and contribution guidelines, visit the Contour project website at projectcontour.io.

The Problem: Secrets Leaking into Public Repositories

GitHub is central to modern software development, giving teams a shared platform to collaborate on code and publish open-source projects. But the same openness that makes it powerful also creates a persistent security risk: developers occasionally commit sensitive material — API tokens, database passwords, private keys, and cloud credentials — directly into repositories without realising it.

Once a secret is pushed to a public repository, it can be indexed, cached, or harvested by automated scanners within minutes. Even a brief exposure can result in account takeovers, data breaches, or unauthorised cloud spending. At enterprise scale, where hundreds or thousands of developers are committing code daily, the probability of at least one accidental exposure climbs significantly.

What Is xGitGuard?

Researchers at Comcast developed xGitGuard, an AI-powered tool designed to detect credentials and other private information that has been inadvertently posted to GitHub. The tool was publicly demonstrated during an Arsenal session at the Black Hat USA 2020 virtual conference on August 7, 2020.

According to Bahman Rashidi, senior cybersecurity researcher and system architect at Comcast, the tool is deliberately lean and fast — two properties that matter enormously when scanning a platform as large as GitHub, which hosts more than 30 million repositories.

“xGitGuard is an AI-based tool designed to detect if and when private information is improperly posted on GitHub (such as passwords or credentials). Comcast technologists developed the tool to address a challenge common in software development environments where large numbers of developers are using GitHub on a daily basis.”

— Bahman Rashidi, Comcast, speaking to The Daily Swig

How xGitGuard Works

The core innovation in xGitGuard is its text-processing algorithm, which analyses not just whether a string looks like a secret, but also the surrounding context within a file. This contextual awareness is what allows the tool to achieve a high detection accuracy while keeping false-positive rates low — a key weakness of simpler pattern-matching approaches.

Key Capabilities

• Context-aware detection: The algorithm inspects the text surrounding a candidate secret, not just the token string itself, improving precision.
• Low false-positive rate: By combining machine learning with efficient text processing, xGitGuard reduces noise compared to regex-only tools.
• Enterprise scalability: The tool is architected to operate at the scale of large organisations, where many repositories and contributors must be monitored continuously.
• Smart use of the GitHub Search API: Rather than brute-forcing every repository, xGitGuard introduces a targeted query-generation approach that works within GitHub’s API rate limits while still covering a broad search surface.

“GitHub contains more than 30 million repositories and with API limitations, it is challenging to find secrets in a timely manner. xGitGuard introduces a new search approach that can utilize the existing GitHub search API and review search results at scale.”

— Bahman Rashidi, Comcast

Why Existing Tools Fall Short

Secret-scanning is not a new problem, and several tools — both open-source and commercial — already exist to address it. Common approaches rely on regular expressions to flag strings that match known secret formats (for example, AWS access key prefixes or GitHub personal access token patterns). While effective at catching obvious cases, pure regex matching suffers from two well-known weaknesses:

• High false-positive rates: Placeholder values, test fixtures, and example credentials in documentation frequently match secret patterns without actually being secrets.
• API rate limiting: Naively querying GitHub’s search API at scale quickly exhausts rate limits, making comprehensive scanning slow or impractical.

Comcast’s claim is that xGitGuard’s ML-driven, context-aware approach directly addresses both of these limitations — though independent benchmarks comparing it against alternatives such as truffleHog, gitleaks, or GitHub’s own secret-scanning feature were not published as part of the Black Hat presentation.

Practical Implications for DevOps and Security Teams

For DevOps and platform-security teams, the inadvertent exposure of secrets in source control remains one of the most common and most avoidable classes of security incident. Tools like xGitGuard are most useful as part of a layered defence that also includes:

• Pre-commit hooks that block secrets from being committed in the first place (e.g., git-secrets, detect-secrets).
• CI/CD pipeline scanning that checks each pull request for credential patterns before code is merged.
• Repository-wide periodic scans to catch secrets that slipped through earlier controls — the problem xGitGuard is specifically designed to solve.
• Secrets management platforms (HashiCorp Vault, AWS Secrets Manager, etc.) to eliminate the need to store credentials in code at all.

A continuous scanning tool that monitors an organisation’s GitHub presence for leaked secrets — especially one tuned to minimise alert fatigue through low false-positive rates — fills a genuine gap in the above stack.

Availability

xGitGuard was presented as an open-source tool at Black Hat 2020’s Arsenal track. Readers interested in the tool should search for the Comcast xGitGuard repository on GitHub and consult the project’s own documentation for up-to-date installation and usage instructions, as project status may have changed since the 2020 release.

Summary

xGitGuard represents Comcast’s practical response to a problem every large engineering organisation faces: keeping secrets out of public code repositories when hundreds of developers are pushing code every day. By combining a context-aware ML algorithm with a smarter approach to the GitHub Search API, the tool aims to deliver faster, more accurate detection than traditional pattern-matching solutions — and to do so at enterprise scale.

Overview

Looker, the business intelligence (BI) and analytics platform that became part of Google Cloud, delivered a major feature release addressing three areas critical to enterprise data teams: modern BI capabilities, foundational performance and infrastructure improvements, and updated tooling for data product development. The release includes support for the complete Google Marketing Platform, significant upgrades for application builders, and a generally available Looker Marketplace where customers can access and share data experiences.

“Looker is continuously evolving to meet the unique and ever growing needs of every business in the way that is best for them. Whether we’re providing multiple choices of cloud providers, the ability to customize data experiences, or the unique solutions coming from our deeper integration with Google Cloud, Looker continues to focus on delivering solutions that have maximum impact on the day-to-day business outcomes of our customers.”

Colin Zima, Head of Looker Analytics and Strategy, Google Cloud

Modern BI Features

Several new and revamped BI features make it easier for business users to extract actionable insights from data without requiring deep technical expertise.

Looker Blocks for Google Marketing Platform

Created in partnership with Google experts, these pre-built analytics blocks are designed to provide a shareable, customizable foundation for analyzing Google Marketing Platform advertising and web data. Key characteristics include:

• Interactive data exploration with light machine learning (ML) predictions embedded in views
• Direct links back into Google Marketing Platform to adjust active campaigns
• Pathways for pushing insights back into the platform
• Fully customizable experiences deployable from Looker Marketplace or the Looker Blocks Directory

The following blocks were made available at release:

• Google Analytics 360
• Campaign Manager + Display & Video 360
• Search Ads 360
• Google Ads Block (refreshed version)

Cross-Filtering in Dashboards

Cross-filtering enables users to slice any metric on one dashboard tile by any dimension surfaced in another tile—with a single click. This feature allows business users to self-serve exploratory analysis directly within a dashboard, surfacing patterns and customer insights that are not immediately apparent from a static view. It reduces dependency on analysts for ad hoc data slicing and supports a more iterative approach to data exploration.

Foundational Performance Improvements

This release included several infrastructure-level enhancements designed to reduce query costs, improve response times, and make better use of existing data infrastructure investments:

• Aggregate awareness: Queries are routed to pre-aggregated tables where possible, reducing compute costs and improving query speed.
• Parallel persistent derived table (PDT) builds: Increases the number of PDTs that can be built simultaneously per connection, reducing wait times in environments with complex data models.
• Faster data downloads: Streaming query results are delivered more quickly when exporting data.
• Pooled database connections: Connection pooling reduces query latency by reusing existing database connections rather than establishing new ones for each query.

Developer and Model Tooling Enhancements

Redesigned Integrated Development Environment (IDE)

The Looker IDE received a significant redesign focused on making LookML development workflows more intuitive. Improvements include:

• More advanced controls for model developers
• An object browser that simplifies navigation and enables reuse of available objects
• Single shared repositories that can be used across multiple Looker instances
• Project folders for improved organization and team collaboration

System Administrator Controls

Administrators in large enterprise deployments gained more granular controls, including:

• Visibility into, and control over, system activity and usage patterns
• Improved user and group management tooling
• The ability to merge Looker-based permissions with corporate identity and access management systems

“Data is essential to our mission of delivering an innovative talent acquisition suite that empowers our customers to grow their companies and help people find jobs. The only way this continues to be sustainable and scalable is because Looker provides tools such as the elite systems activity manager that allows us to manage content, improve adoption, and audit user data over time.”

Zach Linder, VP Machine Learning & Data Analytics, Jobvite

Looker Marketplace and the Extension Framework

Looker Marketplace — Generally Available

Looker Marketplace reached general availability with this release. It serves as a central location where teams can access, deploy, and share data experiences—including all Looker Blocks and community-built custom applications. Teams can rapidly deploy third-party or internally developed applications to their own organization, and optionally share them with the broader Looker customer base. The Marketplace hosts all official Looker Blocks, including the COVID-19 Data Block launched earlier in 2020.

Data Dictionary Application

Available via the Marketplace, the Data Dictionary is a purpose-built application developed using Looker’s extension framework. It provides business users with a dedicated UI to locate the fields and metrics they need for analysis, while giving developers the ability to:

• Audit all LookML fields across a project
• Visualize relationships between datasets and Explores
• Identify the most frequently used data sets and flag duplicate Explores

Extension Framework — Generally Available

Originally announced in November as part of Looker 7, the extension framework reached general availability with this release. It allows developers to build fully customized data experiences within Looker and embed those experiences into existing enterprise applications and workflows—without requiring users to leave their primary tools.

“The National Response Portal was developed to help U.S. healthcare organizations, governments and the public to understand and respond to the impact of COVID-19. Looker’s ability to quickly integrate disparate data sources and rapidly iterate on visualizations was essential in our ability to launch the portal in the midst of a crisis. Looker’s unique extension framework gave us the ability to quickly build and integrate disparate data sources.”

Michael Ames, Sr. Director of Healthcare and Life Sciences, SADA (Google Cloud Premier Partner)

Summary

This August 2020 Looker release represents a broad push across the BI and analytics stack: improved self-service capabilities for business users via cross-filtering and Google Marketing Platform blocks, meaningful infrastructure optimizations for data engineering teams, and a more capable and generally available development ecosystem through the IDE redesign, Marketplace, and extension framework. For teams already invested in Google Cloud, the tighter marketing platform integration provides a direct path from raw advertising data to actionable insights without leaving the Looker environment.

Using Work Item Templates

Azure Boards is excellent for tracking work, but if your team creates dozens of similar Work Items each day — each requiring the same description, priority level, or custom field values — that repetition adds up fast. Work Item templates solve this by letting you pre-fill a defined set of fields with saved values.

Creating a Template

1. Open an existing Work Item that already has the field values you want to reuse.
2. Click the ellipsis (…) in the top-right area of the Work Item form.
3. Select Templates → Capture.
4. On the Capture Template page, click Remove unmodified fields to strip out any fields you did not intentionally set. This keeps the template focused and prevents accidental overwrites.
5. Give the template a descriptive name, verify the field-value pairs, and save.

Applying a Template

1. Open a new, blank Work Item of the same type.
2. Click the ellipsis (…) and choose Templates.
3. Select the template you created. All pre-defined fields are populated instantly.

Templates are scoped to a specific Work Item type (Task, Bug, User Story, etc.), so a Task template will not appear when you open a Bug, keeping the list clean and relevant.

Tagging Work Items Effectively

Tags are free-text labels you attach to any Work Item. Adding a tag takes seconds, but the real value emerges only when the team agrees on a consistent tagging taxonomy and then uses those tags inside queries and dashboards.

A few practical guidelines:

• Agree on a naming convention up front. For example, use ProjectX rather than project-x, projectX, or Project X. Inconsistent casing creates separate tags that behave differently in filters.
• Limit the total number of tags. A long, unmanaged tag list is as useless as no tags at all.
• Assign tag governance to a specific role — typically the person building reports and dashboards — so the list stays meaningful over time.

Harnessing the Power of Queries

Queries are the engine behind Azure DevOps reporting. Every widget on a dashboard, every emailed status update, and every backlog filter can be driven by a saved query. Investing a little time in building well-structured queries pays dividends every sprint.

Building a Query

1. Navigate to Boards → Queries.
2. Add field conditions using the query editor. For example: Work Item Type = Task AND State = Active AND Tags contains ProjectX.
3. Use Add new clause to combine multiple conditions.
4. Click Run query to preview results in the panel below the editor.

Saving and Sharing Queries

Once a query returns the data you need, save it. You have two save locations:

• My Queries — visible only to you.
• Shared Queries — visible to all team members with access to the project. Dashboard widgets can only reference queries saved in Shared Queries or My Queries belonging to the dashboard owner.

Sending Emails Directly from Azure DevOps

Sharing a query result or Work Item status via email used to mean taking screenshots, pasting them into an email client, and hoping the formatting survived. Azure DevOps removes that friction with a built-in email action.

Look for the mail icon or Send email option on query result pages and individual Work Items. Clicking it opens a compose view where you can:

• Search for recipients by name within your Azure DevOps organization.
• Add a personal note or context.
• Include the query results or Work Item details automatically in the message body.

This is particularly useful during daily stand-ups or sprint reviews when stakeholders need a quick snapshot without logging into Azure DevOps themselves.

Building Dashboards for a Single Pane of Glass

Dashboards aggregate the information from your tags, queries, and Work Item fields into a visual overview. A well-built dashboard lets a team lead check project health in under a minute.

Getting Started

1. Expand Overview in the left navigation and click Dashboards.
2. Click Add a widget or Edit on an existing dashboard.
3. Search the widget catalog for the widget you want and click Add.

Recommended Widgets

Adding Conditional Formatting to Query Tile

The Query Tile widget supports color-coded thresholds, making it easy to spot problems at a glance. In the widget’s Configuration panel you can define rules such as:

• Green when the count is fewer than 5
• Blue when the count is between 5 and 10
• Red when the count exceeds 10

Both the Query Tile and Query Results widgets can point to the same underlying saved query, so your count and your detailed list always reflect identical data.

When you are satisfied with the layout, click Done Editing to save the dashboard.

Keyboard Shortcuts

Azure DevOps includes a set of keyboard shortcuts that speed up navigation and common actions without reaching for the mouse. To view them:

• Click the ellipsis (…) on any Work Item and select Keyboard shortcuts for a concise reference.
• Click Full list of keyboard shortcuts at the bottom of that panel to see every available shortcut across Boards, Repos, Pipelines, and more.

Shortcuts are particularly valuable for keyboard-first users who move quickly between backlogs, sprint boards, and individual Work Items.

Putting It All Together

Each of these features delivers incremental value on its own, but the compounding effect is where the real productivity gain lives:

• Templates eliminate repetitive data entry when creating Work Items.
• Tags provide a flexible cross-cutting classification system.
• Queries turn tags and field values into filterable, shareable data sets.
• Dashboards surface query results as visual KPIs and task lists.
• Email integration gets query results to stakeholders without leaving Azure DevOps.
• Keyboard shortcuts reduce navigation overhead for power users.

Azure DevOps is a constantly evolving platform. The features described here represent a foundation — there is considerably more to explore in areas like Pipeline YAML templates, branch policies, artifact feeds, and test plan management. Treat these tips as a starting point and build from there as your team’s maturity with the platform grows.

APIs Are Everywhere — and Largely Unprotected

Application Programming Interfaces (APIs) are the connective tissue of modern software. They allow applications, microservices, mobile apps, and data platforms to communicate with each other. Yet despite their central role in every digital product, API security remains one of the most consistently underestimated attack surfaces in DevOps.

According to figures cited by Akamai, a large majority of Content Delivery Network (CDN) internet traffic is API traffic — meaning that vulnerabilities at the API layer represent a systemic risk to nearly all internet-connected services.

How APIs Are Used in DevOps

APIs serve a wide range of functions across modern engineering organizations:

• External integration: Banks, healthcare platforms, gaming companies, and e-commerce services expose APIs so that partners and customers can interact with their data and services.
• Internal modernization: DevOps teams use APIs to decompose monolithic legacy systems (ERP, CRM, SCM) into loosely coupled microservices and containers, enabling incremental modernization without full rewrites.
• Digital transformation: APIs are a foundational component of most digital transformation initiatives, enabling composable architectures and third-party integrations.

This ubiquity is precisely why API security cannot be treated as an afterthought. A single insecure API endpoint can expose the entire downstream system it serves.

Common API Security Vulnerabilities

Many API vulnerabilities stem from gaps in developer knowledge or inadequate security review processes. The OWASP API Security Top 10 documents the most critical classes of risk. Several recurring weaknesses include:

• Confusion between authentication and authorization: Authentication verifies who a caller is; authorization determines what they are permitted to do. Conflating these two concepts leads to broken access control — one of the most common and dangerous API flaws.
• Security misconfigurations: Default settings, overly permissive CORS policies, missing rate limiting, and exposed debug endpoints frequently make it into production.
• Insufficient logging and monitoring: Without visibility into API traffic patterns, teams cannot detect anomalous behavior, enumerate abuse, or reconstruct the chain of events after an incident.
• Insecure open-source dependencies: APIs often incorporate third-party libraries pulled from public repositories. Unvetted or outdated packages introduce vulnerabilities that developers may not be aware of.
• Lack of input validation: Failing to validate and sanitize API inputs opens the door to injection attacks and data manipulation.

A Real-World Example: API Exploitation in a Digital Payment System

The original Forbes analysis described a case involving Zelle, a peer-to-peer digital payment service widely integrated with U.S. banks. The attack chain illustrates how a weakness at the API integration layer can enable serious financial fraud:

1. Attackers gained full control of a victim’s email account.
2. Using that email access, they triggered credential reset flows — changing PINs, user IDs, and passwords via email and voice verification channels.
3. Attackers registered their own identities and biometrics on their own devices, effectively enrolling themselves as the account owner.
4. They exploited the API integration between Zelle and the victim’s financial institution to transfer funds — in increments under reporting thresholds — to attacker-controlled email addresses.

This type of attack is particularly difficult to detect and reverse. The fraud exploits the gap between a bank’s internal fraud controls and a third-party service’s API, an area where ownership and monitoring are often unclear. Because Zelle transfers are designed to feel like cash, they are hard for consumers to recover and hard for banks to trace.

DevOps Implications: Securing the API Integration Layer

For DevOps and platform engineering teams, this kind of incident highlights several operational responsibilities:

• Treat third-party API integrations as a trust boundary. Any external service your platform integrates with is a potential attack surface. Audit the security posture of third-party APIs before connecting them to your systems.
• Enforce least-privilege authorization at every API endpoint. Each service-to-service call should carry only the permissions it strictly requires, and those permissions should be validated server-side on every request.
• Implement rate limiting and anomaly detection. Unusual transfer patterns, high-frequency calls, and out-of-hours activity should trigger alerts. API gateways (Kong, AWS API Gateway, Apigee, etc.) can enforce these controls centrally.
• Require MFA for account actions with financial or access consequences. Credential resets, device registrations, and payment enrollments should require a second factor that cannot be satisfied by email alone.
• Log API calls comprehensively and review them. Without structured, queryable logs, post-incident forensics are nearly impossible. Use a SIEM or centralized logging platform to correlate API activity across services.
• Conduct regular API security testing. Automated DAST tools (e.g., OWASP ZAP, Burp Suite) and manual penetration testing should be part of your secure SDLC, not a one-off activity.

Consumer-Level Protections

While the primary responsibility for API security lies with the organizations building and operating these systems, end users can take steps to reduce their personal exposure:

• Use strong, unique passwords for each service. A password manager simplifies this significantly. Avoid patterns based on personal information (birthdays, names, anniversaries).
• Enable multi-factor authentication (MFA) on all accounts, especially email, banking, and payment platforms. Prefer authenticator apps or hardware keys over SMS-based MFA where possible.
• Understand your bank’s fraud recovery policy. Peer-to-peer payment fraud is often not covered in the same way as traditional card fraud. Know what you are entitled to before you need it.
• Opt out of automatic third-party service enrollment. If your bank automatically enrolls you in services like Zelle, request to be unenrolled or confirm enrollment settings explicitly.
• Be cautious with phishing vectors. Attackers targeting payment API weaknesses often initiate attacks through email or phone phishing to capture credentials first.

The Broader Security Picture

API security is not a niche concern — it is a foundational requirement for any organization running modern software. As the adoption of microservices, cloud-native architectures, and third-party integrations accelerates, the API attack surface expands proportionally. The shift to remote work has compounded this risk by moving employees and their devices outside corporate network perimeters, making API-level controls even more critical.

The question facing most organizations is not whether an API-related breach will occur, but whether they have the visibility and controls in place to detect it quickly and limit the damage. Treating API security as a first-class engineering concern — built into design, development, testing, and operations — is the most reliable path to reducing that risk.

Disclosure: The original Forbes article was authored by an analyst at Moor Insights & Strategy. The firm has provided research, analysis, advising, and/or consulting to companies across the technology industry. This rewritten version is for editorial and educational purposes.

Serverless and DevOps: Two Misunderstood Game-Changers

DevOps has existed for more than a decade, yet it is still misunderstood by many organisations. You cannot purchase “a DevOps”—it is a culture, a set of practices and a mindset. Serverless carries a similar burden: the name markets well but consistently creates confusion in the industry.

Despite the confusion, both concepts are game-changers. Some have argued that serverless makes DevOps obsolete. That claim is false. What serverless does do is dramatically lower the operational overhead that has historically slowed DevOps adoption at scale—enabling teams to focus on delivery rather than infrastructure management.

Fortune 100 insurer Liberty Mutual is a well-documented example. The company began its cloud journey roughly ten years ago, at the same time internal engineering teams were adopting DevOps principles. Two foundational convictions emerged early:

• Cloud strategy: Build on cloud-native principles, not simply “someone else’s data centre.”
• DevOps strategy: Anchor on CALMS (Culture, Automation, Lean, Measurement, Sharing) rather than writing one-off scripts.

These two tracks eventually converged in a serverless-first strategy that allowed Liberty Mutual to scale advanced DevOps practices across a large, globally distributed engineering organisation.

Why Infrastructure as Code Alone Wasn’t Enough

Infrastructure as code (IaC) is a cornerstone of modern cloud strategy. But teaching more than 1,000 software engineers to provision secure, resilient infrastructure via YAML (as was the common approach around 2015) is a steep learning curve. Layering on advanced requirements—secure-by-design, chaos testing, resiliency, observability, performance optimisation—makes it steeper still.

What changed the equation was the move to serverless architectures. When teams began building serverless systems, a notable shift occurred:

• Workloads became self-healing by default.
• Blue-green deployments became straightforward to implement.
• Teams consistently hit high DORA metrics for both throughput and stability.
• Business value was delivered at significantly lower compute costs.

Core Principles for an Enterprise Serverless Journey

Whether you are a startup or a large enterprise, the following principles provide a useful anchor as you begin adopting serverless. They keep teams focused on business outcomes and prevent the common trap of becoming lost in the vast catalogue of cloud services.

1. Measure Team Outcomes in Business Terms

Product thinking, North Star metrics and impact mapping are all practical tools for keeping engineering teams focused on what matters. The guiding question should always be: What is the most valuable feature we can deliver next? Complexity in tooling and process should never obscure that simple priority.

2. Code Is a Liability

The software industry has known for decades that lines of code (LOC) is a poor proxy for engineering success. Yet LOC counts still generate misplaced pride. Serverless encourages a different instinct: favour managed, event-driven infrastructure that is correctly decomposed, and write as little custom code as possible. Less code means less surface area for bugs, less maintenance burden and faster onboarding for new engineers. You cannot code your way out of complexity—pragmatism is the better tool.

3. Serverless Is a Spectrum, Not a Binary Choice

A serverless-first strategy means starting with fully managed, serverless options and only moving toward IaaS (Infrastructure as a Service) when there is a clear, justified reason. It does not mean every workload must be serverless at all costs. Treat it as an operational construct: begin at the highest level of abstraction and work back toward lower-level infrastructure only when required.

Measurement in modern software development should be trend-based rather than absolute. The four key DORA metrics—deployment frequency, lead time for changes, mean time to restore (MTTR) and change failure rate—are excellent indicators of team health. Serverless teams with minimal handoffs routinely perform strongly across all four.

Key Building Blocks for Scaling DevOps with Serverless

Committing to serverless requires more than choosing a cloud provider’s function-as-a-service offering. The following building blocks provide the foundation that allows advanced DevOps practices to scale safely.

Public Cloud Strategy

Absolute clarity is required before making the move to public cloud. This is a genuine transformation. Security, infrastructure, procurement and engineering functions all need to reinvent how they operate. Getting alignment on what “cloud-native” means to your organisation—before you migrate workloads—is critical. For startups, a serverless-first approach is often the only realistic path to the development velocity required to compete.

Deployment Pipelines

In a serverless environment, the pipeline to production becomes a business-critical capability in its own right. Traditional controls—security gates, compliance checks, approval workflows—must be reimagined to provide genuine protection without creating friction that slows teams down. Under-investment in pipelines is one of the fastest ways to frustrate capable engineers and negate the velocity gains that serverless is supposed to deliver.

Reusable Patterns

As teams adopt serverless, they will independently start creating the same boilerplate components. An effective reuse strategy prevents mass duplication without introducing the bureaucratic overhead that kills momentum. Tools such as the AWS Cloud Development Kit (CDK) and open-source pattern libraries like cdkpatterns.com allow teams to assemble production-ready building blocks quickly. Liberty Mutual has reportedly deployed hundreds of applications using CDK-based patterns.

Well-Architected Reviews

Architecture must live inside the delivery teams, not in a centralised ivory tower. The AWS Well-Architected Framework—with its five pillars covering operational excellence, security, reliability, performance efficiency and cost optimisation—provides a structured, team-friendly approach to non-functional requirements. Teams can self-assess against the framework, but architects play an important coaching role for more nuanced areas.

The goal is to embed well-architected constructs directly into code building blocks so that quality controls are baked into the engineering environment from day one—not bolted on during a pre-release review.

The Business Case: Engineering as a Differentiator

When engineers go through this journey—adopting serverless-first principles, working within strong pipelines, leveraging reusable patterns and applying well-architected reviews—they acquire powerful tools. They can build world-class, low-cost systems quickly. The feedback loop tightens. Innovation accelerates.

There is a caveat, however: this is a relentless journey of optimisation and improvement. Organisations that do not view engineering as a core differentiating capability may find the ongoing commitment difficult to sustain.

The single most important factor in a successful serverless journey is ensuring engineering teams deeply understand the business they are serving. Cross-functional teams chasing a clear business KPI—rather than technical metrics in isolation—are the ones that realise the full potential of serverless. When that alignment exists, the traditional business-IT divide dissolves. Technology teams innovate directly in pursuit of the company’s vision, and engineering engagement improves as a result.

Serverless is not a silver bullet, but as a paradigm shift it genuinely enables engineers to innovate and deliver at a pace that was not previously practical in large enterprises. The key is building the right cultural and technical foundation before, not after, you begin.

Original source: devops.com. Liberty Mutual examples and figures referenced in the original article.

Why Healthcare IT Is Turning to Database DevOps

The COVID-19 pandemic placed extraordinary pressure on healthcare IT teams in 2020. With budgets constrained, staff stretched thin, and demand for remote patient services surging, engineering organizations were forced to accelerate digital transformation faster than originally planned. According to Redgate Software’s 2020 State of Database DevOps Report for the Healthcare sector, one clear response to this pressure was a measurable increase in DevOps and database DevOps adoption.

The need to rapidly develop and deploy telehealth platforms, provide reliable access to electronic health records (EHR), and maintain strict compliance with data protection regulations pushed healthcare IT teams to standardize processes and lean on automation. Database DevOps — extending software delivery best practices to include the database layer — emerged as a practical answer to these challenges.

Key Findings from the 2020 Healthcare Report

1. DevOps Adoption Is Outpacing Other Sectors

The report found that 70% of healthcare respondents had adopted DevOps across all or some projects, or had a Proof of Concept (PoC) in place — slightly ahead of the cross-industry average of 68%. More significantly, 41% had moved beyond the PoC stage, compared to 36% in sectors such as government and financial services. This suggests that healthcare organizations are not just experimenting with DevOps — they are operationalizing it.

2. Healthcare Leads in Database Automation Adoption

The healthcare sector ranked ahead of other industries in adopting automation across the database development lifecycle. Survey respondents cited the following as the top three drivers for automation:

• Freeing up developer time — cited by 27% of respondents
• Increasing speed of delivery — cited by 22%
• Reducing the risk of data loss — cited by 13%

The emphasis on data loss prevention is notable given the sensitivity of patient health data and the strict regulatory environment healthcare organizations operate in, including requirements under HIPAA in the United States.

3. Cloud Adoption Is Growing but Still Maturing

42% of healthcare respondents reported using cloud infrastructure in some capacity. While this figure is comparable to other industries, Redgate’s analysts noted that cloud adoption in healthcare is likely to accelerate as remote service delivery becomes the norm and DevOps practices make cloud-native deployment more accessible to teams that previously relied on on-premises infrastructure.

4. Version Control Is Becoming Central to Compliance

58% of respondents reported having version control measures in place for database code. Version control for database schemas and scripts enables automated builds and deployments, and serves as a foundational component for compliance auditing. When database changes are tracked in source control, teams can demonstrate repeatability, traceability, and the elimination of ad-hoc manual changes — all of which are critical requirements in regulated industries.

In practice, this means treating database migrations and schema changes with the same rigor as application code: committing changes to a repository, running automated validation, and deploying through a controlled pipeline rather than applying changes directly to production databases.

5. Database Deployment Frequency Is Increasing Significantly

51% of healthcare respondents reported deploying database changes daily or weekly in 2020, a significant increase from previous years. Among North American respondents specifically, 55% said they deploy database changes daily, weekly, or on demand — a figure that points to the rapid adoption of Agile and continuous delivery practices to support frequently changing clinical and operational applications.

“What’s surprising this year is the way North American respondents are surging ahead, with 55% saying that they deploy database changes daily, weekly or even on demand. This indicates that they’re embracing Agile practices to better meet the needs of doctors, patients and remote services like telehealth that rely on these databases each day.”

— Kendra Little, DevOps Advocate, Redgate Software

What Database DevOps Means in a Healthcare Context

For most engineering teams, “DevOps” primarily refers to application code pipelines: continuous integration, automated testing, and continuous deployment. However, the database layer is often excluded from these pipelines, becoming a bottleneck where changes are applied manually by a DBA, are difficult to roll back, and are poorly audited.

Database DevOps addresses this by bringing the same practices to the data tier:

• Source control for schemas: Database objects (tables, stored procedures, views) are stored in version control alongside application code.
• Automated schema comparison and migration: Tooling compares the target database state with the desired state and generates safe migration scripts.
• CI/CD pipeline integration: Database changes are validated and deployed through the same pipeline as application changes, ensuring consistency across environments.
• Drift detection: Automated checks identify when a live database has diverged from its source-controlled definition, a critical capability for compliance.
• Rollback capability: Because changes are scripted and versioned, rolling back a bad deployment is planned for rather than improvised.

In healthcare specifically, these capabilities support compliance frameworks by ensuring that every database change is documented, reviewed, and reproducible — reducing the risk of audit failures or data integrity issues that could compromise patient safety.

The Compliance Dimension

Healthcare organizations must navigate complex regulatory environments. In the United States, HIPAA mandates strict controls over how protected health information (PHI) is stored, accessed, and modified. In Europe, GDPR applies. Many organizations are also subject to additional industry-specific standards.

Database DevOps practices directly support several common compliance requirements:

• Audit trails: Version control history provides a complete record of who changed what and when.
• Access control: Pipeline-based deployments remove the need for developers to have direct write access to production databases.
• Repeatability: Automated deployments are consistent and deterministic, reducing the risk of human error that could introduce vulnerabilities.
• Data masking in non-production environments: Tooling can ensure that sensitive patient data is masked before being used in development or test environments, so PHI never leaves the production boundary unprotected.

Telehealth as a Forcing Function

The rapid expansion of telehealth services during the pandemic created an immediate engineering challenge: systems that were designed for in-clinic use had to scale for remote access, often with little lead time. Backend databases supporting appointment scheduling, patient records, billing, and clinical workflows suddenly needed to handle greater load, more frequent updates, and integration with new front-end applications.

Teams that had already adopted database DevOps were better positioned to respond quickly — deploying schema changes to support new features, adding indexes to handle increased query load, and integrating new data sources through controlled, automated pipelines rather than through emergency manual interventions.

About the Research

Redgate Software has published its State of Database DevOps Report annually for over four years. The 2020 edition gathered responses from developers, database specialists, and IT leaders across multiple industries and company sizes globally. The healthcare sector findings represent a subset of that broader dataset, enabling sector-specific comparisons against cross-industry benchmarks.

For the full healthcare sector findings, refer to Redgate’s official report publications at red-gate.com.

About Redgate Software

Redgate Software, headquartered in Cambridge, England, develops tools for database development and DevOps, with a focus on Microsoft SQL Server environments. The company’s tooling is used by IT professionals across organizations of all sizes to automate database deployments, enforce version control, and maintain compliance. According to Redgate, its tools are used by more than 100,000 companies, including a significant proportion of Fortune 100 organizations.

Airtel and AWS Form Strategic Cloud Partnership

Bharti Airtel Ltd. and Amazon Web Services (AWS) announced a strategic partnership aimed at expanding Airtel’s enterprise cloud business in India. The agreement enables Airtel to offer a significantly broader range of cloud products and managed services to its large enterprise and SMB customer base.

At the time of the announcement, Airtel reported serving more than 2,500 large enterprises and over one million emerging businesses through its product portfolio, which includes Airtel Cloud — its multi-cloud product and solutions business.

What the Partnership Covers

Under the agreement, Airtel Cloud will establish an AWS Cloud Practice backed by AWS Professional Services. The collaboration is structured around three main pillars:

• AWS Cloud Practice: Airtel Cloud will develop a dedicated AWS practice, giving enterprise customers access to AWS Professional Services expertise through an Airtel-led engagement model.
• Differentiated Airtel Cloud Products: New cloud products and capabilities will be built by combining AWS services with Airtel’s own data centre infrastructure, network assets, and telecoms offerings — aiming to produce solutions not available from either company alone.
• Integrated Sales and Support: Enterprise customers will receive a unified sales, consulting, and support experience from both Airtel and AWS teams, along with enhanced security, scalability, and cloud management capabilities.

Why This Matters: India’s Growing Public Cloud Market

The timing of the partnership reflects broader momentum in India’s enterprise technology sector. According to International Data Corporation (IDC) figures cited at the time of the announcement, India’s public cloud services market was valued at approximately $3.4 billion in 2020 and was projected to reach $7.1 billion by 2024 — representing significant compound annual growth.

For Airtel, partnering with AWS positions the telco to compete more aggressively for a share of this expanding market, moving beyond traditional connectivity services into higher-margin managed cloud and professional services.

The Telco-Cloud Convergence Trend

The Airtel–AWS deal is part of a broader global trend in which telecommunications operators leverage their existing network infrastructure, data centre footprint, and enterprise customer relationships to compete in the cloud services space. Telcos bring several natural advantages to this market:

• Network edge infrastructure: Proximity to customers enables low-latency cloud delivery, particularly relevant for hybrid and edge computing use cases.
• Existing enterprise relationships: Large telcos already hold long-term contracts with enterprises for connectivity, making cross-selling cloud services a lower-friction opportunity.
• Data centre assets: Many telcos operate their own data centres, which can be integrated with hyperscaler infrastructure to create differentiated hybrid offerings.

By combining Airtel’s network and data centre capabilities with AWS’s cloud platform and professional services expertise, the partnership is designed to address the full cloud adoption lifecycle for Indian enterprises — from initial migration consulting through to ongoing managed operations.

Implications for Enterprise DevOps Teams in India

For DevOps and platform engineering teams operating within Indian enterprises, this kind of partnership can have practical implications:

• Broader procurement options: Enterprises already purchasing connectivity services from Airtel may be able to consolidate cloud procurement under a single vendor relationship.
• Access to AWS services through a local partner: Airtel’s Professional Services layer, backed by AWS, could provide localised support for cloud migrations, architecture reviews, and DevOps toolchain implementations.
• Hybrid and multi-cloud architectures: The combination of Airtel’s on-premises data centre capabilities with AWS public cloud services is particularly suited to enterprises with regulatory or latency requirements that prevent a full public-cloud migration.

Video Overview

Overview

Google Cloud and Best Buy announced an expanded, multi-year partnership that designates Google Cloud as the cloud provider for Best Buy’s Enterprise Data Platform. The deal covers Best Buy’s operations across the United States, Canada, and Mexico, with the stated goal of using cloud infrastructure, machine learning, and analytics to build more personalized shopping experiences for customers.

For DevOps and cloud engineering teams, the partnership is a useful real-world example of a large retailer consolidating fragmented, legacy data estates onto a single hyperscale cloud platform — a common modernization pattern that surfaces both technical and organizational challenges at scale.

Why Best Buy Chose Google Cloud

According to the announcement, Best Buy selected Google Cloud based on the platform’s data and analytics capabilities and Google’s ability to support the retailer’s digital transformation roadmap. Key capabilities cited include:

• Scalable cloud infrastructure capable of supporting enterprise-wide workloads across multiple countries
• Machine learning and AI tooling to generate personalized product recommendations and offers
• Data analytics services to surface customer insights from consolidated data sources
• Flexibility to iterate quickly on new digital products and services

“Our customers are at the heart of everything we do, and better understanding their needs will help us create new, more meaningful experiences for them. Partnering with Google Cloud and the impressive capabilities its platform offers will help make these experiences a reality.”

— Brian Tilzer, Chief Digital and Technology Officer, Best Buy

Two Core Technical Pillars

The partnership is structured around two interdependent workstreams:

1. Unifying Data Sources

Best Buy operates a range of legacy platforms accumulated over decades of retail and e-commerce growth. The first phase of the engagement focuses on consolidating those disparate data sources into a unified Enterprise Data Platform hosted on Google Cloud. Once unified, ML and AI models will be applied to the data to generate personalized offers and product recommendations at scale.

This data unification step is foundational — without a single, clean data layer, downstream ML models produce unreliable outputs. Retailers commonly struggle with siloed point-of-sale, e-commerce, loyalty, and supply-chain data living in separate systems, making this kind of consolidation a high-value but technically complex initiative.

2. Developing New Customer Experiences

With unified data in place, Best Buy plans to experiment with new customer-facing products and services, including:

• Personalized offers and tailored loyalty rewards
• Unique cross-channel shopping experiences (in-store, online, mobile)
• New service offerings informed by behavioral and transactional data

Because the underlying platform is cloud-native, Best Buy’s engineering teams can prototype and ship new capabilities faster than would be possible on on-premises infrastructure, using managed services to reduce operational overhead.

“Retailers like Best Buy are accelerating their digital transformations in order to deliver new products and services to customers. Using Google Cloud’s scalable and secure infrastructure, and leading data and analytics solutions, Best Buy will be able to create new insights from their data, enabling them to innovate now and into the future.”

— Thomas Kurian, CEO, Google Cloud

Key Takeaways for DevOps and Cloud Engineering Teams

The Best Buy–Google Cloud deal reflects several broader trends worth noting for practitioners:

• Legacy data estate modernization remains one of the most common and technically challenging cloud migration scenarios. Unifying data before applying ML is a prerequisite, not an afterthought.
• Enterprise Data Platforms built on managed cloud services (such as BigQuery, Dataflow, or Vertex AI in the Google ecosystem) let engineering teams focus on data pipelines and model development rather than infrastructure management.
• Iterative digital product development is enabled by cloud elasticity — teams can spin up experiment environments rapidly without long provisioning cycles.
• Multi-year strategic partnerships between hyperscalers and large enterprises often include joint engineering resources, not just commercial licensing — a factor that can significantly accelerate delivery timelines.

Background

This announcement was made in August 2020, during a period of accelerated digital transformation across the retail sector driven by shifts in consumer behavior. The expansion built on an existing relationship between the two companies rather than representing a greenfield engagement.

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.

Human Error Remains the Leading Cause of Security Breaches

A widely cited 2014 IBM study concluded that 95 percent of the digital security breaches it investigated were either caused or contributed to by human error—including errors made by software developers and administrators. The remainder were largely the result of technical misconfiguration. That finding has been echoed repeatedly in subsequent breach disclosures across the industry: regardless of the technology stack, humans make mistakes, and those mistakes frequently involve granting access or privileges that should have been denied.

Kubernetes Is Not Immune to Misconfiguration

Kubernetes environments are subject to exactly the same risks. Cloud-native infrastructure, like its legacy data-center predecessors, depends on administrators making correct decisions about access control, privilege assignment, and network policy. In Kubernetes, access is typically governed through Role-Based Access Control (RBAC). Misconfigured RBAC rules can inadvertently grant full cluster-admin permissions to service accounts, users, or workloads that have no legitimate need for that level of access—creating a significant attack surface.

Compounding the problem is Kubernetes’ design philosophy. Its primary mission is to enable rapid application development and deployment. Many of its built-in security controls are not enabled by default, because strict security settings can slow down the build-and-iterate cycle that development teams depend on. Once an application moves from development into production and is exposed to a wider user base, those lax default settings become a multiplied liability.

Why Traditional Security Tools Don’t Work for Kubernetes

Security tooling designed for virtual machines or bare-metal servers was built around static infrastructure concepts: known IP addresses, persistent workloads, and predictable network topologies. Kubernetes violates all of these assumptions. Pods are ephemeral. IP addresses change on every restart. Workloads scale horizontally and dynamically. Traditional perimeter-based or agent-per-host tools cannot keep pace with this level of dynamism, and they lack the semantic understanding of Kubernetes objects—namespaces, deployments, services, pods—needed to make meaningful security decisions.

Two Approaches to Container Security

As cloud-native adoption has matured, the container security market has converged around two broad architectural approaches:

• Container-centric security: Focuses on securing container images and runtimes. These tools use techniques such as inline proxies and kernel-level shims to intercept and control cross-container communication. They are effective at smaller scales and for image-layer vulnerability scanning, but they operate below the Kubernetes orchestration layer and therefore lack full awareness of Kubernetes-level context.
• Kubernetes-native security: Operates at the Kubernetes API layer. Instead of imposing external controls, these platforms express and enforce security policy through Kubernetes itself—making the orchestrator the control plane for both infrastructure and security. Security is built in, not bolted on.

What Makes a Security Platform Truly Kubernetes-Native?

The term “Kubernetes-native” is both an architectural description and a functional requirement. A platform can legitimately claim this label only if it meets several criteria:

• Direct API server integration: The platform must integrate with the Kubernetes API server to gain first-hand, real-time visibility into cluster state—workloads, configurations, and runtime behavior.
• Kubernetes vulnerability assessment: It must be capable of assessing vulnerabilities within Kubernetes itself, not just within application containers.
• Object model awareness: Security policies must be expressed in terms of native Kubernetes objects—Deployments, Namespaces, Services, Pods, and ConfigMaps—rather than in terms of IP addresses or hostnames.
• Leverage of built-in controls: The platform should activate and orchestrate Kubernetes’ own security primitives (Network Policies, Pod Security Standards, Admission Controllers, Secrets management) rather than replacing them with proprietary mechanisms.

From a functional coverage standpoint, a mature Kubernetes-native security platform should address:

• Comprehensive workload and infrastructure visibility
• Vulnerability management (images, packages, and Kubernetes configuration)
• Network segmentation and policy enforcement
• Configuration and compliance assessment (CIS Kubernetes Benchmark, NIST, etc.)
• Runtime threat detection
• Incident response and forensics

Three Practical Advantages of the Kubernetes-Native Approach

1. Richer Visibility and More Effective Risk Discovery

Kubernetes maintains a rich declarative model of everything running in the cluster. A Kubernetes-native security platform can consume that model in full—correlating image vulnerability data, RBAC configuration, network policy, and runtime behavior into a unified risk picture. This contextual awareness allows teams to prioritize findings based on actual exposure, not just theoretical severity scores.

2. Greater Operational Efficiency

When security tooling speaks the same language as the infrastructure it protects, DevOps and security teams share a common source of truth. Engineers troubleshooting a misconfiguration can use the same Kubernetes constructs they already understand—rather than translating between an external security tool’s proprietary model and Kubernetes’ actual state. This reduces mean time to detect (MTTD) and mean time to respond (MTTR) for security incidents.

3. Reduced Operational Risk

Enforcing policy through Kubernetes’ own control mechanisms means security scales and adapts at exactly the same rate as the infrastructure. There is no lag between a workload scaling out and the security policy applying to the new instances, and there is no risk of conflict between an external security agent and the orchestrator’s own scheduling and networking decisions. The orchestrator enforces policy natively, eliminating a whole class of integration failure modes.

Putting It Into Practice: Key Recommendations

Organizations moving toward a Kubernetes-native security posture should focus on the following areas:

1. Audit RBAC configurations regularly. Use tools like kubectl auth can-i and dedicated RBAC auditing utilities to identify over-privileged service accounts and users.
2. Enable and enforce Pod Security Standards. Kubernetes deprecated PodSecurityPolicy in 1.21 and replaced it with Pod Security Admission in 1.25. Ensure your cluster enforces at least the Baseline profile in production namespaces.
3. Apply Network Policies. By default, all pods in a Kubernetes cluster can communicate with all other pods. Implement NetworkPolicy resources to enforce least-privilege network segmentation.
4. Integrate image scanning into CI/CD. Shift vulnerability detection left so that images with critical CVEs never reach production.
5. Use Admission Controllers. Tools such as Open Policy Agent (OPA) Gatekeeper or Kyverno allow you to enforce organizational policy as code at admission time, preventing non-compliant resources from being created.
6. Instrument runtime detection. Complement shift-left controls with runtime tools (such as Falco) that detect anomalous syscall behavior within running containers.

Conclusion

Kubernetes’ built-in security capabilities are among the most powerful controls available to cloud-native teams—but they require deliberate activation and expert configuration to be effective. Given that human error will always be a factor, continuously identifying and remediating misconfigurations at the Kubernetes layer is essential. A Kubernetes-native security platform, one that integrates deeply with the API server and enforces policy through the orchestrator itself, gives DevOps and security teams the visibility, efficiency, and scalability they need to protect cloud-native applications without sacrificing the agility that Kubernetes was designed to deliver.

The Cloud Market Keeps Growing — and Startups Are Leading the Charge

Even as the COVID-19 pandemic disrupted large portions of the global economy in 2020, the cloud computing market showed remarkable resilience. Gartner forecast the public cloud market would grow 6.4% in 2020 to reach $242.7 billion, with Software as a Service (SaaS) accounting for roughly $104.7 billion of that total. A separate 2020 InformationWeek/Interop survey found that IT leaders estimated 42% of their cloud-related budgets were directed at SaaS initiatives.

Flexera’s 2020 State of the Cloud Report reinforced how pervasive cloud adoption had become: 96% of surveyed organisations were using public cloud services, and 76% had a private cloud environment in place. Cloud computing was no longer an emerging option — it had become the default operating model for enterprises and small businesses alike.

Why Cloud-Native Startups Matter

As cloud infrastructure matured, it created fertile ground for a new generation of companies built entirely around cloud primitives. These cloud-native startups did not need to migrate legacy systems or maintain on-premises hardware — they could design their products from the ground up for elasticity, distributed architecture, and pay-as-you-go economics.

This structural advantage allowed them to challenge established vendors in categories such as backup and recovery, enterprise networking, security, and relational databases — often delivering the same capabilities at lower cost and with greater agility. Investors took notice: many of the most prominent cloud-native startups raised hundreds of millions of dollars in venture funding.

Selection Criteria

InformationWeek compiled its list of ten notable cloud startups using the following criteria:

• Founded in 2015 or later — ensuring the companies were genuinely cloud-era businesses rather than incumbents that had adopted cloud features.
• Cloud-related product or service — each company had to offer something directly tied to cloud infrastructure, platforms, or applications.
• Significant funding — the candidate pool was drawn from the highest-funded cloud startups tracked by Crunchbase at the time of publication.
• Ranked by total funding received — companies are listed in descending order of capital raised, not by subjective merit.

Key Technology Themes Among These Startups

While each company on the list has its own focus area, several common themes emerge across the group:

Cloud Meets IoT and Edge Computing

Several startups combine cloud-native architectures with Internet of Things (IoT) and edge computing capabilities. Rather than processing all data in a central cloud region, these platforms push computation closer to where data is generated — reducing latency and bandwidth costs while still leveraging cloud-scale management and analytics.

Reinventing Traditional IT with Cloud Economics

Other companies on the list take familiar IT disciplines — backup and disaster recovery, enterprise networking, identity and access management, and relational databases — and rebuild them as cloud-native services. The result is typically a consumption-based pricing model, automated operations, and integrations with major cloud providers such as AWS, Microsoft Azure, and Google Cloud.

Robotics and Automation

Some startups extend the cloud’s reach into physical operations, using cloud-connected robotics and automation platforms to bring software-defined control to warehouses, manufacturing floors, and logistics networks.

What This Means for DevOps and Platform Teams

For DevOps engineers and platform architects, the growth of cloud-native startups has practical implications:

• More specialised tooling: As startups target narrow problem spaces, teams gain access to purpose-built tools rather than trying to adapt general-purpose platforms.
• Vendor consolidation risk: Many well-funded startups are acquisition targets. Evaluate long-term vendor viability before standardising on a startup’s platform.
• Integration complexity: Cloud-native tools often assume a multi-cloud or hybrid environment. Review integration support for your specific stack before committing.
• Pricing model shifts: Consumption-based pricing can reduce upfront costs but introduces budget unpredictability. Implement cloud cost monitoring from day one.

Where to Learn More

The original InformationWeek slideshow, authored by Cynthia Harvey, provides individual profiles of each company including their founding story, core product, and funding history. For the most current funding data, consult Crunchbase directly, as startup valuations and funding rounds change frequently. Flexera publishes an annual State of the Cloud Report that tracks enterprise cloud adoption trends and is worth reviewing each year as a benchmark for your own organisation’s cloud maturity.

Original reporting by Cynthia Harvey for InformationWeek. Data points sourced from Gartner, Flexera, and a 2020 InformationWeek/Interop survey.

What Is the Cloud Computing Market?

The global cloud computing market encompasses the delivery of computing services—servers, storage, databases, networking, software, analytics, and intelligence—over the internet. Vendors charge on a pay-as-you-go basis, allowing organizations to scale capacity up or down without large capital expenditure on physical hardware.

Market research firms regularly publish reports that analyze this space by deployment model, service type, geography, and vendor. Understanding these segmentation dimensions is essential for engineers and architects making platform decisions, as well as for procurement and finance teams evaluating vendor lock-in and total cost of ownership.

Cloud Deployment Models

Cloud infrastructure is typically categorized by who controls and accesses the underlying resources:

• Public Cloud: Infrastructure owned and operated by a third-party provider and shared across multiple tenants. Examples include AWS, Microsoft Azure, and Google Cloud. Public cloud offers the greatest elasticity and the lowest entry cost.
• Private Cloud: Dedicated infrastructure operated solely for one organization, either on-premises or hosted by a provider. Private cloud trades some flexibility for greater control over security, compliance, and customization.
• Hybrid Cloud: A combination of public and private environments connected by orchestration, allowing workloads to move between them based on policy, cost, or regulatory requirements. Hybrid is the dominant model for large enterprises.
• Community Cloud: Shared infrastructure provisioned for a specific group of organizations with common concerns (e.g., regulatory compliance in healthcare or financial services). Less common than the other three models, but important in regulated industries.

Cloud Service Categories

Beyond deployment model, cloud services are segmented by the level of abstraction they provide to the consumer:

• Infrastructure as a Service (IaaS): Provides virtualized compute, storage, and networking. The consumer manages the operating system and above. AWS EC2, Azure Virtual Machines, and Google Compute Engine are canonical examples.
• Platform as a Service (PaaS): Provides a managed runtime environment for developing and deploying applications without managing the underlying infrastructure. Examples include Google App Engine, Azure App Service, and Heroku.
• Software as a Service (SaaS): Delivers fully managed software applications over the internet. The provider handles everything from infrastructure to application updates. Examples include Salesforce, Microsoft 365, and Google Workspace.

A fourth category—Function as a Service (FaaS) or serverless computing—has grown significantly since these traditional three were codified, and is now a material segment of many cloud vendors’ revenue.

Key Vendors in the Cloud Computing Market

The cloud market is dominated by a small number of hyperscale providers, with a longer tail of specialist and regional vendors. The following organizations are consistently cited as significant market participants:

• Amazon Web Services (AWS) — the longest-established hyperscaler and largest by market share as of the time of writing
• Microsoft Azure — strong enterprise presence, particularly with organizations already invested in the Microsoft ecosystem
• Google Cloud — significant in data analytics, machine learning, and Kubernetes (Google originated the project)
• IBM Cloud — focused on hybrid cloud and enterprise workloads, strengthened by the Red Hat acquisition
• Oracle Cloud — prominent in database workloads and enterprise application hosting
• SAP — dominant in ERP SaaS delivery
• Cisco Systems — networking infrastructure underpinning both on-premises and cloud environments, plus its own cloud management and security offerings
• Akamai Technologies — content delivery and edge cloud services
• Citrix Systems — virtualization and desktop-as-a-service
• HP / HPE — hybrid cloud hardware and GreenLake cloud services

Vendors such as CA Technologies (now Broadcom), Yahoo, and Flexiant, which appear in older market reports, have either been acquired, pivoted, or reduced their cloud footprint significantly since 2020.

Key Questions for Evaluating Any Cloud Market Analysis

When reviewing a cloud computing market report—whether from an analyst firm or a vendor—engineers and architects should scrutinize the following dimensions:

1. What is the forecast horizon and base year? Market projections published in 2020 with a 2029 horizon should be treated as directional, not precise, given the pace of change in this sector.
2. How is market size defined? Reports vary in whether they count end-user spend, vendor revenue, or infrastructure investment. Compare like with like.
3. Which geographies are included? North American and Western European markets behave differently from APAC and emerging markets in terms of growth rate, regulatory environment, and dominant vendors.
4. What segmentation methodology is used? Some reports conflate IaaS and PaaS, or treat managed services separately from raw cloud infrastructure. Understand the taxonomy before drawing conclusions.
5. Who funded the report? Vendor-commissioned research may emphasize segments where the commissioning vendor is strongest.
6. What are the identified market risks? Credible analysis will address regulatory risk (data sovereignty, GDPR), concentration risk (dependency on one hyperscaler), and security risks such as misconfiguration.
7. Who are the distributors and channel partners? Cloud is increasingly sold through managed service providers (MSPs) and system integrators rather than directly, which affects pricing and negotiation leverage.

Market Dynamics Driving Cloud Adoption

Several structural forces continue to accelerate cloud adoption across industries:

• Operational agility: Cloud enables teams to provision and deprovision resources in minutes, compressing the time from idea to production deployment.
• Cost model shift: Moving from capital expenditure (CapEx) on data center hardware to operational expenditure (OpEx) on cloud consumption aligns IT spending with business activity.
• Global reach: Hyperscalers operate dozens of regions worldwide, allowing organizations to serve users with low latency and meet data residency requirements without building their own facilities.
• Managed services: Databases, message queues, container orchestration, and machine learning platforms are available as managed services, reducing the operational burden on engineering teams.
• Remote work and distributed teams: The shift to distributed workforces accelerated cloud adoption for collaboration tools, VPN alternatives (ZTNA), and cloud-hosted development environments.

Factors That Can Restrain Growth

• Data sovereignty and compliance: Regulations such as GDPR, HIPAA, and sector-specific rules restrict where data can be stored and processed, complicating multi-region cloud strategies.
• Egress costs: Moving large volumes of data out of a cloud provider is expensive. This creates lock-in and can make hybrid or multi-cloud architectures costlier than anticipated.
• Security and misconfiguration risk: The shared responsibility model means organizations bear responsibility for securing their own workloads. Misconfigured storage buckets and overly permissive IAM policies remain leading causes of cloud data breaches.
• Skills gap: Demand for cloud architects, DevOps engineers, and cloud security specialists continues to outpace supply, constraining how quickly organizations can migrate and optimize workloads.
• Cost overruns: Without disciplined FinOps practices, cloud bills can grow unexpectedly. Reserved instance planning, right-sizing, and tagging strategies are essential to cost control.

Summary

The cloud computing market is large, growing, and segmented across multiple dimensions—deployment model, service type, geography, and industry vertical. For DevOps and platform engineering teams, understanding this landscape matters not just for vendor selection but for architecture decisions, security posture, and long-term cost management. Any market report you evaluate should be read critically, with attention to its methodology, funding source, and the pace at which the underlying technology is evolving.

DevOps Enterprise Summit Las Vegas 2020 Moves to Virtual Format

IT Revolution, the publishing and events organization focused on advancing DevOps adoption, announced in July 2020 that the DevOps Enterprise Summit (DOES) Las Vegas would transition to a fully virtual format in response to the COVID-19 pandemic. The event was rescheduled for October 13–15, 2020, running in the Pacific Timezone.

The decision followed the successful delivery of a virtual DOES London event earlier in 2020, which served as a proof-of-concept for replicating the immersive, collaborative experience of an in-person DevOps conference in an online setting.

Registration and Attendance Limits

Registration was priced at $650 per attendee, with capacity capped at 3,000 attendees. IT Revolution cited the need to keep Slack channels and group networking sessions manageable as the primary reason for the attendance limit — a practical constraint unique to virtual event formats that rely heavily on text-based community interaction.

Registration deadlines and cancellation policies were updated in line with evolving COVID-19 guidance at the time of announcement.

What the Virtual Format Included

The virtual Las Vegas event was designed to mirror the depth and networking density of an in-person conference. Planned programming elements included:

• Keynotes and panels from enterprise technology leaders across industries
• Experience reports from organizations including KeyBank, Deloitte, T-Mobile, and Microsoft
• Breakout sessions covering DevOps transformation at scale in large, complex organizations
• Virtual book signings with well-known DevOps authors
• Interest-based video networking, allowing attendees to select and engage directly with other attendees or speakers
• Birds-of-a-Feather gatherings to connect practitioners with shared challenges or interests
• Lean Coffee workshops for participant-driven discussion and interchange
• Virtual Happy Hours for informal networking
• A community space for spontaneous gatherings and hallway-style conversations

A key design decision was using pre-recorded keynotes paired with live Slack Q&A tracks and AMA (Ask Me Anything) sessions, giving attendees flexibility to consume content asynchronously while still enabling real-time interaction with speakers.

Lessons from Virtual DOES London 2020

The virtual Las Vegas event was directly informed by feedback from the DevOps Enterprise Summit London 2020, which had already run in virtual format. Attendees of the London event offered detailed reflections on what worked:

“COVID-adapted conferences have had a hard time arranging Q&A and networking. The DevOps Enterprise Summit Virtual #DOES20 has really delivered on that. Pre-recorded keynotes with live Slack ask-the-speaker tracks as well as AMA sessions have been really helpful.”

— Ferrix Hovi, Lead DevOps and Agile Coach, Siili Solutions

“I’ve been in person to 2017 DevOps Enterprise Summit London, and I have to say that I have enjoyed this virtual experience more. It was easier to keep track of what is going on, to engage with other attendees in the Zoom sessions, I had more ‘hallway’ conversations than 3 years ago. And the talks have been just superb.”

— Jiří Klouda, Technology Leader, SRE, Cisco Meraki

“I absolutely loved the whole thing. Seeing what others were learning in the Slack channels helped point me towards new ideas I hadn’t thought of before. I got opportunities to talk to fellow attendees and pages of notes. There were so many people excited to talk about the things I’m excited about!”

— Daniel Cahill, Software Engineer, Ontario Systems

“If you’re curious about the latest on DevOps in the real world, you simply can’t get better than #DOES, and this year was no exception!”

— Steve Pereira, Founder, Visible

Gene Kim on Replicating the Conference Experience Virtually

Gene Kim, founder of IT Revolution and co-author of The Phoenix Project, The DevOps Handbook, and Accelerate, addressed the challenge of translating in-person conference value to an online format:

“Great physical conferences are magical — you learn from incredible talks, feel surrounded by the best in the game, and find fellow travelers who share similar goals and experience similar struggles to conquer together. The connections I have made at conferences often lead to lifelong friendships and changed my career. We’re so proud that we were able to create these experiences for our attendees in our first Virtual DevOps Enterprise Summit in June — we’re now planning our second virtual event this year, and we’re aiming to make it even better than our first!”

— Gene Kim, Founder, IT Revolution

About DevOps Enterprise Summit

DevOps Enterprise Summit is a conference specifically designed for technology leaders and practitioners at large, complex organizations implementing DevOps principles and practices. Unlike practitioner-focused events that emphasize individual tooling or technical skills, DOES centres on organizational transformation — the leadership patterns, operating models, and cultural shifts required to adopt DevOps at enterprise scale.

Event programming emphasizes next-generation operations and infrastructure, as well as the change management practices needed to lead widespread transformation efforts across large, often regulated industries.

About IT Revolution

IT Revolution assembles technology leaders and practitioners through publishing, events, and research. The organization’s stated goal is to elevate the state of technology work, quantify the economic and human costs of suboptimal IT performance, and improve the professional lives of people working in technology.

For sponsorship enquiries related to the event, IT Revolution directed interested parties to Molly Coyne, Director of Corporate Sponsorship, at mollyc@itrevolution.com.

Cloud Computing’s Pandemic-Era Inflection Point

The COVID-19 pandemic forced a sudden, large-scale shift in how businesses operate. Social distancing requirements and widespread office closures pushed organizations — many of which had been cautiously piloting remote-work strategies — to make cloud infrastructure a core operational necessity almost overnight.

As Danny Vena wrote in a Motley Fool piece at the time: “Remote work and videoconferencing have combined to cause a notable acceleration in the adoption of cloud computing, a trend that was already well underway.” The pandemic did not create enterprise cloud adoption; it compressed what might have been years of gradual migration into a matter of months.

For DevOps engineers and platform teams, the practical implications were immediate: organizations that had already invested in cloud-native architectures, CI/CD pipelines, and infrastructure-as-code were far better positioned to scale remote capacity quickly. Those still running predominantly on-premises workloads faced a much steeper climb.

Amazon Web Services as a Bellwether

Amazon Web Services (AWS) is widely cited as both the pioneer and the leading provider in the public cloud market. The Motley Fool analysis noted that AWS revenue grew more than 36% in 2019, and framed the broader cloud industry as a “massive multiyear digital transformation” that was still in relatively early stages as of mid-2020.

AWS’s position matters to engineers not just as a market signal but as a de facto standard: when AWS launches or deprecates a service, the ecosystem — tooling, third-party integrations, certifications — shifts accordingly. The pandemic-era growth underscored why cloud providers invested heavily in expanding global region capacity during this period.

The Cloud Stack: SaaS, PaaS, IaaS, and Beyond

One useful aspect of cloud computing ETF fund definitions is that they often force a precise categorization of what “cloud computing” actually encompasses. The Global X Cloud Computing ETF (Nasdaq: CLOU), which tracks the Indxx Global Cloud Computing Index, defines its investment universe across five distinct segments:

• SaaS (Software as a Service): Companies that license and deliver software over the internet on a subscription basis — think productivity suites, CRM platforms, and collaboration tools.
• PaaS (Platform as a Service): Providers that offer a managed platform for building and deploying software applications over the internet, abstracting away underlying infrastructure management.
• IaaS (Infrastructure as a Service): Vendors offering virtualized compute, storage, and networking resources on demand — the layer where most DevOps automation operates.
• Data Center REITs: Companies that own and manage the physical facilities — data centers and colocation sites — that underpin cloud infrastructure.
• Edge and Cloud Hardware: Manufacturers and distributors of the networking, compute, and storage hardware that makes both cloud and edge computing possible.

This taxonomy is a useful mental model for practitioners too. When scoping a cloud migration or selecting managed services, understanding which layer of the stack a vendor operates in helps clarify responsibility boundaries, SLA expectations, and operational overhead.

Two Cloud ETFs Worth Understanding

Global X Cloud Computing ETF (CLOU)

Launched by Global X ETFs, a New York-based ETF provider, CLOU seeks to track the Indxx Global Cloud Computing Index. The fund holds a diversified basket of companies across the SaaS, PaaS, IaaS, data center, and edge hardware segments described above. For engineers, the fund’s holdings at any given time offer a reasonable snapshot of which pure-play cloud companies are considered mature enough for institutional investment.

WisdomTree Cloud Computing Fund (WCLD)

WCLD tracks the BVP Nasdaq Emerging Cloud Index, which focuses specifically on emerging public companies primarily involved in cloud software and services. The fund is classified as non-diversified, meaning it can take larger positions in individual holdings than a diversified fund. The “emerging” focus means WCLD’s holdings tend to skew toward growth-stage vendors — companies whose platforms DevOps teams may encounter as newer entrants in the observability, security, developer tooling, or data pipeline spaces.

Why This Matters for Engineering Teams

Cloud ETF composition and performance aren’t just investor metrics — they reflect real market dynamics that affect the tooling and vendor landscape engineers work with every day:

• Vendor viability: Companies with strong revenue growth and institutional investment backing are more likely to sustain their products, offer enterprise support, and continue R&D investment.
• Market consolidation signals: When cloud ETFs add or drop holdings, it often reflects M&A activity or shifts in competitive positioning that can affect which platforms remain independently viable.
• Adoption curves: The composition of “emerging cloud” indices like the BVP Nasdaq Emerging Cloud Index can indicate which categories of tooling — say, cloud-native security or serverless observability — are reaching critical commercial adoption.

The Longer-Term Trend

The pandemic-driven cloud surge documented in mid-2020 was an acceleration of a pre-existing trajectory, not an anomaly. Organizations that adopted cloud infrastructure under pressure during COVID-19 have largely retained and expanded those workloads. For DevOps practitioners, this means continued investment in cloud-native skills, tooling, and architecture patterns remains strategically sound — independent of any individual ETF’s performance.

The fundamental drivers — elastic scaling, pay-per-use economics, managed services that reduce operational burden, and global reach — did not change during the pandemic. COVID-19 simply forced a faster reckoning with organizations that had been deferring cloud adoption decisions.

Original source reporting: ETF Trends. Motley Fool analysis cited is by Danny Vena. ETF details reflect information available as of the original publication date (July 2020); fund holdings, index methodology, and performance will have changed.

Understanding Debt Risk in Infrastructure Companies

Investor Howard Marks famously observed that the risk he truly worries about is not share price volatility, but the possibility of permanent loss of capital. One of the clearest early-warning signals for that kind of permanent loss is excessive debt. For capital-intensive infrastructure businesses — including renewable energy operators like TerraForm Power, Inc. (NASDAQ: TERP) — debt is an operational reality, but how much is too much?

This article breaks down the key metrics used to assess corporate debt risk, using TerraForm Power’s 2020 balance sheet as a concrete case study. Understanding these concepts is useful for any engineer or technical leader evaluating vendors, partners, or employers in capital-heavy industries such as cloud infrastructure, energy, and telecommunications.

Why Debt Is a Risk Factor

Debt is a legitimate growth tool. Borrowing allows companies to fund infrastructure buildouts, acquisitions, and expansion without immediately diluting shareholders. However, it introduces two major risks:

• Insolvency risk: If a company cannot service its debt, creditors can force bankruptcy proceedings.
• Dilution risk: To avoid bankruptcy, a company may issue new shares at depressed prices, permanently reducing the value of existing shareholders’ stakes.

Both outcomes are damaging. The first step in assessing debt risk is examining a company’s cash and debt positions together, rather than in isolation.

TerraForm Power’s Debt Position (as of March 2020)

According to the balance sheet data cited in the original Simply Wall St analysis:

• Total debt: US$6.99 billion (up from US$5.68 billion a year prior)
• Cash on hand: US$249.2 million
• Net debt: approximately US$6.74 billion

On the liabilities side:

• Short-term liabilities (due within 12 months): US$740.9 million
• Long-term liabilities (due beyond 12 months): US$7.43 billion
• Short-term receivables: US$190.7 million

Netting cash and receivables against total liabilities leaves a shortfall of approximately US$7.7 billion — against a company market capitalisation of roughly US$4.54 billion at the time. That means the liabilities were substantially larger than the entire market value of the company.

Key Ratios for Measuring Debt Burden

Financial analysts use two primary ratios to contextualise a company’s debt load relative to its operational performance:

1. Net Debt to EBITDA

This ratio compares net debt to earnings before interest, taxes, depreciation, and amortisation (EBITDA). It answers the question: how many years of operating earnings would it take to pay off the debt?

TerraForm Power’s net debt to EBITDA ratio was reported at 10.9x — a high figure by most industry standards. A ratio above 4–5x is generally considered elevated in asset-heavy sectors.

2. Interest Coverage Ratio (EBIT / Interest Expense)

This ratio measures how comfortably a company can pay the interest on its debt from operating earnings (EBIT — earnings before interest and tax). A ratio below 1.5x is typically a warning sign.

TerraForm Power’s interest coverage ratio was reported at 0.45x, meaning its operating earnings covered less than half of its interest obligations. This is a significant red flag.

EBIT Trend and Free Cash Flow

Compounding the concern, TerraForm Power’s EBIT declined by approximately 4.7% over the prior year, according to the source analysis. A shrinking earnings base makes it progressively harder to service a growing debt load.

However, one genuinely positive data point from the analysis is free cash flow generation. Over the three years preceding the report, TerraForm Power’s free cash flow exceeded its reported EBIT — suggesting that accounting profits were conservatively stated relative to actual cash collected. Strong free cash flow is critical because debt must ultimately be repaid in cash, not accounting earnings.

Summary Assessment

Based on the figures reported in mid-2020:

The combination of a very high leverage ratio, weak interest coverage, and declining operating earnings represents a meaningful risk profile. The strong free cash flow conversion is a mitigating factor, but does not fully offset the structural concerns.

Why This Matters Beyond Finance

For DevOps engineers and technical leaders, understanding a vendor’s or employer’s financial health is increasingly relevant. Companies carrying unsustainable debt loads may:

• Cut infrastructure and tooling budgets unexpectedly
• Reduce headcount in engineering and operations teams
• Delay or cancel platform modernisation initiatives
• Become acquisition targets, leading to technology stack consolidation or abandonment

Knowing how to read a balance sheet — even at a high level — helps technical professionals make better career, vendor, and partnership decisions.

Disclaimer

This article is adapted from a Simply Wall St analysis and is intended for general informational purposes only. It does not constitute financial or investment advice. All figures cited are drawn from the original source and reflect publicly reported data as of mid-2020. Readers should conduct their own due diligence before making any investment decisions.

The Disaster That Started the Conversation

In April 2018, TSB migrated billions of customer records onto a new core-banking platform. The project had been in planning for over 18 months and involved more than 1,000 professionals. Within 20 minutes of the cutover, customers began reporting missing savings balances and incorrect transaction histories. Weeks of service disruption followed, costing the bank an estimated £330 million and driving approximately 80,000 customers to switch to competitors.

The post-incident analysis pointed to a single, preventable root cause: insufficient rigorous testing before go-live.

TSB is not an isolated case. Across industries, digital leaders facing executive pressure and fixed delivery deadlines routinely compress or skip testing phases—especially when complex legacy systems are involved. The result is almost always the same: defects surface in production, where fixing them is far more expensive and damaging than catching them earlier.

Why Testing Gets Treated as an Afterthought

In traditional waterfall delivery models, testing sits at the end of the pipeline. By the time testers receive a build, the delivery deadline is imminent and any defects discovered are unlikely to be fully resolved before go-live. This creates a self-defeating cycle:

• Testers flag issues late in the cycle.
• Business stakeholders override the concerns because timelines are fixed.
• The product ships with known or unknown defects.
• Incidents occur in production at far greater cost than earlier remediation would have required.

Testing is perceived as the “troublemaker”—the discipline that causes delays rather than the one that prevents them. Reframing that perception is the first step toward more resilient delivery.

How Agile Transforms the Testing Mindset

Agile methodology fundamentally changes when and how testing happens. Rather than a single testing phase at the end of a project, testing is distributed across the entire software development lifecycle (SDLC):

• Testing in sprints: Testers are embedded within cross-functional Agile teams and participate in every sprint, not just the final one.
• Continuous feedback: Each sprint’s test results directly inform the scope and priorities of the next sprint, creating a tightening feedback loop.
• Shared ownership: The whole-team approach means every team member—developer, business analyst, tester—is responsible for product quality, not just the QA function.
• Broader tester skills: Testers in Agile environments need strong communication, collaboration and exploratory-testing skills alongside their technical expertise, because they are active participants in sprint planning and retrospectives.

This shift means that defects are found and resolved when they are cheapest to fix: during development, not after deployment.

Test Automation: The Critical Enabler

Embedding testers into Agile teams is necessary but not sufficient. The volume of testing required to support continuous delivery at pace makes manual-only testing unsustainable. Test automation is what allows teams to move quickly without sacrificing coverage.

What to Automate

• Regression testing: Running the full suite of existing tests against every new build manually is prohibitively slow. Automated regression suites catch regressions overnight or within a CI/CD pipeline run.
• Smoke testing: A fast automated smoke test validates that a new build is stable enough for deeper testing before human effort is invested.
• API and integration tests: Automated contract and integration tests verify that services communicate correctly as codebases evolve.

Freeing testers from repetitive manual regression work allows them to focus on higher-value exploratory testing—the kind of creative, scenario-driven testing that automated scripts cannot easily replicate.

The ROI of Automation

According to the original case study, a large telecoms provider previously required two full-time testers and two weeks to execute 8,000 tests at a cost of approximately £7,000 per cycle. After implementing automated testing, the same test suite ran overnight at a fraction of that cost. The two testers were redeployed to process improvement and exploratory testing—adding direct value to the delivery pipeline rather than executing repetitive checks.

Note: This specific figure comes from the original devopsonline.co.uk source and has not been independently verified.

Test automation requires upfront investment in people, tooling and process design. It also demands sustained discipline: automation suites rot if they are not actively maintained alongside the product they test. Teams that treat automation as a one-time project rather than an ongoing engineering discipline consistently see their suites degrade in value over time.

Dynamic Test Automation: Letting Data Drive the Tests

Standard test automation typically executes test cases in a fixed, predetermined order. Dynamic Test Automation takes a different approach: the test data itself carries indicators that determine which tests run and what the expected outcome should be. This surfaces hidden dependencies that linear test execution would miss.

“If we always work through our automated tests in the order 1, 2, 3, 4, 5 we will never find out what happens if we test 1, 2, 3, 5, 4.”

Adam Pettman, 2i

Because unknown dependencies are more likely to be exposed when test execution order varies, dynamic approaches tend to find defect categories that traditional scripts would miss entirely.

Generating Test Data

Dynamic automation requires quality test data. Live production data is usually unsuitable for test environments for privacy and compliance reasons. Two practical approaches exist:

Approach 1 – Anonymisation

Live data is transformed so that personally identifiable information (PII) is replaced with realistic but fictional equivalents. For example, “Bob Smith, Accountant” becomes “James Brown, Finance Associate.” The data relationships and realistic value distributions are preserved, improving test coverage compared with purely synthetic data. The limitation is scale: anonymising data consistently across large relational databases with many foreign-key relationships is complex and may not be feasible in every context.

Approach 2 – Generating Data from Scratch

Test data is created synthetically, working with Product Owners and business stakeholders to ensure all key scenarios are represented. Brief workshops to define the required data rows require an initial time investment, but that investment pays back quickly: synthetic data that covers edge cases catches defects before User Acceptance Testing (UAT), dramatically reducing the number of surprises at that stage.

Breaking the Data Intentionally

A complete test strategy must verify not only that valid inputs produce correct outputs (the “happy path”) but also that the system handles invalid or unexpected inputs gracefully (the “sad path”). Introducing deliberately malformed or boundary-violating data in a controlled way—sometimes called negative testing or fault injection—validates that the system catches errors correctly rather than silently producing wrong results.

Case Study: Dynamic Test Automation for an Eco-Tech Start-Up

Testing firm 2i partnered with a cloud-native start-up to embed Dynamic Test Automation into their delivery pipeline. The engagement spanned the full team, from CTO to junior developer. The technology choices made in this implementation illustrate how the theory translates into practice.

Generating Test Data with Python

Test data was generated from scratch using Python scripts that produced a series of JSON files ready for upload through the application. This gave the team full control over the data’s structure, volume and variation without any dependency on production data or anonymisation tooling.

Breaking the Data with Python

A separate Python script randomly injected invalid values into the JSON files. Files with injected values were tagged so that the test framework knew to expect failures when processing them—providing a clean mechanism for sad-path testing without manual intervention.

UI Test Automation with Cypress and Cucumber

Cypress was selected as the browser automation framework to interact with the web application and drive test execution. All test cases were written in BDD (Behaviour-Driven Development) format using Cucumber, which allowed test scenarios to be expressed in plain language (Gherkin syntax) while the underlying implementation remained hidden from business stakeholders. This enabled non-technical Product Owners to read, review and even contribute to test case design.

Test cases covered both happy paths (valid JSON files processed successfully) and sad paths (files tagged as “Broken” rejected as expected). The full suite formed the basis of the ongoing regression pack.

Embedding in the CI/CD Pipeline

The complete Dynamic Test Automation suite was integrated into the team’s GitOps CI/CD pipeline. Every commit triggers the test suite automatically, giving the engineering team continuous confidence that new code has not broken existing functionality—without slowing down their deployment velocity.

Where Quality Assurance Is Heading

Test automation will continue to expand its scope. Several trends are already visible:

• Low-code and no-code automation tools are lowering the barrier to entry, enabling teams without deep scripting expertise to build and maintain automated test suites.
• AI-assisted testing is beginning to augment test case generation, defect prediction and visual regression detection—though this area is still maturing.
• Shift-left security testing (integrating security checks earlier in the pipeline) is following the same pattern that functional testing has undergone with Agile.

However, automation does not eliminate the need for skilled testers. Human expertise remains essential for:

• Defining relevant test scenarios and acceptance criteria.
• Exploratory testing that probes the edges of expected behaviour.
• Overseeing automation suite quality and preventing test rot.
• Translating business requirements into testable conditions.

The organisations that will deliver the most reliable software at the highest velocity are those that combine strategic test planning, well-designed test cases, disciplined automation and skilled QA engineers—all embedded directly in the delivery pipeline from the first sprint, not bolted on at the end.

Original article by Adam Pettman, first published on devopsonline.co.uk. Implementation referenced was delivered by 2i.

Cloud Computing Becomes Mission-Critical Infrastructure

By mid-2020, cloud computing had shifted from a strategic priority to an operational lifeline. The COVID-19 pandemic forced enterprises, governments, and educational institutions to accelerate digital transformation plans that had previously been projected to unfold over several years. Remote work, distance learning, and the sudden shutdown of physical offices placed an enormous burden on cloud infrastructure — and exposed how underprepared many organizations were.

Wedbush Securities analyst Dan Ives captured the moment clearly in a research note from June 2020:

“With remote learning, work from home and more applications and technology needing to be accessed during this ‘new normal’… the shift to cloud computing over the last few years is now the ‘hearts and lungs’ core technology and infrastructure enabling companies and governments globally to operate smoothly during this unprecedented environment.”

Dan Ives, Wedbush Securities

Ives specifically highlighted front-line collaboration tools — Zoom, DocuSign, Citrix, Microsoft Teams, and Slack — as the visible face of the pandemic response, while pointing to the hyperscale public and hybrid cloud providers (AWS, Microsoft Azure, and Google Cloud) as the foundational infrastructure enabling those tools to function at scale.

Cloud Spending Bucked the 2020 IT Downturn

The broader IT industry took a significant hit in 2020. Research firm Gartner projected that global IT spending would fall approximately 8 percent to $3.4 trillion as a result of the pandemic-driven economic recession. Cloud computing, however, moved in the opposite direction: Gartner forecast cloud spending to increase by roughly 19 percent over the same period.

This divergence reflected a broader structural shift. Cloud migrations and infrastructure modernization projects that had been on multi-year roadmaps were suddenly being fast-tracked. As Ives noted, many enterprises found themselves “caught flat-footed with a lack of cloud-enabled functionality” — a reality that compressed timelines dramatically.

A Turning Point for Enterprise Cloud Adoption

Wedbush’s analysis suggested that the pandemic represented a genuine inflection point — not just a temporary spike in cloud usage. Prior to the pandemic, the firm’s baseline forecast projected that cloud workloads would grow from approximately 33 percent of enterprise workloads to 55 percent by 2022. By mid-2020, Ives believed those targets could be hit a full year ahead of schedule.

“We believe this coronavirus pandemic is a key turning point in the technology world around deploying cloud-driven environments… With our expectations of a trillion dollars to be spent in the cloud over the next decade, there will be many beneficiaries — cybersecurity, data center plays, cloud stack/enablers, hybrid cloud, applications — across the technology landscape.”

Dan Ives, Wedbush Securities

Microsoft Azure and AWS were identified as the two vendors best positioned to capture the sustained acceleration in cloud infrastructure spending both during and after the pandemic.

Why Cloud Startups Thrived in This Environment

Venture-backed cloud startups were uniquely positioned to benefit from this acceleration. With hyperscalers providing the foundational infrastructure, startups were free to build specialized tooling, platforms, and services on top of it — targeting specific pain points that large cloud vendors were too generalized to address effectively.

Key areas where cloud startups found traction in 2020 included:

• Cloud security and zero-trust networking: As enterprise perimeters dissolved with remote work, demand for cloud-native security tooling surged.
• Data management and observability: Enterprises moving workloads to the cloud needed new ways to monitor, govern, and extract value from distributed data.
• Multi-cloud and hybrid cloud management: Few enterprises operated on a single cloud, driving demand for abstraction and orchestration layers.
• Developer tooling and CI/CD: Software delivery pipelines needed to scale rapidly to support remote engineering teams.
• Cloud cost optimization: As cloud bills grew quickly, FinOps and cost visibility tools became a priority for CFOs.

The Broader Context: A Decade of Cloud Investment Ahead

The mid-2020 analysis from Wedbush framed the pandemic not as a short-term demand spike but as an accelerant for a decade-long investment cycle. For DevOps engineers, platform teams, and infrastructure architects, this meant that architectural decisions made in 2020 — around containerization, Kubernetes adoption, serverless computing, and multi-cloud strategy — would have long-lasting consequences.

Cloud startups entering the market in 2020 were building against this backdrop: enterprises newly committed to cloud-first strategies, hyperscalers investing heavily in developer ecosystems, and a venture capital market still willing to fund ambitious infrastructure bets.

For a curated list of the specific startups identified by CRN as the hottest cloud companies to watch in mid-2020, refer to the original CRN coverage.

Key Takeaways for DevOps Teams

• The COVID-19 pandemic compressed enterprise cloud adoption timelines by one to two years relative to pre-pandemic projections.
• Cloud spending grew even as overall IT budgets contracted — a rare counter-cyclical dynamic that signaled structural demand rather than discretionary spending.
• Hyperscalers (AWS, Azure, Google Cloud) provided the foundation, but startups addressed specialized gaps across security, observability, cost management, and developer experience.
• Enterprises caught without cloud-ready infrastructure in 2020 faced immediate operational risk — a lesson that drove lasting changes in how organizations approach cloud strategy.
• The long-term investment thesis for cloud — framed around a trillion dollars in spending over the following decade — created a durable opportunity for well-positioned startups.