Highlighting the possibilities of continuous integration and continuous delivery (CI/CD) was a key theme at the DevOps World / Jenkins World conference in San Francisco, and Sacha Labourey, CEO and founder of CloudBees, took some time to talk about the role his company has in the landscape.
CloudBees, the host of the conference, is a developer of an automated software delivery systems based on Jenkins, an open source automation server that helps with software deployment. During the conference, CloudBees announced that it was partnering with Google Cloud to develop a DevOps platform that would draw technology from Anthos, the hybrid cloud platform Google announced in the spring.
Labourey spoke with InformationWeek about the ways continuous integration and continuous delivery continue to evolve and what the new partnership with Google will mean for CloudBees.
Why did you start this conference to bring together professionals in DevOps and continuous delivery?
“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 there are a lot of people sharing tricks, sharing pain points, and how they solve them.
What has CloudBees been working on that speaks to the evolution you see in the DevOps space?
“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.
“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.
“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.
“We get to create policies and processes to connect different parts of the business and IT to have a bird’s eye view of what is going on in IT. So 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 a lenient or not, but you do it in a declarative fashion. That’s what we see is needed for the future of DevOps.
How much of this is a hard wakeup call for organizations that have not yet taken any steps into DevOps? Is there a lot of handholding?
“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 it, 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 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.
Where does Jenkins fit in CloudBees?
“We’ve been good at doing is create the factory floor. That’s where goods are being created. They are digital goods. 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.
What will the partnership with Google Cloud mean for CloudBees?
“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 this 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. The question is ‘how do you accelerate that movement?’ A lot of companies think that if they can use the same deployment framework, 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.”