The Next Steps for DevOps: an Interview With CloudBees CEO Sacha Labourey
The Next Steps for DevOps: an Interview With CloudBees CEO Sacha Labourey
CloudBees CEO Sacha Labourey discusses the move from Continuous Integration to Delivery, and what the next steps are for DevOps.
Join the DZone community and get the full member experience.Join For Free
Discover how quick and easy it is to secure secrets, so you can get back to doing what you love. Try Conjur, a free open source security service for developers.
What’s new at CloudBees? Any cool news for JUC West?
The underlying change we’re going through that really started a year ago is this big shift from continuous integration to continuous delivery. Last year, we announced the release of Jenkins Workflow to be able to build models of the continuous delivery pipeline, and not just build jobs on top of Jenkins. So that was the meta construct of continuous delivery, and what makes it possible to draw the diagram, if you will.
Here, we’ve worked hard to release a number of features around Docker. We see a lot of companies using Docker now either along the full lifecycle or simply in build/test staging, but Docker really takes a lot of importance. As a lot of companies are moving to continuous delivery in stages, so they don’t move the entire company to continuous delivery processes overnight, they start with specific projects, and the adoption features of Docker-like projects turns out to be less difficult, right? Since you have to do new changes anyway, why not implement technologies like Docker? So that’s very exciting.
Last year you moved away from the PaaS industry to focus on Jenkins. Could you talk about CloudBees’ evolution from PaaS to Jenkins to Continuous Delivery?
When we started the company, we had the vision that we could accelerate the way companies create value through software. That’s why we had three pieces, not just the PaaS, because it was pretty different. We had not just a deployment platform, but a more complete offering with the source code repository, you had Jenkins-as-a-Service in the cloud fully managed for you, and we had the full-fledged platform-as-a-service so you could do continuous delivery in the cloud, with the full pipeline set up for you. So that was our vision.
As we talked to more companies, we came to realize that a lot of people really liked the idea of what we were doing, but because of our business model we were kind of forcing one way to do things. So it had to be public cloud, it had to be on our own platform-as-a-service. So we were mandating a way to do things and people were telling us “we like your stuff but for this project we’d like to deploy to Elastic Beanstalk or to a AWS machine or on-premise.” We were restricting ourself to a tiny set of use cases, so we decided to refocus on Jenkins, though we expanded the use cases we offered by doing that. I don’t think this change in strategy would have been necessary 3-4 years ago because at that time all the rage was around continuous integration. Continuous integration focuses on developers, but developers typically don’t have the keys to the budget. As we move to continuous delivery and DevOps transformation, we can reach a lot more people in the organization, and so it was a much easier go-to-market for us.
What should we be looking forward to as far as new technology is concerned in the world of CD and DevOps?
We’re seeing the emergence of very powerful lego blocks, if you will. We have Docker, obviously, and we have Jenkins serving as a hub of continuous delivery extension. We also have a competition in the market around cloud orchestration, like Mesos or Kubernetes. We have the same thing taking place with repositories: you have things like jFrog and Docker. I think all of those layers will play and do play an important role. In the future, obviously we’re going to start to see the emergence of new innovation as always, that’s not going to change, but I think what’s going to be very important for users is the integration between those components and the use cases that are becoming very well-defined.
Today what's sometimes slowing down the adoption of continuous delivery is not so much the lack of tools. Every company is slightly different, and there is sometimes a lack of confidence in how to achieve these results. What are the best practices? So every company tends to have a mini-view on their specific ecosystem, and I think what’s going to mature over the next few years is more partnership and more best practices among vendors which will definitely ease the adoption of continuous delivery.
So less “every one for themselves” and more industry cooperation and standards?
Exactly. I think today you have all these experts who lead the pace, and they all know how to do it within their company, but not everybody can afford to have the best experts in the world, right? So I think it’s about the democratization of continuous delivery becoming much more mainstream, and that requires a lot of best practices, a lot of pre-touch messaging, if you will, and I see that growing a lot.
What do you think, as the CEO of a continuous delivery company, some of those best practices ought to be?
Typically, what we advise customers to do is to first focus on simple, small projects. We see companies say “okay, we want to move to continuous delivery” and they start this big plan. That never works. Big bang approach doesn’t work. Then if you have a knee-deep project, companies cannot really look at all of the problems or constraints in their business. They find a mini-project that assembles all of constraints they can see and think “if this project works, we can succeed with all projects.” I think this is very wrong, because most of the problems when adopting CD do not come from complicated problems we can’t solve technically. Most of the time it comes from lack of culture, lack of expertise, or lack of confidence.
So you better pick a team that is motivated to succeed, because sometimes you find teams that are afraid of change. So find the right team, find a simple project, and get started. That alone will be huge because you can start building a culture of success. You can showcase that project in your office, and it only expands from there, so you can work on more projects and establish your best practices within the company. You have to nurture a knowledge base that is specific to your company. Just those two pieces of advice can help you be more successful with your project.
Sometimes what’s also useful for larger organization is to listen to some consultants who specialize in continuous delivery. It can help to force a change, and it’s often too easy to fall back on the good old principles of non-CD software development, so having someone on board can stop you from falling back on that behavior, but everything you do fits with your strategy.
As far as culture goes, what’s a good way to convince people that CD is the way to go?
The best thing to say is to tell them that their job is likely to become much more interesting. When you look at a project in an organization, a lot of boring tasks are very manual. You can also look at the interaction among teams, and it's all about conflicting interests. You have business owners creating this massive project description, they fit it to IT, IT works a lot on it, 18 months later it’s not something the market wants and business is pissed. Nobody wants to feel responsible for that failure, when business made a project people do not need, and IT only did what they were asked. A lot of that is déjà vu, and that’s tiring and less motivating.
Showing how working through an interactive project with a tight integration between business and IT I think can make everyone’s job much more interesting, and everyone can have a much better life. You have a continuum of stories to tell to show that this is the way forward. Obviously the business benefits are huge, but ultimately what needs to be understood is that we’re moving into an era where software is leading the world. Any company that is not good about producing value through software will have a big issue down the road. There’s a famous quote from Eric Shinseki: “If you don’t like change you’re going to like irrelevance even less.” I think this applies very much to these kinds of transformations.
What do you think are some of the huge DevOps challenges we’ll have to adapt to in the next few years.
The biggest DevOps challenge is this: we have high-level concepts like CD, DevOps, and so on. Then we start to have quality blocks like Jenkins, Docker, repositories, and so on. But then we have all this underlying infrastructure and we tend to forget it. That’s great, and part of the benefit of cloud: we get machines when we want. But I think having a complete well-managed stack top-to-bottom is still going to take time. Firewalls, routines, switching, etc. These need to be well-integrated with the top-level decisions that need to happen.
Is there anything you think the DZone audience needs to know?
We’re still in a phase where Jenkins workflow is getting very good adoption, and I think its pretty transformative to see that happen. I already told you about that, so I’m just sharing my personal excitement!
Opinions expressed by DZone contributors are their own.