We’re so glad you’re here. You can expect all the best TNS content to arrive
Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences
and even join additional groups.
Check out the latest featured and trending stories while you wait for your
first TNS newsletter.
Patrick Debois is known as the godfather of DevOps. He is also the founder of the DevOpsDays volunteer-led event series which now has spread to more than 30 cities around the world, and the co-author of “The DevOps Handbook.”
As The New Stack continues to explore platform engineering — which some say is rising in response DevOps challenges — and software development team productivity, it only made sense we sit down with Debois for a deep-dive conversation around the past, present and future of DevOps. We dive deep into how DevOps and platform teams can motivate developers, especially around the all-important topic of security.
Patrick Debois: I’ve been around for a long time — as you can see with the gray hair — as an engineer. My passion has always been about learning something new, and over my career, starting in ’93. I’ve been a developer, a tester, a system administrator, and also on the management track. Currently, I’m working as a VP of engineering at Showpad. I did startups. I did enterprise. Governments.
I’m always trying to find something new every three, four years. This is maybe what has led me in 2009 to the concept of DevOps, where we were experimenting with agile and it was so much fun.
How would you define DevOps in the shortest most concise definition possible?
I tried to summarize this once in a tweet: DevOps is about removing the friction between silos. All the rest is engineering.
Initially, we’re very focused on removing the Dev and Ops collaboration silo. At that time developers lived in their own world, Ops lived in their own world. As we progressed, we got more friends around the kind of indie organization. We got the testers on board with CI/CD. We got the security people on board.
Why I’ve made the definition so broad is that it could be any silo, but sometimes your bottleneck is not technical. You might want to fix how you hire people. Or that your product is not charging the right things or has no business visibility. Some people call this DevSecOps, QA, biz, whatever, as the long term.
It depends. There are several layers. Business will tell you [DevOps] is about delivering more frequently, at a lower cost. Then there’s the frustration of one team not reaching a certain goal or not being able to do their job. The third layer — that maybe does not get much attention — is actually the individual because there’s nothing more frustrating than working without results and not having an impact. So in that way, I think DevOps is removing friction for the business, removing it for the groups that work on a day-to-day basis, and then the individual.
That all sounds well and good, but, for most organizations, their focus of DevOps tends to be on the operations side. Developers often feel excluded from DevOps. If you could rename, would you name it something different than DevOps?
DevOps [began] at that same time we were going to the cloud, so there was a bigger revolution going on in the land of infrastructure and operations. At the same time, you could say agile had the pressure of going to the business and that was developer.
I think that friction of delivery is the focus and it’s not like getting one area or the other area better, because they both had a frustration. So I would not name it differently.
Maybe now, things have changed in a way that it’s not that clear cut anymore. We’re not Dev and Ops separately. Now, we’re more: we have 15 teams, they’re all running their own stuff, and they need to start collaborating. So we just shifted the complexity of frustration to that number of teams.
I think that is the manifestation of platform engineering — an approach that actually tackles cross-silo collaboration. As the silos have reshaped themselves in the org, we needed to find a new kind of procedure or mechanism to deal with that.
How do you think platform engineering fits into the DevOps world or is DevOps dead?
Platform engineering is a manifestation of DevOps. It is not one or the other. It’s not contradictory. It’s not old or new. You’re bridging that collaboration. And the mechanism today is different than what used to be, where the DevOps team was something and now maybe the platform team is there.
Why do you think platform engineering has suddenly become such a hot topic developer productivity this year, or even the last six months?
I think that the shape of organizations has changed. Before you had the big group that was the developers, the big group that was the operations. Then everybody started organizing the pizza teams as the new way of working but then they realized that if you give all these teams autonomy, there are certain things that stop working well.
There’s the fact that we all have different ways of collaborating and working. Like, when one team leaves, who takes the ownership? Who’s looking at the economies of scale of cost across all the teams? Who is setting the golden path, that we’re not reinventing the wheel over and over again?
As people have been on that journey from two groups to a lot of groups, a lot of people in the industry are acknowledging that we need to re-shift those new problem areas [with] a new way of resolving them — which is the platform team.
The developer experience is a grow-up emotion by saying when cloud came from the hardware to the cloud, it was about self-servicing that was important. And then once you have the self-servicing, it is about keeping your business — talking to them, evangelizing, making best use of the spend or the solution you’ve built. When everything has shifted, they then had to start doing that advocacy from that central team to kind of prove that it’s useful for others. Those kind of authority days are over. So we have to win the hearts and minds and listen to our customer, which is the different teams that need certain things to make their job happen.
I don’t think so. When you talk about the platform, I would say it’s like a rebranding of [the DevOps] team to the new space. If you think about it broadly, platforms in a company are everywhere. There is a data platform. There is an application platform, in the middle layer. Maybe there are other connecting platforms that you need to build. So then it becomes more of an umbrella where you say well platforms is broader than DevOps. Because what I usually see is that the the traditional people who were rebranded to DevOps, they stay in the in infrastructure realm.
But the abstractions are always getting higher. Who’s going to run the middleware layer? It’s not going to be the hardware people, but you need some people who deal with, like, who’s going to organize the front end, kind of the developer experience and platform or the front end platform so don’t see one-on-one mapping. DevOps should be there [and] can certainly be part of the platform team, as such.
One of your obsessions is DevSecOps. As we examine the order of importance in this portmanteau, how does security fit between developers and operations?
When Dev and Ops got better at working with each other, there was one group that was still grumbling at the increased velocity of those teams — security. They had to make sure that like everything was vetted and, all of a sudden, they were being overwhelmed with more things they needed to check, more libraries, more releases, and that didn’t make sense.
At the same time, people had to learn how to do security in the cloud environment. So instead of being in the ivory tower, writing the guidelines on security, the whole notion of DevOps collaborating across your silo, got born in that group of security as well. And people started calling that collaboration DevSecOps.
There has been a movement that you need to shift left on security. That is the security people trying to go early in the value stream [to get] developers more excited about security. There’s another movement happening, where some companies then believe shifting left is enough. But, for the newer companies who have not run on the cloud security part, they have to shift right and they have to learn more about what it takes to operationally run a security business. A lot of startups tend to do the shift left part in the development part, but they have no visibility on what goes on in their production on the security level. You have to have both.
The 2020 Linux Foundation FOSS Contributor Survey found that only 3% of developers wanted to be responsible for security. Knowing that, how does platform engineering into a DevSecOps strategy?
So platform engineering provides the different teams — whether that’s developers or other groups — with a set of tools that can make their lives better, like a vulnerability scanner in your code that reports on what goes on in production.
I’m a big believer in making the pain visible. A platform team can make the security visible and say, ‘Hey, you have X amount of vulnerabilities in your repos’ [but] that does not bring the motivation of the developer. Because that will be on a spectrum. You will have those that say, ‘Here’s a ticket. Oh, yeah, I need to solve this. It’s not the light of my life.’ And then you will have the security champions. So how do we get like the people that are just seeing it as a nuisance to fix to become the ones that kind of take pride in fixing those vulnerabilities? Making it visible does not improve their kind of incentive.
But, I think it goes hand in hand — if you are writing code, you’re responsible for running it and securing it. And that balancing is a struggle because the next thing we’re going to ask is: Do better UI. Do better performance. So I’m well aware that there is a lot of balancing. And it should not be an all or nothing, drop everything, and remove all your vulnerabilities. Much like we do the error budgets, we must keep vulnerabilities on track on the trend that we’re reducing them, keeping them within certain boundaries.
I think what you can do is make it a lot easier. Make it visible. Reduce the noise so that they don’t have to debug everything, help them on the journey. And I think nobody will disagree that if it is done early, then that is better. That is also better for the developer because if something is released in production, and they’re being held accountable for that, they don’t like that.
Before we go, we have to talk about DevOpsDays. For those that don’t know, you are a white, cisgender man. How has DevOpsDays developed differently into a rarely inclusive and diverse tech event from Day One?
Interesting question. So it does not help that I’m a white male, indeed. I think there’s probably two areas: From the beginning, the rule that we tried to adhere to at DevOpsDays was about finding new ideas. So it was about looking out instead of looking inwards. So that created a large cast of a net to reach for people. For example, in the beginning, we had a rule, that if somebody has already given a talk, they do not get accepted for a talk because we wanted to have new voices in the space.
This was early in the beginning. It’s not any more like this now because we already have a broad community but it was one of the things where I said look for new voices. At those times we were turning down big speakers because we could just see their talk already on the internet, so why have that conversation again. Get new people and more local people amplified.
The fact that it turned into diversity, I would say that it has a lot to do with, if you’re in this emerging field, like DevOps in 2009, maybe there is an open mindset of listening and sharing which was there from the beginning. And those people tend to have an open vision across people as well. Also, there was a very strong push by attendees or sponsors to have more technical talks at the DevOpsDays event. In the beginning, what we always tried to do was put the cultural talks in the morning in the single track and, in the afternoon, you can talk as much tech as you want. So it tried to keep those cultural, collaborative and human things centered in the program. And again, that has led people who maybe come from an agile background, which is also a very open community anyway.
Again, from the beginning. Obviously, the broader you get, that gets changed. I find it was very up to the individuals. They really believed in keeping it open. And I think the people who chaired DevOpsDays after me really fostered over and over again to get more diversity of attendees got that as well. So it’s amazing that this has worked.
Community created roadmaps, articles, resources and journeys for
developers to help you choose your path and grow in your career.
