Patrick Debois - The Father of DevOps

Andre Pino: So I'm joined by Patrick Debois, the CTO of Small Town Heroes, and longtime DevOps advocate. Patrick, welcome.

Patrick Debois: Well, welcome back. It's great to be on the show.

Andre: Thank you. Patrick, you've been clearly one of the early DevOps thought leaders and advocates. Can you tell us a little bit about your background in IT, how you got involved in those early days of DevOps?

Patrick: Well, I was – I think what year was it – 2008. I was working with agile people in development group and doing support. I wanted to be as flexible and as fast as them in infrastructure. I started exploring the idea of agile infrastructure. In 2009, I got the idea of organizing the first DevOps Days, because clearly, I wanted to have development and operations folks work together. I guess I was kind of patient zero by creating first event, and by accident coining the term DevOps with the first event. From there, it just started all over the world.

Andre: The DevOps Days have been extremely successful, well received, well attended, all around the world. What's most amazing is they are – yeah, so the DevOps Days have been a huge success around the world. I can't believe how many cities you can find them in. To me, what's most amazing is that they are all produced and managed locally. Congratulations. What a great way to get the DevOps message out there, and to get people involved around the world. Patrick, what are you doing now at Small Town Heroes?

Patrick: I am currently working in the media sector, so everything with television and video shows, and we're kind of building a Periscope-like, Facebook-like or Snapchat stories for broadcasters, so they can build it within their own app, within their own analytics, their own CRM. So they want to have everything of the new media, but they don't want to have it always on the social platforms. So that's basically what we do.

Andre: Yeah, that's really interesting. So are you involved in any kind of DevOps work at Small Town Heroes?

Patrick: Well, I'm CTO and still do the support, and I work together with the devs. So yes, I would say I'm still doing DevOps. I still do a lot of deploys - Amazon stuff, a bit on the side, but my main focus is actually to have the mobile people, the front-end people, back-end people, infrastructure people, to actually have them collaborate. My main job is to challenge the different groups, and have them collaborate and just produce better and faster results because a lot of our jobs is in the peak of a life event. So we really need that collaboration in case something happens during a show or something similar.

Andre: Sure, makes perfect sense. As the father of DevOps, of the term for sure, as you take a look back over the last several years, what do you see with respect to the way the DevOps movement has grown across the world? I'm very curious in your thoughts on that.

Patrick: I think in the beginning there was a kind of disbelief from the existing traditional thinking people, that kind of grew with the passion. I think mainly because of it improving people's life and their expressiveness to do their work better. Then I think the business picked it up and saw the advantages and saw the passion from the people who are doing this – the multiple deploys a day. They wanted to achieve the same thing. After the initial excitement, the early practitioners, I think it got more – not saying more institutionalized, but the practices got known. They got shared. Over the last years, we're seeing banks and more traditional companies taking over. Myself, I'm looking into – it bridges the gap between Dev and Ops. We're still bridging the gap to security people and maybe to other parts of the company. I'm looking – as a startup, I'm also looking to collaboration across companies by using external services, services that are clearly vital to your own environment, but they're outside their company. So it's almost, in a traditional sense of a supply chain that you're working with your partners. That's how I, in a nutshell, see progress like from the Dev and the Ops, inside the team, go to the business. Now we're putting in extra silos like security and HR, and now we're even moving outside the companies. That's my take on it.

Andre: As you think about that across the world, do you see differences in different geographies, like Europe versus North America versus Asia Pac? Or do you see this pretty homogenous across the world?

Patrick: I think if I would compare Europe and US, I think traditionally US people think bigger because their region is bigger. They can do things on a bigger scale. Within Europe, it's often more fragmented as a scale level, unless you're a startup that can scale internationally with your service, but otherwise, it'll be more local to your country or your region. In essence, it doesn't really matter whether you're facing deploys of a region of Belgium or a region from the US. There are some differences, but it's more of the mindset like you want to build things repeatable. You probably need more people if your geography's greater because your base is greater. You put more effort to it. I think – the mindset of managing the two things is the same. So that's one difference, I think, on the size. The second would be more management style. If I would take Silicon Valley style, that would go like "Oh yes, okay. It's a new idea. Let's apply this. Let's go for it." It's more of the startup mentality whereas in Europe, it'll probably lag a little bit more because of our social security system, taking risk is not that much, or like being a startup is less promoted, because there's a lot of safety nets and the adoption though is rising, but I think it was faster in the US.

Andre: Yeah, I would tend to agree with that. One of the things we've seen is people have this fear of DevOps. They're somewhat frightened by the notion of doing multiple deploys a day. Do you still see this fear as you go out around the world?

Patrick: I never saw it actually as fear. I see it more like people that forget that in order to run you have to take steps first. I usually say even the poster child, like the Netflix and the Etsy people of this world, it took them four years to get up to that level. It's not an instant level you achieve, whether it's that your people skills or your technical skills. People say – often think when I employ the same tools as these companies, I can do the same things, but they forget that it's actually just a grow process of a couple of years, where you stop doing Git commits, and pulls directly into production and just move up the maturity level. I think that's kind of my take on it.

Andre: Yeah, makes perfect sense. You touched on security and DevOps just a little while ago. One of the things we're seeing is the topic of DevOps Sec is starting to gain a foothold. Can you talk more about what you're seeing with respect to security and DevOps?

Patrick: I think the – I see a lot of people within the security world see the benefit from automation and faster collaboration. It used to be this kind of contract or guidelines where it took like a month or longer to do patching, and now with the automation, they can get a much faster relationship, which in some cases security requires. Zero days, or whatever you want in security, is just moving so fast. Your logging, your metrics, everything if you want to have it better under control. So I see that again, it's a matter of your security people also getting on board for the journey that'll take them time to understand that being able to do multiple deploys, which is not the end goal, but to react faster to things or to change things faster in case there is an emergency, that is a real benefit for them.

Andre: Great. It looks like you and Gene Kim, Jez Humble, John Willis, and John Allspaw have all collaborated on this most recent book to come out of IT Revolution, the DevOps Handbook. How's the book doing these days?

Patrick: From what I hear, it's doing well. I've got to admit, I haven't actually had the courage to read the final copy.

Andre: [laughter] I started –

Patrick: I had so many discussions in different areas with the whole crew, and I always find it hard when it's written down, it's kind of set in stone. It is obviously a good summary and it's widespread. I think it takes some willingness to absorb all the ideas and the little nuggets that are in there. I can understand somebody might be overwhelmed, and then I can also understand somebody might be underwhelmed, because it might not have enough of step 1, 2, 3. Do this. It still requires a lot of thinking, and to think how this would apply in your context, but I think that's the value that the book brings. It's not the 1, 2, 3, step. It's also not the one trick – do this. It's a broad variety. I wouldn't say pick your own poison, but pick your own benefit.

Andre: Yeah, I've not finished it yet. I've started reading it. I think that you're right. I think it's one of those books that after you read it, you realize there's much you need to be able to take in, and so a second read is definitely well worth it. So the DevOps Days communities that you helped to launch around the world, which have been tremendously successful, have helped to create local communities around the world where they get together and discuss their experiences with DevOps. From your perspective, has this been able to translate into organizational solutions or a value add for businesses?

Patrick: I'm pretty sure. There's actually companies that are mimicking the same DevOps Days event structure and doing it internally. I think I often see like 5 or 10 people from the same company being sent. Obviously they might drink a little bit of wine or beer together, they see it as, "This is a place where we can discuss things amongst peers." The knowledge sharing is not only unilateral by listening to something you probably could listen to a video online, but the fact that you can have the one-on-one discussions with people. I have numerous people, especially in the early days, send me mails like, "You changed the way how I think about this job." "You changed my job because it became more enjoyable." I'm pretty sure companies wouldn't send me these kinds of kudos, but I'm pretty sure if the employee is more energized and willing to do his job in a good way, I'm pretty sure that's a big benefit to them as well.

Andre: Absolutely. I know that you and Bridget Kromhout have collaborated also in the past on DevOps Days, and other things. How did you first get connected with Bridget because we've had her on the show as well. She has a great deal to add to the DevOps discussion.

Patrick: Totally. I think about the first five years. Not that I was a specific leader of DevOps Days, but I think I was the most active person in the group around the world with a lot of help from others. I think a couple of years ago, I said "I'm going to retire." Bridget took on the role of kind of – what do you call it – chair, or most energizing person on the team that is actually doing it. I think I met her the first time at Velocity in Santa Clara and then I also saw the work she was doing in Minneapolis DevOps Days. She seemed like a person who had so much energy. We discussed this and she found it a great honor to just continue the DevOps Days all over the world. It's often – the community drives itself, but a little fine structure like a website or the format or a place they can go to for questions or kind of that part, she's been taking a lot of the early days and made them clearer to everybody what the goal was. A lot in the beginning was a lot of feeling days. "Oh, we think that's the right way. That's the right format. Let's try this." Later, she externalized a lot of our thinking to the people now organizing the events.

Andre: Sure. I think that, as I mentioned before, I think those DevOps Days have been truly very influential in helping to spread the DevOps message around the world, and helping people to learn in practice how to utilize some of the DevOps best practices. Patrick, as you look at this DevOps movement as we see it today, where do you see it all going? What do you think the future is for DevOps?

Patrick: This is where I get my crystal ball. I see some hints. I have my ideas on the third parties. I think it's bound to become embedded another way how we look at things. What's interesting for me to observe, being there from the early start, is that some people are kind of dismissing it as the new thing isn't DevOps anymore. It might be serverless, or it might be Docker, or it might be something. They're kind of shopping around. Personally, I don't mind them thinking like this, but what I do mind is that they're kind of dismissing sometimes new ideas as a fad or the next thing, and then they're moving onto the next. They dismiss it almost by saying, "Well, the old thing didn't help us. Let's try this new thing." That's a mentality that I don't know – I would love to break that, whatever new comes around doesn't bash the old thing. A lot of people in the early days were bashing ITIL, which isn't bad, but you always have to see things within perspective or within their timeframe. Then we add things on it. The same thing went on with config management. And then Docker and then serverless. There's this thing of people looking at the previous and saying "Wow, that was the old way." I would always say it was a different way. Within the context, it was a good way, but now we're just building on top of that. If they hadn't been here before, we wouldn't be where we are now. That's kind of my take on it.

Andre: I think that's right. I think that people who think that way also miss the point that DevOps is not a thing. It's not something you buy and you implement it. It's a culture. It's a whole transformation of not only the way IT develops and delivers software. It's also the way IT interacts with the business. That's, to me, one of the most important valuable aspects of DevOps. So Patrick, anything else that you'd like to discuss that I didn't ask you about today?

Patrick: I'm good. I'm just about to be – tomorrow I'm going to be on a plane for DevOps Days Beijing. That's going to be an interesting trip. But for the rest, all is good.

Andre: Enjoy the trip. Safe travels, and thank you so much for joining us today.

Patrick: You're welcome.