In this episode my guest is a well-known DevOps expert. It is a great honour for me and I am proud to have the chance to talk about DevOps with Patrick Debois. He is known as one of the authors of the DevOps Handbook together with Gene Kim, Jez Humble and John Willis. And he created the DevOpsDays, the first DevOps Conference ever. First question is always the same and under this circumstances very special: „How would you define or describe „DevOps“? We continue to talk about the DevOpsDays which started in 2009 and the changes within the last 10 Years. Patrick accompanied DevOps for that lopng time and we are talking about his most satisfaying moment or experience with DevOps and his disappointment. This episode provide a very personal view from Patrick.
In this episode, Dierk Söllner interviews Patrick Debois, a renowned DevOps expert, where they delve into the evolution of DevOps, its impact on the industry, and speculate about its future. The discussion highlights the emergence of DevOps Days, the role of collaboration in DevOps, the shift towards human and cultural elements, challenges in integrating DevOps practices in traditional organizations, and the rising importance of DevSecOps. The conversation also touches upon the need for a balance between adopting new tools and frameworks and maintaining an effective collaborative work environment.
Inhalt
- Introduction to DevOps and its evolution
- Role of collaboration in DevOps success
- Changes and trends in DevOps Days over the years
- Challenges in integrating DevOps in different organizational cultures
- The rise and importance of DevSecOps
- The impact of tooling and frameworks in DevOps practices
- The potential future directions of DevOps
- Personal experiences and anecdotes related to DevOps implementation
Shownotes
DevOpsDay weltweit
Patrick Debois auf Twitter
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
Happy New Year and a warm welcome to all the listeners of my podcast DevOps auf die Ohren
und ins Hirn, which means DevOps right through your ears into your brain.
Usually it is a German-speaking podcast. Today it’s the third time with an international guest,
so I would like to switch to English. My name is Dirk Zöllner and I’m working as a consultant,
trainer and coach for DevOps. I’m one of roundabout 15 DASA DevOps Ambassadors all
over the world and was selected for Germany. To my point of view, DevOps covers cultural,
organizational and technical aspects. In this podcast, I’m talking about these
things with experts. Today, my guest is a well-known DevOps expert. It is a great honor
for me and I am proud to have you here, Patrick Dubois. He is known as one of the authors of
the DevOps Handbook and together with Gene Kim, Jess Humble and John Willis. And he created the
DevOps Days, the first DevOps conference ever. This episode is called 10 Years After Birth.
So, hello Patrick. I decided not to introduce you deeply. Could you please do that for me and all
the listeners? I was going to say Guten Morgen, Dirk. Thank you. So yeah, I guess most people
know me from DevOps Days and having started DevOps. I’ve been a consultant for about 20 plus
years and I think my background has been in
doing different roles, being a tester, being a developer, being an ops person, being a manager,
being a product owner. So that’s kind of how working in these different groups I got together
on DevOps as such. So I’ve worked a lot in government, but also in startups. So the more
diversity I have in my life, the more interesting it gets. Sounds great. So
thanks a lot. First question is always the same. How would you define or describe DevOps?
Yeah, it’s the million dollar question, right? For me, DevOps is about collaborating so we can
do our each of our jobs better. And for me, I want to stress that part on the collaboration.
I think from that , we’ve seen the results happen that there have been
new practices emerged new tool sets. And the speed of which we could do things has
improved, some would say, It was the pressure of the speed that Goddard’s collaborating.
But I think the main point is the collaboration that drives
better results. So on one hand it’s getting toato the content is going up, and the change is in direction. And so on. One of the things that really definitely dirt hard, and I was also an ableist about it in my personal experience, that this makes planning that’s very fascinating. We are designed by pelo, 먼 woodpecker working with a lot of field believers andchat people.ул e junglegusion need training in architecture assistance. I think from that, we’ve seen the results happen that they have been new practices
Das ist in Theorie, wenn man es von einer Systemtheorie-Perspektive betrachtet,
die Summe ist mehr als jede individuelle Teilnahme.
Das ist mein Hintergrund, wie ich DevOps sehe.
Oh, großartig. Ich habe die DevOps-Tage erwähnt.
Sie haben 2009 angefangen und letztes Jahr hattest du das 10. Jahrhundert.
Wie haben sich die DevOps-Tage in den letzten zehn Jahren verändert?
Es war in den ersten Jahren ein bisschen unter dem Boden, weil es nicht so bekannt war.
Ich denke, es ist in einem breiteren Spektrum weitergegangen.
Ich denke, die Themen sind in einem Weg verändert, in dem wir über die Jahre viele verschiedene Perspektiven gehabt haben.
Ich denke, die Pattern sind besser.
Ich denke, die Pattern der Menschen und der Kultur sind in einem Weg verändert,
in dem es die predominante Teilnahme der Konferenz wird,
die einige nicht mögen, weil es immer noch ein großer Teil der Technologie ist.
Was faszinierend ist, ist, wie es sich über die Welt verbreitet.
Leute wie Bridget Krumhout, die jetzt die DevOps-Tage-Kurve leitet,
wissen, wie sie sich über die Welt verbreitet.
Sie haben viel Arbeit in der Dokumentierung und die Leute, die sie selbst verbreiten, gefordert.
Es ist faszinierend, dass sich das weltweit verbreitet.
Und etwas, was mich wirklich beeindruckt, ist, dass das Jahr Brasilien so viele Events eröffnet
und es einfach weitergeht.
Es macht mich ein bisschen traurig, dass wir nach zehn Jahren immer noch so viele Events eröffnen,
dass wir nach zehn Jahren immer noch so viele Events eröffnen, dass wir einfach weitergehen. Es macht mich ein bisschen traurig, dass wir nach zehn Jahren immer noch so viele Events eröffnen,
dass wir nach zehn Jahren immer noch so viele Events eröffnen, jetzt weil wir nach den ersten Jahren immer noch so viele Dinge reden.
Und es macht mich eigentlich ein bisschen traurig, dass wir wieder auf der Ebene dieser Informationen kró 걱정en originally speaking about these things,
mainly in our own conferences.
So, yes, there are DevOps tracks in other conferences, but originally I would have hoped that it was almost common knowledge
und nicht ganz heftig saddle, dass die Connections der Conference die alles was Horizonte geben würde
oder dass die Conference nicht mehr da ist und siephou Honoris im Unterschied’de Crystal
integration would be integrated in all the other conferences of development and operations and so on.
Also, es ist Prozesse, aber das macht nichts.irez chỉ kurz einen kompletten, hervorgehens teenagers-romen verteidiger Forum von害ouverweise.
It’s good to still talk about it and it’s good to see things,
but in a way it’s sad that we created another separate conference
and sometimes it feels a little bit like an echo chamber.
Right. It’s a little bit like building a DevOps silo, right?
Just talking about DevOps on our conferences, not on every conferences.
Correct, yes. It is still interesting. There’s a lot of good talks.
So I’m not saying that, but I think maybe it’s overall what annoys me
is that the adoption is still a long way from being embedded as a good common practice.
Yes, it would be better doing DevOps than talking about DevOps.
Well, yeah, but you’ve got to have both, right?
Yes, right.
You said that the change was a little bit that human and culture is more on the top.
Do you have some examples for that?
Well, like patterns or things like empathy really came into a couple of years ago.
And then…
You know, concepts…
It’s like maybe more like T-shaped people and groups doing, celebrating retrospectives.
So it’s less on the technical side that it’s about cloud or any technology,
but more on these human kind of aspects of collaborating and working in enterprise.
Also burnout has been a big topic that come up.
I know it comes up in maybe other conferences as well,
but the fact that we are, as DevOps days, not a technology only focused,
we do get a lot of talks on that as well.
Right. So we talked about what has changed to the DevOps days
and how did DevOps itself change in the last years from your perspective?
Well, the change in the industry…
It’s almost like the industry has decided on what DevOps is.
And I think 85%, you know, give or take, it means deployment and faster deploys.
And in a way that I would have hoped for more on the collaboration aspect, as I said before.
But for a lot of people, it is the…
You know, the deployment…
It’s the deployment tool and the pipeline.
There’s still, you know, there’s a lot of people still…
I’m not going to say fighting the good cause,
but it’s almost like explaining that it’s more than the tool set.
But I think the industry has settled on what it is.
And we are beyond any change on that.
But from my perspective,
I think any of the larger industry movements,
whether it was ITIL or Agile,
for some reason, they get more reduced over time to the tool set.
Whether ITIL was the whole ticket system and the control software
and Agile was about the testing and the, you know, the scrum kind of tool set.
I think it’s…
You know, it seems to be natural.
It shouldn’t be like that, but it’s apparently something we in the industry,
what we remember on a certain, you know, buzzword or something.
But in a way, it doesn’t really matter because it did change people’s lives.
You know, sometimes I get these emails like, yes, you changed my job.
And I’m now much happier than I was before.
And, you know, that’s really rewarding.
And I think, you know, people will build upon that for the next thing.
And it’s good.
And, you know, we don’t have to be sad, but we could have expected something different.
But it is what it is.
So.
Yes.
So you talked about or you mentioned collaboration and results.
So I think that would be a good thing.
Yeah.
I think that will be the or could be the next steps.
Doing better collaboration to get better results and to engage with customers.
Could be the next 10 years or the next year’s change with DevOps or to DevOps.
Last year, I mentioned that DevOps Days had the 10th anniversary.
I think there were a lot of interviews.
You had to give last year.
What questions are not asked, which you would have liked to hear and to answered?
Well, I can tell you the question I got all the time.
What’s the next thing?
Okay.
But the question I would like to hear, it’s hard to say.
For me.
I can only speak from my perspective.
Yeah.
Yeah.
It’s interesting.
I think that is in a way that I find it fascinating with anything that the collaboration was
within our companies.
And I experienced in my own company that when you use a lot of SaaS solutions, the
authority of those companies lie outside of your authority.
And it’s interesting how collaborative.
Yeah.
It’s interesting how collaboration is working in that perspective, because you cannot ask the people from Amazon, you cannot ask the people from your CI system to sit next to you and to talk to you all the time.
So I found that, you know, fascinating how collaboration would work in this kind of services world.
And yeah, so that’s something, you know, that interests me.
And I don’t know if that’s, you know, something they had to ask, but, you know, that’s something that keeps, you know, me going as a puzzle.
Right. Okay. So you changed my life was something you mentioned from emails to guys they sent you.
Sometimes I have the impression or get the impression that this is a question.
A question of experience and of age, because I think younger people are more DevOps-like than older one.
What do you think about that?
Well, it’s, you know, it’s definitely harder to change after you’ve been doing something for a long time.
And, you know, I wouldn’t say this is young.
And old, it’s, I don’t know, maybe it is because I’m old and I can’t say that.
You are not old, you are experienced.
Yeah.
Like me.
The experience is also, I would say, they would probably see the benefit easier,
because they’ve lived through the pain much more.
So I can’t really decide what, what, but yes, they can, you know, the younger people or the less experienced people can change and they, they maybe not know the difference because they don’t have, you know, the pain experience and the more experience they do.
So, but in both cases, it could mean a difference of, yes, the person next to me doesn’t talk to me.
I always have to do this, you know, manual jobs, which aren’t interesting.
But now.
So, you know, giving in a good context where I come into a company where people talk to me, where I am accepted for who I am.
I think that is still largely from both perspectives.
But you get to appreciate it more if you see, you have seen more bad examples from it.
So maybe it’s a little bit black and white.
But I think.
I often met people who are complaining and they are, they do not change.
So I think the, the younger ones, the younger people are more focusing on collaborating and more focusing on the reals, the results.
They want to do a good job.
It’s my impression.
And the older one, they may complain, they may have felt the pain, but I would, I would like to have them more working on the, the pain and change their, their business.
And they.
I would like to have them more working on the, the pain and change their, their business.
Yeah.
What’s interesting to me is that sometimes I have the impression that I would say that DevOps has been a zeitgeist in a way that on social media, the trend was to collaborate, to work together, to share information.
And that, that same general sense of community.
And.
Whether it’s now in you know in for having a, a greener environment or other things, this kind of shift in authority almost, most has, you know, had an impact on DevOps as well.
And that’s what younger people are used to is that they, they don’t blindly accept authority top down.
Like waterfall.
And that, and that’s something I’ve seen change in general on how management inside companies has changed as well.
In the past, you, you, you know, you had the, the architect somewhere up there deciding what needs to be done and then, you know, you get decided further down the chain.
But now you almost have to find consensus.
Your voice, even if it’s in Spanish.
experienced is equal to any other so you have to defend you have to explain you
have to listen a lot more to make a more balanced decision if you continue to look
into the past what was your most satisfying moment or experience with
DevOps I think the and it’s it’s it’s a very strange example I’m gonna give for
for DevOps but I when I worked into for a government company we were doing a
lot of we were building a portal and it wasn’t until we started working with one
of the almost like a politician that we we made some progress so what happened
is that
he would uh he would trust us to do the right thing on the technology and then he would go
uh defend that solution uh to other people and um it’s almost like this this blind trust uh between
uh you know two people um and it didn’t mean that we had to do everything ourselves or uh or that
just like the one amplifies the other uh and I know this example is outside of death and OPS uh
and you help him that you can achieve like a lot better results on uh you know than before
yes it’s an example for human changing for culture and for collaboration right just outside DevOps but
It should be a normal way to work with each other.
Yes, and I think in my talk in DevOps Days,
I also gave the examples of collaborating outside of DevOps
with marketing, with sales, with legal,
and to make the whole company improve,
and not just the pipeline,
because a lot has been written on the pipeline,
and you can keep on improving the pipeline,
but after a certain point, it might just be enough.
And I think that’s another interesting part of the discussion,
is that when your bottleneck moves
and isn’t anymore in the pipeline,
you should work on that.
And it’s something I see not happen a lot,
because people would say,
yes, but I will improve my pipeline,
and then everything goes better.
But there’s so much…
There’s so much around the pipeline
that needs to be resolved as well.
Right, so I think the IT inside the companies will change itself.
So we’re talking something about BizDevOps
to engage more business into DevOps,
and I think it’s the right way, you said,
integrating more business and moving the bottleneck
maybe outside the IT, outside the pipeline.
Yeah.
And it’s also a matter of trust.
Let’s say somebody in the ops team,
let’s say that…
Let me find the example.
If they would say a developer…
Oh, yeah, I know the example.
So somebody made fun of me during the DevOps Days
and said, the DevOps Days website uses Git
to change the website.
And normally, you would have to send like a pull request
and asking people to have a peer review
and then submit or commit it to the site.
And what I did,
and I changed it immediately on master.
I didn’t go to a pull request.
And they said, well, you can’t do that.
And it made me think like, yes, I understand.
There’s the pull request and the peer review.
But this was like changing two letters in my name.
Okay.
So, you know, where’s the trust in, you know,
I would have taken ownership if something would have failed.
But how can we be so stuck in the process of saying,
well, you’d have to have a peer review, right?
So there is a matter of trust that still needs to be there.
Somehow so.
Yes, okay, right.
So that was talking about satisfying moments or experience.
And what was the greatest disappointment?
Well, the greatest disappointment was a company
where I tried so hard to explain things and to help things.
But I got the impression that they were throwing more hoops at me
as before.
Because they…
They didn’t believe in DevOps.
They believed that by specifying everything in a document,
that that was the way to go.
And it made me realize that it’s sometimes,
you know, DevOps goes on to a fundamental belief
that you believe that collaboration does improve things.
And if you don’t believe it,
you have a hard time defending it.
And there is no, you know, if somebody doesn’t believe in that
and he still believes in, you know, you need to specify everything
from top to bottom and more of a waterfall approach,
there is no way you’re going to convince him.
If the belief is not there that, you know, it will improve things.
And that was a really hard job.
And I tried for, let’s say, a year, and then I moved on.
Because, you know, if it doesn’t make sense, it doesn’t make sense.
Yes, I got these disappointment points like you for smaller steps,
not for companies itself, but in smaller projects.
I do get this impression too.
So they’re talking about DevOps.
They are talking about being agile, but they are not agile.
They are doing some events from Scrum or something like on.
They’re building a board on the wall,
but they do not change their mindset and all the things like that.
Yeah, I read a funny tweet.
I forgot.
It was somebody who was really known in the agile world,
but I forgot who it was.
And he said, I’m going to change my consultancy fee.
So the first hours are,
let’s say, the first days are for free.
And then after a while, my price will just increase very fast, very high.
And he said, the reason why I would do that is that I would have already
explained everything in the first two days and me having to repeat that all the time.
You know, if you want me to do that, it will cost you a lot.
Okay, right.
So, okay.
Yes.
Regarding the last 10 years of DevOps,
what happened that you did not expect?
I think the, you know,
having the different groups in there is something I expected.
I think the more ceremonial things like retrospectives and burnouts,
that’s something I wouldn’t have anticipated.
I think the more ceremonial things like retrospectives and burnouts,
that’s something I would have anticipated that we would have anticipated before,
that we would result in such a strong, you know,
collaboration practices beyond that.
It’s probably because for me personally, again,
I hadn’t seen that happen before during my jobs.
Yes, you know, talking to others.
Yes, yes, collaborating.
But having that almost like formalized in a way that,
Other people could do that. That was really interesting for me to see that we could take those practices outside of one company and do that in others.
Yes, okay, right. So, I think that DevOps is a movement. It’s not a framework. I think you would agree to that. What do you think about all the frameworks like Scrum, ITIL or SAFe regarding DevOps? How is the point for that?
I think every framework gives you a model to think in.
I don’t think…
Every model has its flaws and its good things, but it’s almost like when you, let’s say, if you’re a developer and you see a new tool and you have this belief that this tool will solve your problems.
And the reason why that you often have that feeling is that because you haven’t used it already.
But once you start using it, you…
You would see its flaws and problems. And, you know, yes, we shifted our way of thinking, but now new problems arise. So, you can’t escape complexity. And I think it’s very similar with these models. Yes, they give you a framework to think about.
I think there’s…
The nice thing is that if it’s written down, then, you know, people can read the same thing.
They can report on the same problem.
Otherwise, everybody has their, like, special snowflake model.
But, and here I say, but, it’s almost like Scrum, but, you know, there’s always, like, exceptions.
And sometimes you don’t realize the nuances of why practices are done in a certain way.
After you…
You’ve done it for them for a while.
But I think it’s great that people keep describing them.
You know, I love to read that.
But it’s a little bit like certifications.
You know, I like certifications in a way that it pressures you to learn the space.
It pressures you to not only learn the aspects that you’re used to doing, but also other aspects.
But when you would say a certain certification, when you attain the certification doesn’t mean you know everything about it.
And it’s similar to a framework.
Yes, it has its good things.
And yes, you can use it.
But if you use it almost like fundamentalistically, only the framework is right, then I will probably not believe you.
I came across…
A framework that integrates framework, like the Bossa Nova.
And that’s interesting because they kind of mix things together and they kind of show overlaps and point out similarities in frameworks.
So, you know, that’s how I think about, you know, whenever a new framework comes out.
Yes, I will read it.
Yes, I will try to understand it.
Also, I understand the context, where it works, why.
And then it’s an extra thing in my tool set to kind of, you know, work with that.
Yes, so although I’m selling trainings and certifications, I prefer more the workshops or trainings without certifications, without exams.
Because just looking your first sentence was collaboration and results.
So, if I do have a workshop without exam, without certification.
There’s a lot of more collaboration and we are a lot more focusing on the results and on the content, but not on the exam.
And presenting my knowledge to someone who questioned me something.
So, it’s okay.
That’s an interesting observation there.
So, but how would you translate that inside a company context?
So, that means like introducing a new tool would, it’s almost like when you don’t put pressure on it, then it might get accepted.
And if you put the pressure on there, you know, everybody will go against it or something.
I don’t know what the equivalent is.
So, if you put a pressure on a new tool, you would say, okay, this is the new tool and you have to use it after 14 days of training on the new tool.
And so, I think the…
My perspective of DevOps and modern work is to work together, to collaborate, just you said, and to get the things, the best things out of it.
Cherry picking, you might call it.
And so, cherry picking from a new tool or from a new framework and look, okay, so this is a good thing.
We can change it, but not to use all the things of the frameworks, not deciding, not discussing, no discussing.
And so, cherry picking from a new tool or from a new framework and look, okay, so this is a good thing.
We can change it, but not to use all the things of the frameworks and not discussing, no discussing, no discussing.
Yeah, that’s a good point.
As a coach and trainer, I often work with administrators in DevOps context.
Sometimes I get the impression that these guys are not really amused working with Scrum or Kanban.
Do you think there are different types of people within DevOps companies?
Both.
That’s the jump between both.
Right.
I can see many reasons.
I can’t work with Kanban and Scrum.
But let me first take that.
I think over the years, it’s been interesting.
We work with different customers.
And once in a while, a new customer comes up and he says like, yes, and we’re just starting on our Scrum journey and we’re doing the sprints.
And it’s a good thing.
They have the mindset to change.
They have the will to change.
There’s a project.
So that’s good.
But for example, the Scrum sprint period, let’s say they would do two weeks.
If you need something done right now, let’s say an urgent thing from the ops perspective, from production perspective.
Sometimes you get this pushback.
Let’s say.
No, no, no.
It’s not part of our current scope, right?
So in a way, I understand that the Sprint protects people for new things flowing in.
But if you are so stubborn to say no, nothing new comes in and you don’t even consider it, whether you need to swap something in or out during your Scrum Sprint, you know, that that makes me sad as well.
So, you know, that’s just an example.
I’ve.
I’ve experienced on having agile teams versus an ops team, because in ops, a lot of things can be urgent because, you know, you need to react quite fast.
And that’s why I like the Kanban approach often better if there’s a if let’s say the ops part is has a lot more incidents or things that would happen that needs urgent attention.
Then that makes sense, because in that way, when you limit the work in progress, you can always say, what’s the most important?
Let’s do that first.
I don’t know if that makes sense on that part.
You’re talking about the dev team and the ops team.
And to my perspective, my goal is to engage both in one team.
So to have a dev ops team, what do you think about that?
Well, they can certainly be part of the same team.
You know, there’s there’s been a lot of discussion whether you can call it a dev ops team or not.
Personally, I don’t I don’t care that much as long as, you know, you know, you collaborate and you get results.
I think what’s what’s been interesting in what I see happening in the industry right now is that, you know, they some people yell fire when they say they see you call it a dev ops team.
But now.
Yeah.
Yeah.
Yeah.
Yeah.
I mean, obviously, I do think that the dev ops team is one of the most important, but also a term that comes up quite often is the platform team.
So it makes sense to be a little bit to look a little bit strange when you just rebrand your ops team to the dev ops team and you don’t collaborate.
But what I see is that the platform team is almost like the ops team from before.
self-servicing to the other teams and they see themselves as the enabler of other parts of the
team instead of being the final part of the delivery chain that has to control everything
so it’s a fundamental mind shift whether you’re an enabler that allows things to happen
and trusts the you know development to do things in production or you you don’t trust them and
you’re gonna be the bottleneck who always says no and uh you know whatever the name
i think that’s what we try to go against uh for um i was reading i was watching an episode
of presentation on devsecops yesterday
from etsy and um for example they the fact that um let’s say in a company somebody changes a very
important configuration file and um there’s two ways of going about it you would say well we make
changing impossible and if you want to change that you would have to have approval from six people
and then you can change that but let’s assume that
same configuration file is quite often needed if things go wrong um do you allow somebody to change
that file or not it’s very similar to the you know the git you know master commit do you trust
somebody to do that um and um i think the point he made was um well the point is that everybody
gets notified not that somebody everybody has to agree if if if you what they did was they put like
yes if you change this file six people will get notified are you sure you want to do this
and they put the ownership and to that person to make that call
instead of blocking it and i think that’s a good example of the difference between
a traditional ops team or you know the way they used to work versus a new array of working where
you empower other people or you make them self-service to do things and you listen to
what they need so yes right i think it’s a really good example and it and it refers also to your
point to your this definition of devops it’s about collaboration and results and talking about
results and
um having good results so uh this year you will focus on devsec ops you told me so just uh
looking uh for for for the thing what what is the the new for you talking about devsec ops
well i’ve um you know last year i um the the last five years i i run a little company
and uh you know we we decided to to
end it um last year and uh i figured like what’s um what am i gonna do in the new year so there’s
so many options and uh i was at the conference in in november at devops rex in paris uh where
i gave a talk and uh i came out in the in in the sponsor area almost every booth was devsec ops
um and it might have been that you know being too busy with running my own company
in an area of devsec ops and you know i was at the conference and i was not keeping tap on
anything in the devsecops industry um specifically um you know that made me just interested to you
know figure out like where can we help where can we uh maybe uh help in some tooling evangelizing
uh on devsecops sometimes it feels a little bit different from devops and sometimes it doesn’t uh
there’s
i think a bigger
I focus on tooling in general, but I found it just, you know, I have also a background in previous jobs on security.
And, you know, I’m looking forward to going back to those parts and to learn more about the space.
But like I said before, the example on collaborating between changing that file from a security perspective,
those are the kind of examples I’m looking for in the DevSecOps space.
So, yes, the tooling is going to be interesting, but also those practices.
Because what I noticed is when DevOps goes faster, we do a lot of changes.
And there is, you know, work to be done on how to, I’m not going to say control,
but how to deal with the impact of those changes in a fast way.
If you, you know, if we were doing waterfall in the infrastructure
and it would take us a long time to send an update or a patch, we would just be more vulnerable.
So because we now got our pipeline under control and we can do a lot more, a lot faster changes.
It’s interesting how that actually changes the security.
It’s interesting how that actually changes the security level of a company as well.
And we’ve experienced that firsthand.
In my previous company, we were doing live television shows.
So support for live television shows.
And, you know, there’s voting, there’s gaming.
And if people start to kind of abuse your, you know, to win a prize or something else.
Yes.
So I think with this will lead me to my last question.
And I want to start with you.
So I think with this will lead me to my last question.
I want to step back to the title of this episode.
Is DevOps adult and mature enough?
What do you think?
What will happen to DevOps within the next five or 10 years?
Well, the interesting part is that there’s still a lot of companies still discovering DevOps.
So it will just continue as it is before.
I think, you know,
DevSecOps is interesting because it’s almost like a new field extension.
And I would imagine like BizDevOps or others, there will just start being extensions.
And it will be confusing with the, you know, the name, whether that’s still DevOps or good or bad.
But, you know, to say that it’s mature.
Like I said before, people have made up their minds that,
a lot of the DevOps is the deployment pipeline and all the tooling around it.
And they will look for something new.
And, you know, maybe some people would extend DevOps for that and some would have a new buzzword for that.
But I think the nice thing is we’re, at least I hope, is that we’re still progressing as a profession to, you know, to do things better.
So.
Yeah.
To do things better.
Yeah.
To do things better.
To collaborate better and to get better results.
So, right.
Life is changing.
The world is changing.
The names are changing.
So there will be no problem to have some changing in the last year, in the next years.
Yeah, correct.
And the interesting part is that I don’t have any shares in DevOps or companies.
So, you know, whatever happens is the right thing.
So.
So that’s what my daughter says.
She’s 20 years old.
And she always says, okay, what happens, it happens.
It should have happened.
So, right.
Thank you, Patrick.
Thanks.
Thanks a lot for this episode.
Thanks a lot for sharing your insights, sharing your opinions.
And I hope to see you again on Twitter.
So we will meet there.
And thank you again for that.
Definitely.
Thank you for being, that I could be on the show.
So, next time.
Maybe I try a little bit of German.