Verizon Partners with Google Cloud to Modernize Customer Contact Centers

Verizon announced a pilot program to deploy Google Contact Center Artificial Intelligence (CCAI) with the goal of delivering more intuitive, efficient customer experiences across voice and chat channels. The partnership reflects a broader push by Google Cloud to position its AI tooling as infrastructure for telecom and enterprise contact centers.

How Google Contact Center AI Works

At the core of the offering is natural language understanding (NLU), which allows customers to state or type their requests in plain language rather than navigate layered IVR menus. When a customer contacts Verizon by phone or direct chat, the AI interprets the intent and routes or resolves accordingly — reducing friction at the first point of contact.

According to a Google Cloud statement cited in the original report, the technology is intended to “help empower shorter call times, quicker resolutions, and improved outcomes for customer satisfaction.”

When a call escalates to a human agent, Google CCAI continues to contribute by:

• Providing real-time agent assist — surfacing relevant knowledge base articles and suggested responses during the live interaction
• Locating relevant customer history and context automatically
• Reducing the cognitive load on agents so they can focus on complex or sensitive issues

The Role of Dialogflow

Much of the experience is powered by Dialogflow, Google Cloud’s platform for building conversational agents across voice, chat, and messaging channels. Unlike older bot frameworks that modeled human conversations as strictly linear flows, Dialogflow is designed to handle multi-turn, dynamic conversations — more closely approximating how human agents actually interact with customers.

Dialogflow supports integration across a wide range of channels and can manage multiple concurrent requests, which is critical for high-volume contact center environments.

Industry Analyst Perspective

Irwin Lazar, Vice President and Service Director at Nemertes Research, told UC Today that the deal is a logical fit, noting that many contact center platform providers already integrate Google Cloud’s contact center technology into their own offerings. This means Verizon is building on a technology foundation that has already achieved meaningful adoption across the industry.

Conversational AI Will Augment — Not Replace — Human Agents

Seth Miller, CEO of VerbalWare and a chatbot industry expert, offered a measured take on the partnership’s potential. He described the Verizon–Google deal as “a win all around,” particularly in the context of the COVID-19 pandemic, which strained customer service teams across industries while simultaneously raising customer expectations.

“COVID has, and will continue to be, a wake-up call for the economy. Customer service teams have shrunk, but customers expect a superlative experience.”

Seth Miller, CEO, VerbalWare

Miller argued that conversational AI will not fully replace human agents but can absorb a large volume of routine, repetitive queries — freeing agents to handle higher-complexity interactions that genuinely require human judgment. He also stressed that companies deploying these systems will need to invest in retraining agents to design conversation flows and work alongside NLU platforms effectively.

Broader Google Cloud Enterprise Momentum

The Verizon announcement was part of a wider wave of enterprise commitments to Google Cloud. Other organizations reported to have adopted Google Cloud technology around the same period include Deutsche Bank, Goldman Sachs, and Telefónica — one of the world’s largest telecom operators by subscriber count.

At Google Cloud Next ’20, Google also announced BigQuery Omni, a multi-cloud analytics solution built on the Anthos hybrid and multi-cloud platform. BigQuery Omni allows users to run analytics workloads against data stored across multiple cloud environments using a consistent interface — addressing a real operational challenge for enterprises with data distributed across AWS, Azure, and Google Cloud.

“We’re honored to see organizations across every industry place their trust in Google Cloud, as we partner to solve real-world business problems.”

Thomas Kurian, CEO, Google Cloud

Key Takeaways for DevOps and Platform Engineers

• Dialogflow is the underlying conversational AI platform. If you’re evaluating NLU frameworks for contact center or chatbot use cases, it’s worth assessing alongside alternatives such as Amazon Lex and Microsoft Bot Framework.
• Google CCAI is designed to integrate with existing telephony infrastructure, not replace it wholesale — making incremental adoption feasible.
• Real-time agent assist is increasingly table-stakes for enterprise contact center AI — evaluate vendors on the quality of their suggestion latency and knowledge retrieval accuracy.
• BigQuery Omni signals Google’s intent to compete for analytics workloads even when data lives outside GCP — a significant architectural consideration for multi-cloud strategies.
• Workforce planning matters: AI deployment in contact centers requires parallel investment in agent training and conversation design skills, not just technology procurement.

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.

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.

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.

Researchers Len Bass, Dr. Ingo Weber, and Dr. Liming Zhu have offered a widely cited academic definition: DevOps is “a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production while ensuring high quality.”

The Problem DevOps Solves

To understand what DevOps changes, it helps to understand the friction it replaces. In a traditional software organisation, developers and operations engineers work in separate silos with different priorities, tools, and mental models of the system.

The Developer’s Experience Without DevOps

Developers write code in a local or shared development environment. Once a batch of changes is ready, it gets handed off to operations for deployment — a process that might happen only once or twice a month. The developer moves on to the next feature while that batch sits in a queue.

When the code finally reaches production, it can behave differently than it did in development. Subtle environment differences — configuration, library versions, network rules — cause errors. The developer must now context-switch back to code they wrote weeks ago to diagnose and fix a problem they can barely remember writing.

The Operations Team’s Experience Without DevOps

The operations team owns the production environment. They manage servers, maintain uptime, and are ultimately accountable when something breaks in front of customers. Periodically, they receive a large bundle of new code from developers and must integrate it into a live system with as little disruption as possible.

Because deployments are infrequent and each one is large, they carry significant risk. Operations engineers often spend considerable time coaxing new code to behave correctly in an environment they maintain but did not design the code for. If errors follow a deployment, it is the operations team that must respond — even when root cause lies in code they did not write.

This structural tension — developers optimising for speed, operations optimising for stability — is the core problem DevOps addresses.

How a DevOps Team Works Differently

DevOps removes the handoff wall. Developers and operations engineers collaborate throughout the entire development lifecycle: design, coding, testing, deployment, and post-release monitoring. The key shifts are:

• Smaller, more frequent releases. Instead of batching weeks of work into a single deployment, teams ship small increments of code continuously. Smaller changes are easier to test, easier to debug, and easier to roll back.
• Automation first. Manual steps — building, testing, provisioning infrastructure, deploying code — are automated wherever possible. This reduces human error and makes the pipeline repeatable and auditable.
• Infrastructure as Code (IaC). Infrastructure is defined in version-controlled configuration files rather than configured manually. Tools like Terraform, Ansible, and Puppet make environments reproducible, closing the gap between development and production.
• Continuous monitoring. Application performance, error rates, and user experience are measured in near real-time. Both developers and operations engineers are responsible for acting on that data.
• Shared ownership. The team shares responsibility for the full lifecycle of a service, reducing the blame culture that arises from siloed work.

Core DevOps Principles

Several principles underpin the DevOps way of working:

• Continuous Integration (CI): Developers merge code changes into a shared repository frequently. Each merge triggers an automated build and test run, surfacing integration problems early.
• Continuous Delivery (CD): Every change that passes automated tests is automatically prepared for release to production. The decision to deploy can be made at any time.
• Continuous Deployment: An extension of CD where every passing change is automatically deployed to production without manual approval gates.
• Feedback loops: Short, fast feedback loops between production behaviour and developer action are central. Monitoring and alerting tools provide this signal.
• Blameless culture: Post-incident reviews focus on systemic improvements rather than individual blame, encouraging transparency and learning.

A Brief History of DevOps

DevOps did not emerge from a single moment. It evolved from the Agile System Administration and Enterprise Systems Management (ESM) movements that gained momentum in the mid-2000s, as practitioners began questioning why Agile principles applied inside development teams were not extending to operations.

Key milestones include:

• 2008 — Velocity Conference: O’Reilly’s Velocity conference, focused on web performance and operations, became a gathering point for engineers interested in developer-operations collaboration. Talks at the 2008 and 2009 editions helped crystallise the ideas that would become DevOps.
• 2009 — DevOpsDays, Ghent: Agile practitioner and project manager Patrick Debois organised the first DevOpsDays conference in Belgium, giving the movement its name and a dedicated community.
• 2012 — First State of DevOps Report: Alanna Brown at Puppet launched what became an annual industry survey tracking DevOps adoption, practices, and outcomes. Subsequent editions, produced in partnership with DORA (DevOps Research and Assessment), provided data on the business impact of DevOps practices.

Essential DevOps Toolchains

DevOps practices depend on integrated toolchains — sets of tools that automate and connect different stages of the delivery pipeline. The major categories are:

What DevOps Is Not

DevOps is frequently misunderstood. It is not a job title, a specific product, or a team you stand up and declare done. Hiring a “DevOps engineer” or deploying a CI/CD tool does not make an organisation DevOps. The tools support the practices, and the practices require a genuine cultural shift: shared ownership, trust between teams, tolerance for experimentation, and a commitment to learning from failure.

Why DevOps Matters

Organisations that successfully adopt DevOps practices can deploy code more frequently, recover from failures faster, and maintain higher levels of service stability. The underlying reason is structural: by removing handoff delays, automating repetitive work, and closing feedback loops between production behaviour and engineering decisions, teams spend more time on valuable work and less time on rework, incident response, and coordination overhead.

DevOps is not a destination. It is an ongoing discipline — one that rewards teams willing to continuously examine their own processes and improve them.

PlanetScaleDB for Kubernetes: Managed Databases Inside Your Own Cluster

PlanetScale announced the beta release of PlanetScaleDB for Kubernetes, a solution that lets organizations host their databases inside their own network perimeter while still benefiting from a fully managed, SaaS-like operational experience. Deployment is handled through the PlanetScale control plane and a Kubernetes operator, aiming to reduce the operational burden of backups, high availability, and software upgrades to just a few clicks.

PlanetScaleDB for Kubernetes is a MySQL-compatible database-as-a-service designed for teams running distributed, containerized workloads on Kubernetes—whether on-premises or in a public cloud.

Built on Vitess: A Battle-Tested CNCF Project

The underlying engine for PlanetScaleDB is Vitess, a top-level Cloud Native Computing Foundation (CNCF) open source project. Vitess was originally developed at YouTube to handle massive MySQL sharding at scale and has since been adopted by companies including GitHub, HubSpot, Slack, and Square to serve millions of queries per second.

By building on Vitess, PlanetScaleDB inherits horizontal sharding, connection pooling, and topology management capabilities that are difficult to implement with standard MySQL deployments. Organizations that need MySQL compatibility but require Kubernetes-native scalability are the primary target audience.

Why Bring the Database Into the Kubernetes Cluster?

As Kubernetes adoption has accelerated, a common architectural tension has emerged: application workloads run inside a Kubernetes cluster while the database lives outside it, often in a managed cloud service or a separate VM-based environment. This separation introduces network latency, complicates security policy enforcement, and creates operational silos between application and data teams.

PlanetScaleDB for Kubernetes addresses this by co-locating the database with the application workloads inside the same cluster. According to PlanetScale, running the database adjacent to microservices can reduce query latency by up to 20 milliseconds—though this figure will vary significantly depending on existing network topology and workload characteristics.

Key Features

• Efficiency: Co-locating databases and applications in the same Kubernetes cluster eliminates the need for complex cross-network infrastructure.
• Performance: Reduced network hops between microservices and the database layer lower query latency.
• Reliability: PlanetScaleDB manages software upgrades, hardware failure recovery, and network partition handling without requiring application downtime.
• Security: Because data remains within the customer’s own network perimeter, it is easier to enforce internal security policies and compliance requirements.
• Ease of Operations: The PlanetScale control plane and Kubernetes operator handle day-two operations—backups, scaling, and failover—as a managed service.
• MySQL Compatibility: Applications that already use MySQL drivers and tooling can connect without changes to the application layer.

How the Operator Model Works

PlanetScaleDB for Kubernetes uses the Kubernetes Operator pattern: a custom controller watches for PlanetScaleDB custom resources and reconciles the actual cluster state to match the desired state declared in those resources. This means database provisioning, scaling, and lifecycle management are expressed as Kubernetes manifests and handled natively by the Kubernetes API server, rather than through a separate out-of-band management tool.

The PlanetScale control plane provides a management UI and API layer on top of the operator, delivering the simplified “few clicks” provisioning experience the company describes for teams that do not want to write raw Kubernetes manifests.

Target Use Cases

• Regulated industries where data residency and network perimeter requirements prevent use of external managed database services.
• Hybrid cloud environments where workloads span on-premises Kubernetes clusters and public cloud infrastructure.
• High-throughput transactional workloads that need horizontal sharding beyond what a single MySQL instance can provide.
• Teams migrating from VM-based MySQL to a Kubernetes-native stack without rewriting application database logic.

Availability

At the time of this announcement (June 2020), PlanetScaleDB for Kubernetes was in beta. For current availability, pricing, and documentation, visit planetscale.com directly, as the product has continued to evolve since this announcement.

PlanetScale can also be followed on Twitter at @planetscaledata.

NFV Has Laid the Groundwork for Cloud-Native Telecoms

Communications service providers (CSPs) have been building toward cloud-native architectures for years, and the foundation they are building on is Network Functions Virtualization (NFV). According to Gabriele Di Piazza, VP of Solutions for VMware Telco Cloud Edge, the journey began in earnest with 4G. “4G kickstarted the shift towards virtualization and gave the operators experience,” he explained. New additions and expansions in 4G networks have been running in virtualized or cloud-based environments, making a fully physical packet core largely obsolete for new deployments.

A prominent example is Vodafone, which had been on its virtualization journey for more than five years at the time of reporting. Working with VMware, it completed the roll-out of its NFV Infrastructure (NFVi) platform, supporting more than 900 virtual network functions (VNFs) across 21 markets. That scale of deployment represents the operational muscle CSPs have developed through NFV — muscle that now needs to flex in a very different direction.

The Jump from VNFs to CNFs Is Not a Simple Swap

The move from virtual network functions (VNFs) to cloud-native functions (CNFs) is frequently mischaracterized as a straightforward upgrade. Di Piazza pushed back on that assumption directly: “The transition from virtualized functions to cloud native has a lot of implications… as applications are disaggregated into microservices, for the first time in many years there’s a need for the complete re-architecting of applications — it’s not a case of ‘I had a VNF and now I have a CNF and the problem is solved.'”

This architectural shift carries significant operational consequences. Moving to containerized, microservices-based network functions means operators must adopt CI/CD (continuous integration/continuous delivery) pipelines and Platform-as-a-Service (PaaS) deployment models that are fundamentally different from how they managed monolithic VNFs. The transformation is not just technical — it runs across the entire supply chain and introduces a significant skills gap at the human level.

Three Stars Must Align for Cloud-Native Telecoms to Work

Di Piazza outlined three interdependent conditions that must all be in place simultaneously before telcos can operate cloud-native networks at production scale:

1. Platform vendor maturity: Cloud infrastructure vendors — including VMware and its competitors — must deliver production-grade telco cloud platforms. Di Piazza was relatively confident here: “Sometimes I think this is the least of the problems because we are technology companies — this is what we do.”
2. CNF readiness from network function vendors: The containerized versions of core network functions need to be production-ready. At the time of the briefing, Di Piazza was candid: “Today CNFs, the containerized functions, are either barely ready or still in the process of being released.” Significant R&D work remained before those functions would be fit for telco production environments.
3. Carrier operational maturity: Operators themselves need to develop the Kubernetes expertise, CI/CD workflows, and cultural readiness to run cloud-native operations. This includes everything from retraining engineering staff to rethinking how software lifecycle management works at scale.

“If all three things are not in place at the same time — if you miss only one of those three — then you have a gap,” Di Piazza warned. He used a concrete illustration to convey the operational challenge: “Imagine deploying a network function continuously into tens of thousands of sites, updating these, maintaining a fresh version in a world where there is a new Kubernetes version every quarter” — that represents an entirely new operational paradigm for network engineers accustomed to long-lifecycle hardware and software deployments.

VMware’s Strategic Acquisitions Filled the Cloud-Native Gap

A few years prior to this briefing, VMware had limited credibility in the Kubernetes and cloud-native space. A series of acquisitions changed that trajectory. Di Piazza highlighted the purchases of Heptio (a Kubernetes-focused company co-founded by two of Kubernetes’ original creators), Pivotal Software (known for its Cloud Foundry PaaS platform), and Bitnami (an application packaging and deployment platform) as central to VMware’s cloud-native pivot.

“The transition towards the cloud native and containerized world matches really well with our recent acquisitions,” he said, adding that VMware was investing in automation, orchestration, and intelligence to build a more complete end-to-end portfolio. “Things are about to become way more complicated,” he acknowledged, positioning VMware’s portfolio evolution as a direct response to that increasing complexity.

VMware Telco Cloud Automation: From Project Maestro to GA

The product outcome of this portfolio evolution was VMware Telco Cloud Automation, previously known internally as Project Maestro. According to Di Piazza, it became generally available in February 2020. The platform is designed to address the orchestration and lifecycle management challenges that arise when deploying network functions not just in centralized data centers but across distributed edge locations — including central offices (near edge) and radio access network (RAN) sites (far edge).

“You have centralized sites and distributed sites, near edge in the central office or far edge all the way to the RAN, and with the RAN you have tens of thousands of endpoints — think about the impact that will have on orchestration and automation,” Di Piazza noted. Managing software lifecycle at that scale, with Kubernetes release cadence as a constant variable, is precisely the problem VMware’s telco cloud automation tooling aims to solve.

CSPs Are Becoming Their Own Systems Integrators

One of the more strategically significant observations from Di Piazza concerned the changing role of carriers themselves. Historically, CSPs relied heavily on large systems integrators to pull together complex network deployments. That model is shifting.

“The carriers are, de facto, becoming their own systems integrator as they undertake this digital transformation,” he said. “The network is at the heart of that transformation — this is their factory — and they are building those integration skills in-house.” This insourcing of integration capability is both a response to the complexity of cloud-native deployments and a strategic move to retain control over their most critical infrastructure.

Key Takeaways for DevOps and Platform Engineers in Telecoms

• NFV is the bridge, not the destination. Operators who invested in NFVi are better positioned for cloud-native, but the architectural assumptions are fundamentally different.
• CNF maturity was a real constraint in 2020. Platform readiness outpaced the readiness of the actual containerized network functions being deployed on it.
• Kubernetes operational skills are a critical bottleneck. The quarterly Kubernetes release cadence alone creates continuous operational pressure for teams unused to software-defined infrastructure.
• CI/CD isn’t optional for 5G core. Cloud-native 5G functions demand the same delivery automation that web-scale software companies use — applied to carrier-grade, highly available network infrastructure.
• Edge scale changes the orchestration problem entirely. Managing thousands of RAN edge sites is a qualitatively different problem from managing a handful of core data centers.

Image courtesy of VMware. Original reporting by TelecomTV.

What Is DevOps?

DevOps is a set of practices and cultural principles that brings together software development (Dev) and IT operations (Ops) teams with the goal of shortening the software delivery lifecycle while maintaining high quality. At its core, DevOps emphasizes:

• Automation of build, test, and deployment pipelines
• Continuous integration and continuous delivery (CI/CD) to reduce batch sizes and release frequently
• Cross-functional collaboration between developers, testers, and operations engineers
• Monitoring and observability so teams can detect and resolve issues quickly
• Feedback loops that allow rapid iteration based on real production signals

The practical result is that teams aligned around DevOps practices tend to deploy more frequently, recover from failures faster, and maintain greater visibility into the state of their systems.

What Is DataOps?

DataOps applies the same lean, agile, and automation-first thinking that underpins DevOps to the world of data: its ingestion, transformation, storage, quality assurance, and delivery to consumers such as analysts, data scientists, and business applications.

Where DevOps coordinates developers and operations engineers around a software product, DataOps coordinates data engineers, data scientists, analysts, and data governance professionals around a data pipeline or analytics product. Key DataOps principles include:

• Incremental, iterative development of data pipelines rather than large monolithic batch jobs
• Automated testing of data quality at each stage of the pipeline
• Version control for data pipeline code and configuration
• Collaboration and shared ownership across data engineering, analytics, and business stakeholders
• Monitoring of data freshness, completeness, and accuracy in production

In short, DataOps is not a single tool or platform — it is a methodology that treats data pipelines with the same engineering discipline applied to application code in DevOps.

Key Benefits of DevOps

Transparency Across Teams

Regular communication between development, QA, and operations teams means everyone has visibility into project status, pending changes, and live system health. Shared dashboards, runbooks, and on-call rotations reduce information silos.

Faster, Higher-Quality Deployment Cycles

CI/CD pipelines allow teams to release smaller changes more frequently. Smaller releases are easier to test, easier to roll back, and carry lower blast radius when something goes wrong.

Faster Bug Detection and Resolution

Automated testing at every stage of the pipeline surfaces defects early, when they are cheapest to fix. Continuous monitoring in production means regressions are caught quickly rather than discovered by customers.

Flexibility to Handle Change

Agile-aligned DevOps teams are structured to absorb unplanned work and shifting priorities. Because delivery is incremental, teams can reprioritize without discarding large amounts of in-progress work.

Key Benefits of DataOps

Faster Data Processing and Delivery

Processing data in smaller, well-defined batches rather than in a single large job reduces latency and makes it easier to detect where in a pipeline a problem originates. Teams can deliver fresher data to consumers more frequently.

Quicker Problem Diagnosis

Because DataOps pipelines are modular and instrumented, teams can isolate a failing stage quickly rather than debugging an opaque end-to-end batch process. Automated data quality checks flag anomalies before downstream consumers are affected.

Improved Data Security

Closer collaboration between data security professionals, data engineers, and analysts means that security controls — access policies, encryption, masking of sensitive fields — are considered at every stage of the pipeline rather than bolted on at the end.

Better Resource Utilisation

Transparent, well-documented pipelines reduce duplicated effort. Teams spend less time debugging undocumented data transformations and more time building new value-adding capabilities.

Where DevOps and DataOps Intersect

The two disciplines share a common foundation. Both reject the idea that large, infrequent releases or deliveries are safer than small, frequent ones. Both rely on automation, monitoring, and tight feedback loops. And both require breaking down organisational silos so that the people who build a system are connected to the people who operate it and consume its outputs.

In practice, the boundary between the two frequently dissolves. A team shipping a machine learning feature must version its training data pipeline alongside its application code, run data quality tests in its CI pipeline, and monitor data drift in production alongside application error rates. These are not separate DevOps and DataOps concerns — they are unified engineering concerns that require both disciplines working together.

Concretely, combining the two practices can look like:

• Storing pipeline definitions (ETL jobs, dbt models, Spark jobs) in the same version control system as application code, with the same review and CI processes
• Provisioning isolated, virtualised copies of production databases for each feature branch, so developers and QA work with realistic data without risking production
• Running data contract tests and schema compatibility checks as part of the deployment pipeline before new application versions are promoted
• Using the same observability stack to monitor data latency and completeness as is used to monitor application latency and error rates
• Applying the same on-call and incident response processes to data pipeline failures as to application outages

A Real-World Example: Database Provisioning as a DevOps and DataOps Problem

One of the most common friction points where DevOps and DataOps collide is database provisioning for non-production environments. Development and QA teams need realistic, up-to-date copies of production databases to build and test against. In traditional environments, provisioning such a copy is a time-consuming, manual process involving DBAs, storage administrators, and network engineers — often taking days and resulting in stale data by the time the environment is ready.

Automated, self-service database provisioning tools address this by using storage virtualisation and compression to create lightweight, point-in-time copies of databases on demand. This approach can deliver several meaningful improvements:

• Environment refresh time drops from days to under an hour
• Development and QA teams can spin up, refresh, or roll back environments without involving DBAs, reducing bottlenecks
• Storage costs fall substantially because virtualised copies share underlying blocks with the source database rather than duplicating them
• QA teams work with accurate, current data rather than stale snapshots, reducing the chance that data-related defects escape to production
• Development freezes caused by database refresh cycles are eliminated, allowing teams to maintain continuous delivery cadences

This is precisely the kind of outcome that emerges when DataOps thinking — treating data environments as code, automating data lifecycle tasks, enabling self-service for data consumers — is embedded into a DevOps delivery workflow.

Getting Started: Practical Steps for Teams

Teams looking to align their DevOps and DataOps practices can start with a few concrete actions:

1. Audit your data dependencies in the delivery pipeline. Identify every place where your CI/CD pipeline touches a database, data warehouse, or external data feed. These are the points where DataOps discipline can most immediately reduce friction.
2. Version-control your pipeline code. ETL scripts, transformation logic, and schema migrations should live in source control with the same branching strategy and review process as application code.
3. Automate environment provisioning. Explore database virtualisation tools or snapshot-based provisioning to give each team self-service access to realistic test data environments.
4. Add data quality gates to your CI pipeline. Schema tests, referential integrity checks, and statistical distribution checks on sample data can catch data regressions before they reach production.
5. Extend your observability to data pipelines. Track pipeline run time, row counts, null rates, and freshness alongside application metrics. Alert on anomalies with the same urgency as application errors.
6. Align on-call responsibilities. Data pipeline failures that affect customers should be treated with the same incident response rigour as application outages.

Conclusion

DevOps and DataOps are not competing frameworks — they are complementary disciplines that address different layers of the same delivery problem. DevOps ensures that application code moves from development to production reliably and quickly. DataOps ensures that the data underpinning those applications is accurate, fresh, and trustworthy. As the complexity of data-intensive systems grows, engineering teams that treat both as first-class engineering concerns — with shared tooling, shared culture, and shared accountability — will be better positioned to deliver quality software at pace.

This article draws on concepts originally discussed at devops.com.

What Is DevSecOps?

Traditional software delivery models treated security as a final gate before release. DevSecOps shifts that model by embedding security practices — static analysis, dependency scanning, secrets detection, compliance checks, and runtime protection — at every stage of the CI/CD pipeline. The goal is to surface and remediate vulnerabilities when they are cheapest to fix: during development, not after deployment.

Adoption is driven by several converging pressures:

• Regulatory compliance — frameworks such as SOC 2, PCI-DSS, HIPAA, and GDPR require demonstrable controls over how software is built and deployed.
• Supply chain risk — high-profile incidents involving compromised build pipelines have raised boardroom awareness of software supply chain security.
• Cloud-native complexity — containerized, microservices-based architectures introduce new attack surfaces that traditional perimeter security cannot address.
• Developer velocity — organizations need security tools that integrate into existing workflows (Git, CI/CD, container registries) without blocking releases.

Major Vendors in the DevSecOps Ecosystem

The DevSecOps vendor landscape spans large platform providers, pure-play security companies, and open-source projects. Analysts commonly cite the following established players:

• IBM Corporation — offers integrated security capabilities across its cloud and hybrid-cloud portfolio, including application security testing through its acquisition of HCL AppScan and broader security orchestration tooling.
• Microsoft Corporation — GitHub Advanced Security (secret scanning, code scanning via CodeQL, dependency review) and Azure Defender for DevOps bring native security gates into developer workflows.
• Google LLC — Binary Authorization, Artifact Registry vulnerability scanning, and the SLSA (Supply-chain Levels for Software Artifacts) framework position Google Cloud as an active contributor to supply chain security standards.
• Synopsys — a long-standing provider of SAST (Coverity), SCA (Black Duck), and DAST tooling widely used in enterprise application security programs.
• Palo Alto Networks — its Prisma Cloud platform covers cloud workload protection, container security, IaC scanning, and CI/CD pipeline security under a unified console.
• Qualys — cloud-based vulnerability management, container security, and policy compliance scanning integrated into pipelines.
• Broadcom (formerly CA Technologies and Micro Focus) — CA Technologies was acquired by Broadcom; Micro Focus (now part of OpenText) contributes Fortify for application security testing.
• Chef Software (Progress) — InSpec provides compliance-as-code, enabling policy enforcement to be version-controlled and tested alongside application code.
• Dome9 (Check Point CloudGuard) — acquired by Check Point, now marketed as CloudGuard Posture Management for cloud security and compliance automation.

Beyond these established names, a large ecosystem of specialist tools has emerged — including Snyk (developer-first SCA and SAST), Aqua Security (container and cloud-native security), Checkmarx (application security testing), and HashiCorp Vault (secrets management) — reflecting how fragmented and fast-moving this market remains.

How the DevSecOps Market Is Segmented

Market research firms typically break down the DevSecOps market along three dimensions:

By Component

• Software/Platforms — integrated DevSecOps platforms, SAST, DAST, SCA, IAST, and container security tools.
• Services — consulting, implementation, training, and managed security services layered on top of tooling.

By Deployment Model

• Cloud-based / SaaS — increasingly the dominant delivery model, enabling rapid onboarding and centralized policy management across distributed teams.
• On-premises — required in air-gapped or highly regulated environments (defense, financial services, healthcare).

By Organization Size and Vertical

• Enterprise — typically drives the largest deal sizes, with complex compliance requirements and existing security toolchains to integrate.
• SMB — growing adoption as cloud-native SaaS tools lower the entry barrier.
• Verticals — financial services, healthcare, government, and technology/software sectors tend to be early and heavy adopters due to regulatory pressure and breach exposure.

Key Market Drivers and Challenges

Drivers

• Increasing frequency and sophistication of software supply chain attacks.
• Executive and board-level prioritization of cybersecurity investment.
• Growing adoption of cloud-native architectures (Kubernetes, serverless) that require new security tooling paradigms.
• “Shift-left” mandates from CISOs pushing security earlier into the SDLC.
• Expansion of open-source tooling (Trivy, Grype, Semgrep, OPA/Gatekeeper) that lowers adoption barriers and accelerates market education.

Challenges

• Alert fatigue — poorly tuned tools generate high false-positive rates, eroding developer trust and leading to alert suppression.
• Skill gaps — bridging security and engineering disciplines requires training, cultural change, and hiring that many organizations struggle with.
• Toolchain fragmentation — organizations often manage a patchwork of overlapping point solutions, creating integration overhead and coverage gaps.
• Pipeline performance — heavyweight security scans can slow CI pipelines if not carefully optimized with incremental or parallel scanning strategies.

Competitive Dynamics

The DevSecOps vendor landscape is consolidating in some areas while fragmenting in others. Large platform vendors (Microsoft, Google, GitLab, and JFrog) are embedding security capabilities natively into their developer platforms, raising the question of whether standalone security tools can maintain differentiation. At the same time, specialist vendors compete on depth — more accurate SAST engines, broader language coverage, or richer runtime telemetry — targeting enterprises that need best-of-breed capabilities beyond what platform-native tools provide.

Acquisition activity has been significant: Snyk has absorbed several smaller players, Palo Alto Networks built Prisma Cloud through a series of acquisitions (Twistlock, PureSec, Aporeto), and Check Point absorbed Dome9. This consolidation is expected to continue as buyers seek fewer, deeper integrations rather than managing many independent tools.

Regional Considerations

North America leads DevSecOps adoption by revenue, driven by a mature enterprise software market, strong regulatory enforcement, and a large base of technology companies. Europe follows, with GDPR compliance requirements and growing national cybersecurity mandates (such as the EU Cyber Resilience Act) accelerating investment. Asia-Pacific is the fastest-growing region by adoption rate, with financial services and government sectors in Singapore, Australia, Japan, and India driving demand.

Practical Takeaways for Engineering and Security Teams

Market reports are useful for budget justification and competitive benchmarking, but the more actionable questions for engineering teams evaluating DevSecOps tooling are:

• Where are our riskiest gaps? — Start with a threat model before evaluating tools. Identify whether the highest priority is dependency vulnerabilities, secrets exposure, container image hygiene, IaC misconfigurations, or runtime threats.
• What integrates with our existing stack? — A tool that fits natively into your existing CI/CD platform (GitHub Actions, GitLab CI, Jenkins, Azure Pipelines) will see far higher adoption than one requiring a separate workflow.
• How do we measure false-positive rates? — Request benchmark data from vendors using codebases similar to yours, or run a proof-of-concept with real code before committing.
• What is the developer experience? — Security tools that surface actionable, contextualized findings in the IDE or pull request review get fixed; findings buried in a separate security portal often do not.
• Can we start with open-source? — Tools like Semgrep, Trivy, Grype, detect-secrets, and Checkov provide a strong baseline with no licensing cost, allowing teams to build maturity before evaluating commercial alternatives.

The DevSecOps market will continue to evolve rapidly. The vendors that succeed long-term will be those that reduce friction for developers while providing the depth and auditability that security and compliance teams require — a balance that remains genuinely difficult to strike.

One of the strengths of Kubernetes as a container orchestrator lies in its ability to manage and respond to dynamic environments. One example is Kubernetes’ native capability to perform effective autoscaling of resources. However, Kubernetes does not support just a single autoscaler or autoscaling approach. In this post, we discuss the three forms of Kubernetes capacity autoscaling.

1. Pod Replica Count

For many applications with usage that varies over time, you may want to add or remove pod replicas in response to changes in demand for those applications. The Horizontal Pod Autoscaler (HPA) can manage scaling these workloads for you automatically.

Use Cases
The HPA is ideal for scaling stateless applications, although it can also support scaling stateful sets. Using HPA in combination with cluster autoscaling (see below) can help you achieve cost savings for workloads that see regular changes in demand by reducing the number of active nodes as the number of pods decreases.

How It Works

For workloads with HPA configured, the HPA controller monitors the workload’s pods to determine if it needs to change the number of pod replicas. In most cases, where the controller takes the mean of a per-pod metric value, it calculates whether adding or removing replicas would move the current value closer to the target value. For example, a deployment might have a target CPU utilization of 50%. If five pods are currently running and the mean CPU utilization is 75%, the controller will add 3 replicas to move the pod average closer to 50%.

HPA scaling calculations can also use custom or external metrics. Custom metrics target a marker of pod usage other than CPU usage, such as network traffic, memory, or a value relating to the pod’s application. External metrics measure values that do not correlate to a pod. For example, an external metric could track the number of pending tasks in a queue.

How to Use It

To configure the HPA controller to manage a workload, create a HorizontalPodAutoscaler object. HPA can also be configured with the kubectl autoscale subcommand.

apiVersion: autoscaling/v1kind: HorizontalPodAutoscalermetadata: name: hello-world namespace: defaultspec: maxReplicas: 10 minReplicas: 1 scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: hello-world targetCPUUtilizationPercentage: 50
This manifest would configure the HPA controller to monitor the CPU utilization of pods in the hello-world deployment. The controller could add or remove pods, keeping a minimum of one and a maximum of ten, to target a mean CPU utilization of 50%.

Requirements

The HPA controller runs, by default, as part of the standard kube-controller-manager daemon. It can manage only those pods created by a replication controller, such as deployments, replica sets, or stateful sets.

The controller requires a metrics source. For scaling based on CPU usage, it depends on the metrics-server. Scaling based on custom or external metrics requires deploying a service that implements the custom.metrics.k8s.io or external.metrics.k8s.io API to provide an interface with the monitoring service or alternate metrics source.

For workloads using the standard CPU metric, containers must have CPU resource limits configured in the pod spec.

Kubernetes-native security: what is it and why it matters
Download this ebook to learn why a Kubernetes-native approach to protecting your containerized applications provides the most comprehensive security in Kubernetes environments

Download Today

2. Cluster Autoscaler

While HPA scales the number of running pods in a cluster, the cluster autoscaler can change the number of nodes in a cluster.

Use Cases
Dynamically scaling the number of nodes to match current cluster utilization can help manage the costs of running Kubernetes clusters on a cloud provider platform, especially with workloads that are designed to scale to meet current demand.

How It Works

The cluster autoscaler loops through two main tasks: watching for unschedulable pods and computing if it could consolidate all currently deployed pods on a smaller number of nodes.

The autoscaler checks the cluster for pods that cannot be scheduled on any existing nodes because of inadequate CPU or memory resources or because the pod’s node affinity rules or taint tolerations do not match an existing node. If the cluster has unschedulable pods, the autoscaler will check its managed node pools to decide if adding a node would unblock the pod. If so, it will add a node if the node pool can be increased in size.

The autoscaler also scans the nodes in the node pools that it manages. If a node has pods that could be rescheduled on other available nodes in the cluster, the autoscaler will evict them and then remove the node. When deciding if a pod can be moved, the autoscaler takes into account pod priority and PodDisruptionBudgets.

How to Use It
The cluster autoscaler supports only a limited number of platforms. If you use a managed Kubernetes service, check if it provides the cluster autoscaler as an option. Otherwise, you will need to install and configure the autoscaler yourself.

Exact configuration steps vary by cloud provider, but generally, the cluster autoscaler must have the permissions and credentials to create and terminate virtual machines. Infrastructure tags or labels mark which node pools the autoscaler should manage.

Requirements
The cluster autoscaler can manage nodes only on supported platforms, all of which are cloud providers, with the exception of OpenStack. Different platforms may have their own specific requirements or limitations.

Because the autoscaler controller requires permissions to add and delete infrastructure, the necessary credentials need to be managed securely, following the principle of least privilege. This requirement poses less of a risk in managed Kubernetes platforms which run the controller on a secure control plane.

3. Vertical Pod Autoscaling

The default Kubernetes scheduler overcommits CPU and memory reservations on a node, with the philosophy that most containers will stick closer to their initial requests than to their requested upper limit. The Vertical Pod Autoscaler (VPA) can increase and decrease the CPU and memory resource requests of pod containers to better match the allocated cluster resource allotment to actual usage.

Use Cases

The VPA service can set container resource limits based on live data, rather than human guesswork or benchmarks that are only occasionally run.

Alternatively, some workloads may be prone to occasional periods of very high utilization, but permanently increasing their request limits would waste mostly unused CPU or memory resources and limit the nodes that can run them. While Horizontal Pod Autoscaling can help in many of those cases, sometimes the workload cannot easily be spread across multiple instances of an application.

How It Works

A VPA deployment has three components: Recommender, which monitors resource utilization and computes target values; Updater, which evicts pods that need to be updated with new resource limits, and the Admission Controller, which uses a mutating admission webhook to overwrite the resource requests of pods at creation time.

Because Kubernetes does not support dynamically changing the resource limits of a running pod, the VPA cannot update existing pods with new limits. It terminates pods that are using outdated limits, and when the pod’s controller requests the replacement from the Kubernetes API service, the VPA admission controller injects the updated resource request and limit values into the new pod’s specification.

VPA can also be run in recommendation mode only. In this mode, the VPA Recommender will update the status field of the workload’s VerticalPodAutoscaler resource with its suggested values but will not terminate pods or alter pod API requests.

How To Use It
If your Kubernetes provider does not support VPA as an add-on, you can install it in your cluster directly.

VPA uses the custom resource VerticalPodAutoscaler to configure the scaling for a deployment or replica set. If I wanted VPA to manage resource requests for my hello-world deployment, I might apply this manifest:

apiVersion: “autoscaling.k8s.io/v1beta2″kind: VerticalPodAutoscalermetadata: name: hello-worldspec: targetRef: apiVersion: “apps/v1” kind: Deployment name: hello-world resourcePolicy: containerPolicies: – containerName: ‘*’ controlledResources: [“cpu”, “memory”] minAllowed: cpu: 200m memory: 50Mi maxAllowed: cpu: 500m memory: 500Mi updatePolicy: updateMode: “Auto”
Now VPA will watch the pods in my deployment and try to set the appropriate resource value, between 200 and 500 milliCPUss with between 50 and 500 mebibytes of memory. If VPA computes new resource values for the deployment’s pods, it will evict existing pods sequentially and update the replacements with the new values.

Requirements
VPA can replace only pods managed by a replication controller, such as deployments. It requires the Kubernetes metrics-server.

VPA and HPA should only be used simultaneously to manage a given workload if the HPA configuration does not use CPU or memory to determine scaling targets.

VPA also has some other limitations and caveats.

These autoscaling options demonstrate a small but powerful piece of the flexibility of Kubernetes. Using one or more forms of autoscaling removes a good deal of the overhead in managing dynamic production environments and improves efficiency of infrastructure utilization.

The State of DevSecOps in 2020

Integrating security into DevOps pipelines has proven considerably harder than simply automating deployment or testing. Sonatype — the company behind the Nexus application security platform — released its 2020 DevSecOps Community Survey to take stock of where the industry actually stands. The results highlight a clear divide between teams with mature DevOps practices and those still finding their footing, across tooling adoption, deployment frequency, and even developer satisfaction.

Who Responded: Survey Methodology and Representativeness

The survey drew more than 5,000 respondents from a Sonatype-maintained email list of approximately 160,000 software professionals. Sixty-five percent identified as individual contributors rather than executives, which lends more weight to the ground-level accuracy of responses — answers are less likely to reflect the polished view a CTO would project on behalf of their best-performing division.

The survey questions were developed with input from a range of industry advisors, including the DevOps Institute, Verica, the Software Engineering Institute’s DevOps division at Carnegie Mellon, Cloudbees, and DevOps.com. This consensus-driven approach shaped the ten security tool categories examined in the survey.

In terms of project type, 86% of respondents worked on web applications and 64% on web services, while mobile (29%) and desktop (37%) were less represented. Most respondents came from larger organisations: 68% had more than 25 developers.

Sonatype also validated self-reported maturity levels. If a respondent claimed high DevOps maturity but described a waterfall release process with quarterly web deployments, the team would downgrade that classification. This cross-checking adds a degree of rigour to the maturity segmentation.

Deployment Frequency: A Key — but Nuanced — Metric

Deployment frequency is a widely-cited proxy for DevOps maturity, but it can be misleading at the organisational level. A company with twelve teams might report deploying “twice a day” when each individual team ships roughly once a week. With that context in mind, the survey found that 55% of respondents deployed at least once a week — most likely measured at the team level.

The Ten DevSecOps Tool Categories — and Their Adoption Rates

The survey assessed adoption across ten distinct security tool categories. Listed roughly from highest to lowest adoption:

• Web Application Firewall (WAF) — the most widely adopted; 51% of even less-mature teams reported using one.
• Open Source Governance — tracking and managing open source dependencies and their licences.
• Intrusion Detection System (IDS)
• Static Analysis Security Testing (SAST) — often referred to as “code scanning.”
• Data Loss Prevention (DLP)
• Container Security
• Dynamic Analysis Security Testing (DAST) — commonly associated with penetration testing.
• Software Composition Analysis (SCA) — identifying known vulnerabilities in third-party libraries.
• Interactive Application Security Testing (IAST) — sometimes called “human pen testing” in the survey’s framing.
• Runtime Application Self-Protection (RASP) — the least adopted; only 20% of even the more mature respondents were running RASP.

The gap between WAF adoption (51% even among less-mature teams) and RASP adoption (only 20% among more-mature teams) underscores how early-stage most organisations’ runtime security postures remain. Mature teams are more likely to adopt tooling across all ten categories, but no category has reached universal adoption.

Developer Satisfaction and Security: Happy vs. Grumpy Engineers

One of the more striking findings involves developer satisfaction. Sonatype segmented respondents into “happy” and “grumpy” buckets based on questions about job satisfaction and whether they would recommend their employer to a friend. It then cross-referenced satisfaction with security tooling adoption.

Key findings from this cross-cut:

• Happy developers were nearly twice as likely to use security analysis tools: 65% of happy developers ran security analysis versus 34% of grumpy developers.
• Among those without security analysis tools, the numbers inverted: 66% of grumpy developers lacked these tools compared to 34% of happy developers.
• Mature DevOps environments correlated strongly with satisfaction: 92% of high-maturity respondents reported job satisfaction versus 61% of lower-maturity respondents.
• Grumpy developers also reported lower awareness of most security tool categories — with the notable exceptions of “Security Management” (20% happy vs. 22% grumpy) and informal awareness via rumour (19% of grumpy developers versus 5% of happy developers).

The interpretation here isn’t straightforward. It’s plausible that mature DevOps environments produce both better tooling adoption and more satisfied engineers, rather than satisfaction being a direct cause of security adoption. It’s equally possible, as the original report wryly notes, that happy developers are “too busy actually getting things done” to worry about security gaps — though the data suggests the opposite.

Real-World Consequences: The SaltStack Case

Derek Weeks, a vice president at Sonatype, highlighted the SaltStack security incident as a concrete example of what inadequate open source governance can cost an organisation. SaltStack’s maintainers released a patch before publicly disclosing the underlying vulnerability — a responsible disclosure approach. However, teams that lacked an open source governance or Software Composition Analysis system had no way of knowing they were running a vulnerable version of SaltStack, let alone that a patch was available. The result: multiple security breaches occurred the day after the public announcement.

The survey found that 21% of respondents had experienced an open source security breach in the past year. Weeks suggested even this figure is likely understated, given that many breaches go undetected without the right monitoring tools in place.

Key Takeaways for DevOps Teams

• Tooling adoption correlates with maturity. If your organisation lacks Software Composition Analysis or Static Analysis Security Testing, closing those gaps is a concrete step toward higher DevSecOps maturity.
• Runtime security remains an industry-wide gap. RASP adoption is low even among mature teams, representing an area where most organisations have room to improve.
• Open source governance is not optional. The SaltStack incident demonstrates that knowing what you’re running — and being alerted when patches drop — is as operationally critical as any deployment pipeline capability.
• Developer experience matters. The correlation between mature DevOps practices and developer satisfaction suggests that investing in tooling and process improvement may pay dividends in retention and morale, not just security posture.
• Self-assessed maturity should be verified. Sonatype’s approach of cross-checking self-reported maturity against actual practices is worth adopting internally when evaluating your own DevSecOps programme.

About the Survey

The 2020 DevSecOps Community Survey was conducted by Sonatype, providers of the Nexus application security platform. More than 5,000 software professionals participated. The survey questions were developed in collaboration with the DevOps Institute, Verica, Carnegie Mellon’s Software Engineering Institute DevOps division, Cloudbees, and DevOps.com. Original coverage appeared on TechRepublic.

Overview: Three Threat Categories in Kubernetes Environments

Trend Micro has published a guide to Kubernetes security threats that organizes risks into three broad categories: external attacks, misconfiguration issues, and vulnerable containerized applications. The guide is aimed at security and DevOps teams navigating an increasingly complex platform that many organizations are still learning to operate safely at scale.

Mark Nunnikhoven, vice president of cloud research at Trend Micro at the time of publication, noted that rapid Kubernetes adoption is compounding an already serious shortage of cybersecurity expertise. The platform’s power and flexibility also introduce substantial surface area for configuration mistakes and architectural missteps.

1. External Attacks: Protecting the Kubernetes API Server

The most common external attack vector against Kubernetes clusters targets the kube-apiserver — the control plane component that exposes the API through which all Kubernetes management operations are defined and executed. An attacker who gains unauthorized access to this API can potentially:

• Deploy malicious containers to exfiltrate data from databases
• Consume cluster resources to run cryptocurrency mining workloads
• Pivot into other parts of the cluster or connected infrastructure

API Server Ports to Secure

The Kubernetes API server is accessible through two ports:

• Port 8080 — localhost only, used for insecure (plain-text) access; should never be exposed externally
• Port 6443 — the default HTTPS port for authenticated API access

Trend Micro’s guide outlines three practical controls for locking down API server access:

1. Firewall rules — restrict API access to only the machines and IP ranges that legitimately require it
2. Avoid --insecure-bind-address — do not configure the API server to open the plain-text port on any non-localhost interface
3. Intrusion Prevention System (IPS) with SSL decryption — deploy an IPS capable of inspecting encrypted traffic to detect and block malicious API calls in transit

2. Misconfigurations: The Most Common Kubernetes Security Failure

According to Nunnikhoven, misconfigurations are the most frequent source of Kubernetes security incidents in production environments. A significant part of the problem stems from Kubernetes’ permissive defaults.

By default, Kubernetes allows all traffic between all pods within the same namespace. Every pod can communicate freely with every other pod. If an attacker compromises a public-facing pod, they can use it as a foothold to reach internal services — dramatically simplifying lateral movement across the cluster.

Recommended Network Policy Approach

The best practice, as outlined in the guide, is a deny-by-default network policy model:

• Deny all ingress and egress traffic by default using Kubernetes NetworkPolicy resources
• Explicitly allow only the traffic paths that are required for each workload
• At minimum, apply a default-deny policy for ingress traffic to all namespaces

This approach limits blast radius significantly if a pod is ever compromised, preventing an attacker from freely traversing the cluster.

# Example: Default-deny ingress NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

3. Vulnerable Applications: Keeping Container Images Patched

Containerized applications introduce a unique patching challenge. Unlike traditional deployments where a library is installed once on a host, every container image carries its own copy of every library it depends on. The same library may appear in dozens of images derived from different base images — and each one must be updated independently when a vulnerability is discovered.

The Trend Micro report highlights two core practices for managing this challenge:

• Keep base images and application images current — rebuild and redeploy images promptly when upstream patches are available, rather than relying on host-level patching
• Regularly scan all container images — integrate image scanning into CI/CD pipelines and continue scanning images already running in production, since new CVEs are discovered continuously after an image is built

The Broader DevSecOps Imperative

Nunnikhoven’s broader conclusion is that Kubernetes adoption inevitably pushes organizations toward maturing their DevSecOps practices. The complexity of Kubernetes means security cannot be bolted on after deployment — it must be embedded in the development and operations workflows from the start.

The practical challenge is cultural as much as technical: bridging the historical divide between development teams and security professionals to establish shared workflows, shared responsibility, and shared tooling. Done well, this reduces the overall security burden on both sides rather than concentrating it on either.

Key Takeaways

• The kube-apiserver is the highest-value external attack target; restrict access with firewall rules, avoid insecure bind addresses, and use IPS with SSL inspection
• Misconfigurations are the most common Kubernetes security failure; adopt a deny-by-default network policy posture
• Vulnerable images require proactive scanning and rapid rebuilds — host-level patching is insufficient in containerized environments
• Long-term Kubernetes security depends on embedding security into DevOps workflows rather than treating it as a separate discipline

Digital Channels Have Become the Storefront

When physical locations become inaccessible—whether due to public health restrictions, natural disasters, or shifting consumer habits—a company’s website or mobile application instantly becomes its primary customer-facing interface. Organizations that had not yet invested seriously in digital transformation find themselves accelerating years of planned work into weeks. IT teams are no longer supporting the business; in many cases, they are the business.

Luke Rogers, General Manager for Canada at AppDynamics (a Cisco company), described the situation clearly: organizations that previously treated IT as a back-office function are arriving at APM vendors saying, “Our IT has become our business, and our applications have become the storefront, and our ability to deliver a digital experience is everything.”

The Real Cost of Poor Application Performance

Application performance directly affects revenue, customer retention, and brand trust. The relationship between page load time and user abandonment is well established in web performance research. As a reference point cited in the original reporting: when mobile page load time increases from one second to ten seconds, the probability of a visitor leaving the page before it loads increases by approximately 123 per cent.

This figure underlines a critical question every engineering team should be asking: Does your infrastructure scale to handle demand spikes without degrading the user experience? A site that performs well under normal load may buckle when traffic doubles or triples, precisely when uptime matters most.

What Application Performance Monitoring (APM) Actually Does

APM tools give engineering and operations teams a comprehensive, real-time view of how their applications behave in production. Rather than waiting for a customer complaint or an on-call alert, APM surfaces problems—slow database queries, memory leaks, failing third-party API calls, saturated connection pools—before they cascade into outages.

Key capabilities that mature APM platforms provide include:

• Full-stack visibility: Traces a single user transaction from the browser or mobile client through load balancers, application servers, microservices, databases, and external APIs.
• Baseline and anomaly detection: Establishes normal performance thresholds and alerts when metrics deviate, reducing alert fatigue compared to static threshold monitoring.
• Distributed tracing: Correlates spans across service boundaries, which is essential in microservice and Kubernetes-based architectures.
• Infrastructure correlation: Links application-layer symptoms (slow response times) to infrastructure-layer causes (CPU contention, disk I/O, network latency).
• Business transaction monitoring: Tags traces by business context—checkout flow, login, search—so engineers can prioritise fixes by revenue impact rather than raw error count.

Full-Stack Visibility: Why Partial Visibility Is Dangerous

A common failure mode is monitoring only one layer of the stack. Teams may have excellent application-level metrics but no visibility into the underlying compute and storage, or they may monitor infrastructure health without correlating it to user-facing latency. When an incident occurs, engineers spend the majority of their time on root-cause analysis rather than remediation because they lack a unified picture.

Rogers summarised the requirement well: “You need something that provides that full-stack visibility of everything—from the compute storage system layer all the way up to the application layer. There’s real value in that.”

In practice, full-stack observability typically means integrating three signal types:

1. Metrics — time-series data on CPU, memory, request rates, error rates, and latency percentiles.
2. Logs — structured or semi-structured event records from applications and infrastructure components.
3. Traces — end-to-end records of individual requests flowing through distributed systems.

Questions Engineering Teams Should Answer Before a Traffic Spike

Rather than discovering scaling limits under fire, DevOps and SRE teams can conduct structured readiness reviews. The following questions provide a practical starting framework:

• What is the current baseline throughput (requests per second) for each critical user journey?
• At what point does response time exceed your SLO threshold—and have you load-tested to that ceiling?
• Are auto-scaling policies configured and validated for your application tier, database tier, and CDN?
• Do you have circuit breakers and graceful degradation in place for third-party dependencies?
• Is your on-call runbook up to date, and do engineers have the access they need to act quickly during an incident?
• Are data residency and compliance requirements (data sovereignty) documented for all services that process customer data?

The APM Market and Vendor Landscape

Application performance management has grown into a substantial and competitive market. According to IDC figures cited in the original reporting, the APM market grew from approximately $4.3 billion in 2018 to $5.8 billion in 2019, with continued growth expected. Several enterprise and open-source options exist, including AppDynamics (Cisco), Dynatrace, New Relic, Datadog, Elastic Observability, and open-source stacks built around Prometheus, Grafana, Jaeger, and OpenTelemetry.

When evaluating APM tooling, consider the following criteria:

• Language and framework support: Does the agent or SDK support your primary tech stack without requiring significant instrumentation effort?
• Cloud and container native support: Does the platform have first-class support for Kubernetes, serverless functions, and managed cloud services?
• Data retention and pricing model: Ingestion-based pricing can become expensive at scale; understand the cost model before committing.
• Data residency options: For regulated industries or specific jurisdictions, confirm where telemetry data is stored and processed.
• Integration breadth: Alerting, incident management (PagerDuty, Opsgenie), CI/CD pipelines, and ITSM platforms should integrate without heavy custom work.

Key Takeaways for DevOps and SRE Teams

Application health is no longer solely an engineering concern—it has direct and measurable business impact. Engineering leaders who can present performance data in business terms (conversion rate, revenue per transaction, customer churn risk) are far more likely to secure the investment needed to address underlying infrastructure and observability gaps.

• Establish SLOs for every customer-facing service and measure them continuously, not just during incidents.
• Invest in full-stack observability before a demand spike, not after one exposes your blind spots.
• Treat load testing as a regular engineering practice, not a one-time pre-launch activity.
• Document data sovereignty requirements early, especially if operating across multiple jurisdictions or in regulated sectors.
• Use observability data to build the business case for infrastructure investment with leadership.

The organisations that weather unexpected demand surges best are those that have invested in visibility, automation, and resilience engineering before the surge arrives.

Containers and Cloud: A Natural Partnership

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

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

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

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

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

Common CaaS offerings from major cloud providers include:

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

CaaS Adoption Is Rising Fast

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

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

Adoption of specific CaaS products reflects this trend:

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

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

Why CaaS Matters: Balancing Speed and Control

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

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

Eric Olsson, Scalyr

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

Key Challenges Slowing Container Adoption

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

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

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

Docker and Kubernetes Remain the Foundation

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

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

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

Is CaaS the Right Choice for Your Organization?

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

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

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

Conclusion

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

Background: Pandemic Demand Reshapes Video Conferencing

The COVID-19 pandemic triggered a rapid, global shift to remote work in early 2020. Demand for video conferencing tools surged almost overnight, and Zoom Video Communications (NASDAQ: ZM) was one of the biggest beneficiaries. The company’s platform went from a niche enterprise tool to a household name within weeks, and its stock price reflected the momentum — roughly doubling year-to-date by late April 2020.

That explosive growth also attracted serious competitive attention, most notably from Google.

Google Fires the First Shot: Google Meet Goes Free

Recognising the market opportunity, Google moved aggressively to compete with Zoom by opening its Google Meet video conferencing tool to all users at no cost — a tier previously restricted to paying Google Workspace (then G Suite) subscribers. The move was a direct competitive challenge, lowering the barrier for individuals and organisations to adopt a Zoom alternative.

Making Meet freely available was a calculated bid to gain market share quickly, leveraging Google’s existing user base across Gmail and other services. The rivalry between Zoom and Google Meet became one of the defining competitive storylines of the 2020 remote-work boom.

Zoom’s Response: Choosing Oracle Over Google Cloud

Zoom’s competitive response came not just in the product arena, but in its infrastructure decisions. Rather than expanding its cloud footprint with Google Cloud Platform — the natural next step for a company already using both Amazon Web Services (AWS) and Microsoft Azure — Zoom signed Oracle Cloud Infrastructure (OCI) as a new cloud computing provider.

The decision to choose Oracle was widely interpreted as a deliberate snub of Google. By routing traffic and workloads through Oracle rather than Google Cloud, Zoom denied a major prospective customer win to a direct product competitor. The move highlighted a dynamic that DevOps and procurement teams at large enterprises increasingly face: vendor relationships do not exist in isolation from product competition.

The Cloud Market Context: Google’s Uphill Battle

To understand why losing Zoom mattered for Google Cloud, it helps to look at the broader competitive landscape as it stood in Q1 2020:

• Amazon Web Services (AWS): approximately 32% global cloud market share (Synergy Research, Q1 2020)
• Microsoft Azure: approximately 18% global cloud market share
• Google Cloud Platform (GCP): approximately 8% global cloud market share

Google Cloud was already a distant third. The company had publicly stated an ambition to become the world’s largest cloud provider within five years — an aggressive goal that required closing a substantial gap with both AWS and Azure. To achieve that, Google needed high-profile enterprise wins, particularly from companies that were already multi-cloud customers of AWS and Azure.

Zoom was precisely that kind of customer — large, fast-growing, and already using both market leaders. Losing that deal to Oracle represented not just a missed revenue opportunity but a symbolic setback for Google’s enterprise credibility narrative.

Google Cloud’s Revenue Position at the Time

Despite the competitive loss, Google Cloud remained a significant and fast-growing business. The division reported $2.8 billion in revenue in Q1 2020, representing year-over-year growth of approximately 55.6%. That growth rate was impressive in absolute terms, but the company needed sustained large-scale enterprise adoption to begin closing the gap with AWS and Azure.

The broader market context reinforced why every significant customer win or loss mattered: according to Gartner estimates cited at the time, global cloud spending was projected to exceed $266 billion in 2020, up from $228 billion in 2019 and $197 billion in 2018. Competition for that spending was intense.

The Oracle Factor: An Unexpected Beneficiary

Oracle (NASDAQ: ORCL) was not the obvious choice. AWS, Azure, and GCP were all established, at-scale cloud providers with proven global infrastructure. Oracle Cloud Infrastructure was a newer, less dominant player still building its enterprise reputation. Zoom’s decision to select Oracle was, therefore, notable on multiple levels:

• It validated Oracle’s infrastructure capabilities for high-throughput, latency-sensitive workloads like video conferencing.
• It gave Oracle a marquee reference customer at a time when the company was actively investing in expanding OCI.
• It introduced an element of vendor diversification for Zoom beyond the two dominant hyperscalers.

It is also worth noting that Google and Oracle were engaged in a significant, long-running legal dispute over Java APIs at the time — a case that eventually reached the US Supreme Court. Whether that litigation influenced Zoom’s decision is not confirmed in the available reporting, but it formed notable background context.

Key Takeaways for DevOps and Infrastructure Teams

The Zoom-Google-Oracle episode illustrates several real-world dynamics that infrastructure and platform engineering teams should be aware of when evaluating cloud strategy:

• Product competition affects procurement decisions. When a cloud provider is also a direct competitor in your core product category, that tension can — and does — influence buying decisions. Companies need to assess whether a cloud vendor’s product portfolio conflicts with their own business.
• Multi-cloud is now the norm, not the exception. Zoom’s use of AWS, Azure, and Oracle demonstrated that large-scale platforms are increasingly built across multiple cloud providers, both for resilience and for strategic flexibility.
• Challenger clouds can win meaningful workloads. Oracle’s win showed that despite lower overall market share, challenger providers can secure high-profile infrastructure contracts — particularly when they offer competitive pricing, performance differentiation, or the absence of a competitive conflict.
• Market share is not destiny. Being third in cloud market share does not disqualify a provider, but it does mean that losing high-visibility customers carries outsized symbolic and momentum cost.

Summary

In early 2020, Zoom’s rapid growth made it both a competitive target for Google and a coveted cloud infrastructure customer. By choosing Oracle Cloud over Google Cloud, Zoom sent a clear signal: when a cloud provider is also a direct product rival, enterprise customers will actively route around them. For Google Cloud, the loss underscored the challenge of competing in a market where its own expanding product portfolio can create conflicts with potential infrastructure customers. For Oracle, it was a credibility-building win at exactly the right moment.

The broader lesson — that cloud vendor strategy and competitive product strategy are inseparable — remains relevant for any organisation architecting a multi-cloud infrastructure today.

Kasten K10 Joins the VMware Cloud Marketplace

Kasten announced that its flagship Kubernetes data management platform, Kasten K10, is now available on the VMware Cloud Marketplace. The listing makes it easier for enterprise IT and DevOps teams running VMware-based infrastructure to discover, validate, and deploy a purpose-built Kubernetes data management solution without leaving their existing cloud environment.

The K10 platform targets what Kasten calls “Day 2” operational challenges for cloud-native applications — specifically backup and restore, application mobility, and disaster recovery — for organizations running Kubernetes workloads on vSphere.

What Is the VMware Cloud Marketplace?

The VMware Cloud Marketplace is a catalog that lets customers discover and deploy validated third-party solutions across public, private, and hybrid cloud environments built on VMware technology. Once a partner solution is validated by VMware, it can be published directly to the marketplace, allowing customers to access it from within their existing VMware cloud environment. The marketplace also provides supporting features such as notifications, usage reporting, and analytics.

Key Capabilities of Kasten K10 for VMware Customers

Kasten architected K10 specifically to address data management challenges for cloud-native, containerized applications. For VMware PKS (Pivotal Container Service) customers, the platform delivers three core capabilities:

1. Zero-Touch Application Backup and Recovery

K10 uses an application-aware approach that dynamically maps data management policies to the current state of applications running on VMware PKS clusters. This means teams can implement backup and recovery without modifying developer workflows or CI/CD pipelines. The platform comes pre-integrated with both relational and NoSQL data services.

2. Seamless Operations and Application Portability

K10 supports disaster recovery workflows across VMware PKS clusters, including cross-region application migration. Managed public cloud Kubernetes clusters are also supported, with data format conversion handled automatically when moving workloads between infrastructure environments.

3. Enterprise-Grade Reliability and Ease of Use

K10 manages backups at scale through automation and a graphical interface, reducing the need for custom scripting. Role-Based Access Control (RBAC) is natively integrated into the platform, along with extensible workflow support to meet compliance requirements.

Why This Matters for DevOps and Platform Engineering Teams

The listing on the VMware Cloud Marketplace lowers the barrier for vSphere-centric organizations that are adopting Kubernetes. Rather than sourcing and validating a backup solution independently, teams can consume a pre-validated offering directly from the marketplace. This is particularly relevant given VMware’s Tanzu portfolio, which integrates Kubernetes management directly into vSphere — accelerating the pace at which production Kubernetes workloads are appearing in traditional enterprise data centers.

For platform teams managing hybrid environments, K10’s cross-region migration and cloud portability features can simplify disaster recovery planning and reduce lock-in concerns when running stateful applications on Kubernetes.

What Kasten and VMware Said

“We believe that the pace of Kubernetes applications in production will accelerate further with VMware’s recent Tanzu portfolio releases that make Kubernetes a first-class citizen in vSphere environments.”

— Gaurav Rishi, Head of Product, Kasten

“Validated technologies, such as Kasten K10, enable our customers to build, run, and manage their applications effectively and efficiently. We’re excited to work with partners such as Kasten to empower customers to derive the most value from their cloud investments.”

— Ramya Sarangarajan, Director, VMware Cloud Services

Background: Kasten and Kubernetes Data Management

Kasten was founded to address stateful application data management on Kubernetes — an area that has historically lagged behind the rapid adoption of container orchestration itself. The company was later acquired by Veeam Software in 2020, broadening its distribution into enterprise backup and recovery channels. K10 remains the product name under Veeam’s ownership.

The VMware Cloud Marketplace listing was announced in April 2020, at a time when Kubernetes adoption within traditional enterprise VMware environments was growing rapidly due to the Tanzu announcements.

ServiceNow Takes a Stand: No Layoffs, More Hiring

At a time when layoffs were sweeping across nearly every industry, ServiceNow CEO Bill McDermott made a public commitment in April 2020 to protect his company’s workforce — and go further by actively expanding it. In a press release issued in April 2020, McDermott stated that ServiceNow would not conduct any COVID-19-triggered layoffs during the year and would instead hire more than 1,000 net new employees in the United States alone, with additional hiring planned globally.

“We want our employees focused on supporting our customers, not worried about their own jobs. Keeping our company strong means we can help our customers succeed. Supporting our customers, we can help get the U.S. and global economy working again.”

— Bill McDermott, CEO, ServiceNow

McDermott described the company as “grateful to be in this position” — an acknowledgment that not every enterprise software vendor had the financial stability to make similar commitments during an unprecedented global health and economic crisis.

Context: ServiceNow’s Financial Position Heading Into 2020

Before the pandemic took hold, ServiceNow had been on a strong growth trajectory. With more than 11,000 employees worldwide, the company was widely expected to post its first-ever billion-dollar quarter in Q1 2020 and was on track to surpass $4 billion in annual revenue for the full calendar year. Those milestones had been within reach, making ServiceNow one of the cloud industry’s standout performers heading into the year.

However, like most enterprise technology vendors, ServiceNow found its near-term financial outlook complicated by the sweeping economic disruption caused by COVID-19. McDermott and the company were preparing to release Q1 2020 financials on April 29, 2020, with analysts and investors watching closely to see how the crisis was affecting demand for digital workflow solutions.

What the Hiring Commitment Signals

Committing to hire more than 1,000 new employees during a global recession is not a decision made lightly. From a strategic standpoint, this kind of forward investment typically signals several things:

• Confidence in demand: ServiceNow’s digital workflow and IT service management (ITSM) platform is designed to automate and streamline enterprise operations — capabilities that become more, not less, relevant during periods of disruption and remote work adoption.
• Customer success focus: Growing headcount in sales, support, and professional services roles helps ensure that existing customers receive the attention they need during challenging times, which in turn reduces churn.
• Talent opportunity: Economic downturns often free up high-quality talent. Companies with strong balance sheets can attract skilled engineers, consultants, and sales professionals who might otherwise be unavailable.

ServiceNow confirmed in its press release that it had “continued to hire and onboard new employees throughout the COVID-19 pandemic,” suggesting the hiring plan was already in motion rather than being a future aspiration.

ServiceNow’s Broader COVID-19 Response

The hiring commitment was part of a larger response from ServiceNow to the pandemic. Earlier in the crisis, the company released four emergency-response applications — developed in partnership with ecosystem partners — at no cost to public-sector organizations and businesses. These apps were designed to help organizations manage the surge in emergency-response and workforce safety requirements that arose rapidly in early 2020.

According to reporting from Cloud Wars, approximately 1,000 organizations had adopted these four emergency-response apps shortly after they were made available. The rapid uptake underscored the immediate operational value ServiceNow’s platform could provide during a crisis, as organizations scrambled to manage employee health tracking, remote work provisioning, and emergency communications at scale.

Why This Matters for the DevOps and Enterprise Tech Community

For DevOps engineers, platform architects, and IT leaders, ServiceNow’s response during COVID-19 illustrated a few broader points worth noting:

• Workflow automation as resilience infrastructure: Platforms that automate IT workflows, incident management, and change management proved critical as remote work created new operational stresses on IT departments. Organizations already running mature ITSM platforms were better positioned to adapt.
• Vendor stability matters: During a crisis, the financial health and stability of your SaaS vendors becomes a real concern. ServiceNow’s ability to pledge no layoffs while expanding headcount was a signal of platform longevity that enterprise customers take seriously.
• Ecosystem agility: The rapid development and deployment of free COVID-19 response apps — built with partners — demonstrated how a mature platform ecosystem can mobilize quickly to address emergent needs.

Looking Ahead

As of April 2020, ServiceNow held the number-nine position on the Cloud Wars Top 10 ranking of cloud vendors. McDermott had been laying the groundwork for an ambitious expansion of ServiceNow’s market position and product vision before the pandemic interrupted those plans. Whether the company would be able to resume that trajectory — or whether the economic headwinds of 2020 would force a more conservative posture — remained to be seen at the time of this reporting.

What was clear, however, was that ServiceNow was betting on continued demand for digital workflow automation, and it was willing to back that bet with concrete investment in people during one of the most uncertain periods in modern economic history.

Source: Cloud Wars (cloudwars.co). Original reporting by Cloud Wars staff, April 2020. This post is based on information available as of April 18, 2020 and reflects the situation as it stood at that time.

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

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

FEATURED STORIES

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

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

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

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

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

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

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

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

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

The VA’s DevOps Challenge Is Fundamentally a People Problem

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

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

Culture Change Before Tool Adoption

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

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

— Patty Craighill, Director of DevOps Implementation, VA

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

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

Breaking the Waterfall Funding Mindset

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

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

— Patty Craighill

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

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

— Patty Craighill

Mastery Teams: Training That Sticks

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

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

— Patty Craighill

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

Change Teams: Bridging Old Processes and New Practices

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

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

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

— Patty Craighill

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

Extending DevOps Beyond Central IT: Legacy and Cloud

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

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

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

— Patty Craighill

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

Key Takeaways for DevOps Leaders in Large Organizations

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

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