This article is based on an interview originally published by InformationWeek, conducted by Joao-Pierre S. Ruth at the DevOps World / Jenkins World conference in San Francisco.
Background: CloudBees and the DevOps World Conference
CloudBees, the enterprise software company built around Jenkins — the widely adopted open source automation server — hosted the DevOps World / Jenkins World conference in San Francisco. The event brought together practitioners, engineers, and executives to discuss the evolving state of continuous integration and continuous delivery (CI/CD).
During the conference, CloudBees announced a partnership with Google Cloud to develop a DevOps platform drawing on Anthos, Google’s hybrid and multi-cloud application management platform. Sacha Labourey, CEO and co-founder of CloudBees, spoke with InformationWeek about CI/CD maturity, the next generation of DevOps tooling, and what the Google partnership will mean in practice.
Why a Conference Dedicated to DevOps?
Asked why he helped create the DevOps World conference, Labourey explained that DevOps is fundamentally different from other technical disciplines:
“What is pretty unique about the DevOps space is that unlike some other technical problems, where it’s about applying a set of rules, in DevOps you have a set of things you can apply but by and large it remains a journey. It’s a venture you need to do with your colleagues, you need to change culture, and you need to change people. Obviously, you have technical matters and that’s where we can help. What happens in this conference is that a lot of people are sharing tricks, sharing pain points, and how they solve them.”
— Sacha Labourey, CEO, CloudBees
This framing — DevOps as a cultural journey rather than a checklist — is a consistent theme in how CloudBees positions both its products and community events.
The CI/CD Maturity Curve: Where Organizations Stand
Labourey used a vivid analogy to describe the wide spectrum of DevOps maturity he sees across the industry:
“DevOps is like a long train. You have companies at the front that are doing everything in beautiful ways, but you also have companies behind them that have not yet looked at DevOps and not doing any continuous integration. Nothing. You need to help those organizations go through that. It’s a maturity cycle where typically you start with continuous integration, move to continuous delivery, and grow from there. We focus on the center, the CI/CD layer, the engine based on Jenkins, and we let companies and developers make choices around what they want to use in terms of the other solutions. From that standpoint, we’re trying to be the Switzerland of DevOps.”
— Sacha Labourey
The “Switzerland of DevOps” framing signals CloudBees’ intent to remain tool-agnostic at the periphery while owning the CI/CD pipeline layer — a strategic position that allows Jenkins-based pipelines to integrate with a wide variety of third-party tools for testing, security scanning, artifact management, and deployment.
The Velocity Problem: When Fast Becomes Frightening
Labourey noted that once organizations successfully adopt CI/CD, they often face a new and unexpected challenge — the speed of delivery itself:
“Once organizations have gone CI/CD, they realize they’ve got what they wanted. They’ve got a lot of velocity, much more innovation, and things are flying to production left and right. That’s great but that freaks them out as well. How do they ensure compliance? How do they make sure that what’s happening is safe and secure and respects their policies? One solution is to inspect things regularly but that doesn’t ensure success. Adding friction is the very thing we’ve tried to move away from for years, so that’s not an option.”
— Sacha Labourey
This is a real tension in mature DevOps environments: governance and compliance requirements can conflict directly with the low-friction delivery pipelines teams have worked hard to build. Manual gates and periodic audits reintroduce exactly the kind of slowdowns CI/CD was designed to eliminate.
Software Delivery Management: The “Brain” of DevOps
CloudBees’ proposed answer to the governance problem is a concept Labourey calls Software Delivery Management (SDM):
“The next level up that we’re building now is called software delivery management (SDM). SDM is the brain of DevOps. As a CI/CD layer, we get to orchestrate all of the steps from left to right. We know all of those tools. That also means we receive all of the signals from those tools and today those signals are being lost in the ether. What we’re doing is capturing those signals in the brain of DevOps and to see it as a normalized DevOps data model for the past signals, the current signal, the future signals.”
— Sacha Labourey
In practical terms, SDM aims to:
- Aggregate telemetry and event data from all tools in the software delivery pipeline
- Build a unified, normalized data model spanning historical, current, and anticipated pipeline states
- Enable declarative policy enforcement — for example, requiring that specific security scans or approval gates occur before any application reaches production, without prescribing exactly when or how
- Provide a bird’s-eye view of software delivery health across teams and business units
“You will be able to say declaratively, ‘I want to make sure that any application that goes to production needs to go through those channels. I don’t care when it takes place, how you want to do it, it just needs to happen.’ If it doesn’t happen, you can block and verify if you want to be lenient or not, but you do it in a declarative fashion. That’s what we see is needed for the future of DevOps.”
— Sacha Labourey
The analogy Labourey draws is to enterprise resource planning (ERP) or customer relationship management (CRM) systems — management layers that provide visibility and control above the factory floor. Jenkins and related tools remain the factory floor; SDM is the management layer on top.
The Role of Fear in Driving DevOps Adoption
On the question of what actually motivates organizations to adopt DevOps, Labourey was candid:
“The leaders typically have some kind of legionnaire at the top who says, ‘The future is moving here; let’s go.’ They’re the lucky few. Typically, what we see as the real driver of change is fear. Fear of competition. Until you feel it in your guts that you need to move, you’ll find excuses to hide behind. When it does happen, it can be stressful, and you need to move fast. That’s why we see a lot of people around here who need to find a way to get started. It’s not easy because you need buy-in from the top, you need the right motion from the field, and all of this somehow needs to magically happen.”
— Sacha Labourey
This matches a commonly observed pattern in enterprise technology adoption: competitive pressure and fear of disruption tend to be more reliable catalysts than abstract efficiency arguments alone.
Where Jenkins Fits in the CloudBees Portfolio
Labourey described the Jenkins ecosystem — including Jenkins X and the products acquired through the Electric Cloud acquisition (ElectricFlow and ElectricAccelerator) — as the “factory floor” of CloudBees’ platform:
“We’ve been good at creating the factory floor. That’s where digital goods are being created. If you think about Jenkins, Jenkins X, or the acquisition we’ve done for Electric Cloud with Electric Flow and Electric Accelerator, they all fit on this factory floor. Now we are building a step up on top of that — the ERP or CRM that is going to manage that. It’s giving visibility to where the bottlenecks are, into where you can improve the situation. That’s really for us the next layer up. We still need to have a strong factory floor at the bottom.”
— Sacha Labourey
This positions Jenkins and its derivatives as execution engines, while the SDM layer adds strategic visibility, policy management, and cross-team coordination on top.
The Google Cloud Partnership and the Anthos Integration
One of the most significant announcements at the conference was CloudBees’ partnership with Google Cloud to build a joint DevOps platform leveraging Anthos — Google’s platform for managing Kubernetes workloads consistently across on-premises infrastructure and public cloud environments.
Labourey framed the shift toward cloud-centric thinking in terms of an astronomical metaphor:
“What Google is doing is like a Copernican Revolution. For a long time, the cloud has been perceived as the thing that revolves around the Earth. We thought all of the core assets had to be on premise and you would burst or scale out to the public cloud, but the center was still the Earth. What we’re seeing in the last few years is this Copernican Revolution where the center becomes the sun and the Earth is rotating around it. That means the sun — the public cloud — is really the center of our system.”
— Sacha Labourey
On the practical role of Anthos in this shift:
“A lot of companies think that if they can use the same deployment framework and the same environment, it’s going to be much simpler. But deploying and maintaining Kubernetes could be a lot of work. Thanks to Anthos, they get a way to get their Kubernetes clusters on premise and managed by Google.”
— Sacha Labourey
The value proposition here is consistent management of Kubernetes clusters whether they run on-premises or in Google Cloud, reducing the operational overhead that has historically been a barrier to hybrid cloud adoption.
Key Takeaways for DevOps Engineers
- CI/CD is a floor, not a ceiling. Organizations that have mastered continuous integration and delivery face a new set of governance and compliance challenges that raw pipeline speed cannot solve on its own.
- Software Delivery Management (SDM) is CloudBees’ answer: a data-driven management layer that captures pipeline signals, enforces declarative policies, and provides executive-level visibility without reintroducing manual friction.
- Jenkins remains central to the CloudBees platform, alongside Jenkins X and the Electric Cloud product line, forming the execution layer underneath SDM.
- The Google Cloud / Anthos partnership targets enterprises navigating hybrid cloud adoption, offering consistent Kubernetes cluster management across on-premises and cloud environments as a path to accelerating cloud-first delivery.
- Cultural and organizational change remain the hardest part of DevOps adoption — competitive fear, not technical readiness, is often the real catalyst.