Is DevOps Dead?

In this episode of the DevOps Sauna, Darren and Pinja discuss DevOps itself, covering its history, impact, and whether we'll need to change the name of this podcast in the future.

[Darren] (0:03 - 0:22)

Getting out of the way of creative people and allowing them to be creative is the best way to get out of them what you want.

Welcome to the DevOps Sauna, the podcast where we deep dive into the world of DevOps, platform engineering, security, and more as we explore the future of development.

[Pinja] (0:22 - 0:32)

Join us as we dive into the heart of DevOps, one story at a time. Whether you're a seasoned practitioner or only starting your DevOps journey, we're happy to welcome you into the DevOps Sauna.

[Darren] (0:37 - 0:43)

Welcome back once again to the DevOps Sauna. Hi, I'm again joined by Pinja. How are you doing today, Pinja?

[Pinja] (0:44 - 0:46)

I'm good. Hello, Darren. How about you?

[Darren] (0:46 - 1:02)

I'm doing reasonably well. We have a bit of a shorter week with Easter just having happened, so a lot of people are on holiday, and it's been a bit quiet. And we've had a chance to discuss the accidental debunking of certain myths we've been doing over the last couple of episodes.

[Pinja] (1:02 - 1:28)

Yeah, so we've already talked about is Jenkins dead? And is Agile dead? But if we actually talk about DevOps itself, as we keep seeing and hearing, that DevOps is now dead.

And that's kind of unfortunate from our perspective, if that is true, because the podcast is indeed called the DevOps Sauna. So, do we really need to change the name of the podcast?

[Darren] (1:28 - 1:31)

Yeah, do we have to become the Platform Engineering Sauna?

[Pinja] (1:31 - 1:33)

Oh, that would be something. Yeah.

[Darren] (1:33 - 1:38)

I think it's even worse from a company's perspective, because don't we still brand ourselves as the DevOps company?

[Pinja] (1:38 - 1:39)

We do.

[Darren] (1:39 - 1:44)

That's a minor issue if it turns out DevOps is, in fact, dead.

[Pinja] (1:44 - 2:02)

So let's see, within this discussion, we actually come to the conclusion that number one, we need to change the name of this podcast. And number two, if Eficode as a company needs to rebrand itself and go change everything on the website, so maybe, maybe, but maybe this is a myth that we need to debunk here.

[Darren] (2:03 - 2:06)

Yeah. So we're going to make some momentous decisions today.

[Pinja] (2:06 - 2:06)

Exactly.

[Darren] (2:07 - 2:45)

But like, let's talk about where DevOps came from, because I'm at least almost old enough to remember the time pre DevOps where things were bare metal, like, you know, when 2007 DevOps started, I think we looked that up. And it was basically having its origins around there that time, you know, 2007, I would have been, you know, university, it's like, not entirely clear to me what the world was like before DevOps, where the things were just being deployed randomly by random people. But I at least remember when people weren't doing anything along those lines, but it was an entertaining buzzword.

[Pinja] (2:46 - 3:50)

Yeah, I think it was around that time, at least according to the reliable sources on the internet, when the Father of DevOps, so-called father of DevOps, Patrick Debois, recognized that there is a need for Dev and Ops to work together. And I guess that was also the name that came from that. But it took 2008, there was an Agile conference, and Andrew Schaefer had created this meeting called the Birds of a Feather meeting.

And he wanted to talk about the Agile infrastructure in this meeting. But since he didn't think anybody would come, even though he was the one to organize this, he thought that nobody would come. So he himself didn't show up to this meeting at all.

But who ended up showing up to this meeting was Patrick Debois himself. And he went looking for Andrew, and he really wanted to talk about agile infrastructure. And he thought that this would be the solution of getting operations to get to the same level of Agility as the developers were at the same time.

So this was one of the moments in the history of DevOps that started the movement.

[Darren] (3:50 - 4:22)

Honestly, it's kind of unsurprising to me, I guess, in a way, because I feel like there's a lot of uncertainty around the entire field of DevOps, that it's one of those things that's just so difficult to pin down. And the fact that I know now that it got started from a guy not even showing up to his own meeting, just kind of cements that point. I feel like, yeah, so 2009, it got started, but I think we're still struggling to understand what DevOps is now.

[Pinja] (4:22 - 5:21)

Yeah. And I've said many times that if you were to ask a hundred Eficodeans, and let's just go back to what we said before, we're a company who lives from DevOps, and we've branded ourselves as a company around DevOps. If you were to ask 100 Eficodeans, what do you think DevOps is?

You will get at least 102 different answers on this one. But if we really think, what was it originally? What was it meant to be?

And the whole idea of, for example, Andrew Schaefer not thinking, nobody will show up. And Patrick Debois being the only one who actually wanted to talk to him about this. And I talked to some of my colleagues and some of my friends about this.

And they were around that time working in development, perhaps in IT, and it took them a while to actually understand, like, wow, maybe I need one of those DevOps into my company as well. Can I have one of those DevOpses, please? But it took a while to understand the necessity of why Dev and Ops should actually work together.

[Darren] (5:22 - 5:25)

One box of DevOps, please, delivered straight to your door.

[Pinja] (5:25 - 5:26)

Yeah, exactly.

[Darren] (5:27 - 6:31)

The issue, I think, we have is that DevOps has become so nebulous. It was originally this fusion of development and operations, obviously, but it then kind of expanded to include so much more, but also not so much more, just the kind of support systems around development and operations. So, project management started getting pulled in, all these methodologies started getting pulled in, everything started coming together under this umbrella.

And I think that's where the problem starts, because I think in DevOps, we kind of have a branding problem. As you say, you talk to a hundred DevOps specialists. We have, I think, we're at like six, 700 people in our company by now.

And there are a lot of very technical people and a lot of non-technical people. And if you ask where they come in, in this merging of development and operations, the answer is not clear. And yet we see everyday that their role is absolutely vital to the merging of development and operations.

So you have this fuzzy definition.

[Pinja] (6:32 - 7:03)

Yeah. And I always make a joke about this. I say, I'm the tree hugger who says that everything is DevOps that is related to delivery.

And then when I talk to my colleagues who are more on the product management side, and I say, well, product management is part of DevOps. And they say, no, no, no, DevOps is part of product management. So we've had this debate, for example, where do we draw the lines?

What is part of what? And as you say, it's very fuzzy and everything is now DevOps. And at the same time, we do see that there is a need to do things better.

[Darren] (7:04 - 8:06)

Yeah. The need to improve, I think, is what causes this rebranding problem because back in, I want to say 2019, but I feel like the dates are not right. But several years ago, we saw this shift towards this idea of platform engineering and what platform engineering is, is building up the kind of internal development platform, building these layers of abstraction around the internal development platform to really focus on developer experience, to make sure that they get everything they need out of their IDP and that there's no or limited overhead for things like security, which should just happen and compliance, which should just happen or the parts of DevOps that come into it, they should just happen.

And this was confusing to me because firstly, it was like, yeah, this is all the technical parts of DevOps that interest me as a technical person. But also I just sat there thinking, is that not just DevOps done correctly?

[Pinja] (8:07 - 9:15)

Yeah. And here we think of like, how do we make lives easier for developers? How do we minimize, as I say, the overhead and minimize the context switches and cognitive load, for example, so that our experts are able to focus on what they do the best.

They wouldn't have to actually go into separate systems, and they would see in one class what's going on. And here we are at the moment in time, in basically one part of the history of DevOps. In five years, we're looking back now.

So, is DevOps and platform engineering that different? If we think in a couple of years time, do we still call DevOps DevOps? Do we still call it or do we now call it platform engineering?

Which is part of which? So is there still room for something else than platform engineering? Which, by the way, I do see that is exceptionally necessary in times like this.

And it has created so many good things in the companies that we've seen and the industry itself. So I'm not saying here, and neither is Darren, you're not saying here that this is an unnecessary step, right? But it's more about what else is needed around it, right?

[Darren] (9:16 - 10:53)

Yeah, I think no, I'm not saying anything negative about platform engineering. As I just said, platform engineering contains all the parts of DevOps that I enjoy. Yeah, like that's everything, that's what I do for a living.

That's what's fun for me. I think it's better if we take a step outside of ourselves because we're all DevOps experts. We are the people who work with DevOps.

The people who are listening to this podcast probably have an interest in DevOps. They probably understand it at least partially or are looking into it because they identified a need. The problem from our perspective and from an external perspective is very different in that I feel like we're trying to sell a moving target.

So DevOps occurred and people started building towards DevOps and now everyone's in a race to kind of try and claim the next big thing. And, you know, the next big thing could be platform engineering. It could be this idea we've discussed before of progressive delivery.

It's these things that are, in my opinion, falling under the same umbrella. And if we look at that externally, how does a person who is not a DevOps expert perceive this? How do they look at this and see, OK, what's the difference between DevOps and platform engineering?

If we had a couple of websites we looked into, like, obviously, you go to platformengineering.org, and there's one, “DevOps is dead, long live platform engineering”. And they're obviously not the most unbiased source. But then you go to the other side, you go to DevOps.com, and you'll find a post basically saying that platform engineering is under the DevOps umbrella.

[Pinja] (10:53 - 11:30)

And if you go to Reddit, which usually is, of course, one of the most reliable sources of information, and there draws the conversation like, hey, do not take a job in the field of DevOps, because that's a totally dead industry by now. And why wouldn't we trust experts on Reddit? But it's a very interesting debate.

And if we think of the rebranding that happened a couple of years ago from Twitter to X, it's really hard for me, at least, personally, to still say X instead of Twitter. Sometimes I end up correcting myself, but sometimes I know that people will understand if I say Twitter, right?

[Darren] (11:30 - 13:21)

I think you're actually quite good at the use of X. Like, my brain has steadfastly refused to call it X. It is Twitter, and it will be until Elon Musk begrudgingly shuts down the service.

Like, you can't take something that's part of the zeitgeist and rename it. People just won't listen. And I think we actually have something similar happening here.

There's this whole nerd versus geek argument where you have a Venn diagram, and on one side are nerds, and on the other side are geeks. And the intersection point are the people who have a strong opinion on the difference between them, because they've been labeled one and would prefer to be labeled another. And my opinion is the same thing is happening with DevOps and platform engineering.

There are people who will have strong opinions on the differences between DevOps and platform engineering, and I think the people who will try and make them extremely separate things are the ones who will be trying to sell you one or the other, whereas I feel like the people in the middle who develop this understanding that platform engineering without DevOps around it is not going to be a useful thing for your developers, and not going to be a useful thing for your Developer Experience.

And DevOps, without going into this requirement of an IDP, of a developer platform, serves no purpose. It's supported without the actual main function. We come back to this value stream map that I mentioned a lot, that former colleague Mark had quite a lot, where he had this huge value stream with dozens of boxes, and noted that value was only added in two places where development was occurring.

So DevOps, without looking at the developer experience and making these platforms, this platform engineering, is just, to me, they work in synchronicity.

[Pinja] (13:21 - 14:10)

Yeah. And what I started to think here is that this is something we discussed when we were talking about, is Agile dead? That since people are disappointed in Agile, are people disappointed in DevOps and how they've been doing DevOps?

And is that the reason why they're searching for something new to say that, hey, this is now going to save us, this is now going to make us work better, it's going to make our CI/CD better? Because we're talking about continuous services and we always want to deliver the best value possible, right? So is it so that we discussed before here that are we now looking for the right way to do DevOps instead of the quote marks, so-called wrong way of doing DevOps that was not working for us?

And it is easier now to think that this is something completely different and not in a way that, hey, we're just trying to do DevOps but better.

[Darren] (14:10 - 15:07)

I think you've kind of nailed it there that a lot of people are unhappy with how DevOps has been deployed in their companies because DevOps is so nebulous. Like if you go to the Wikipedia page for DevOps, one of the first things you will read are the words, although debated, DevOps is characterized by key principles. And there are four different links attached to this, although debated.

So we start by having this system where no one's quite sure what's supposed to go into it. They build it in a way that might be, like they build it without the proper strategy in place. So they're building it to look like what their neighbors look like or what the books tell them it's supposed to look like.

And then they get kind of disappointed with it, and they decide, okay, we need something new. We now try platform engineering, not realizing the platform engineering is also just a step they should have done in the first deployment.

[Pinja] (15:07 - 15:54)

Yeah, as I said, it requires so many things around it. Platform engineering is solving a lot of problems when it comes to developer experience and developer productivity. And at the same time, if we think about what is needed around it, because it's a whole organization around it.

So, say product management, for example, my colleagues who are very much into this topic might again start disagreeing with me and say that is not part of DevOps, it's the other way around. But regardless, whatever happens during the development process, when we're using IDPs, actually it needs product management. So somebody to tell that part of the organization what needs to be done and why it needs to be done.

So it's good that we're doing things the right way, but we also need to do the right things and in the right way for us to get the most optimal value out at the end of the value stream.

[Darren] (15:55 - 16:34)

On this objective, the project management versus DevOps, that happens across the board. Like we have our security manager, Jussi Helminen, he and I are constantly locked in a debate about whether information security is part of cyber security or cyber security is part of information security. And it always comes down to everyone thinking that what they have is the chicken and what everyone else has is the egg.

Of course, as a nerd, I think information security is part of cybersecurity. And him, as the compliance expert, he thinks that information security contains cybersecurity, and neither of us is willing to move. So we see this across the board.

[Pinja] (16:35 - 16:39)

Yeah. So, as a nerd versus geek, quite literally, I guess, in this.

[Darren] (16:39 - 16:50)

Exactly. The sensible thing for us to do would just be to use the title security and have them both next to each other. But that would require one of us backing down.

That's not going to happen. So.

[Pinja] (16:50 - 17:23)

Yeah. And let's go back a little bit down the history again. So what did we want to do with DevOps in the first place?

And let's take the father of DevOps, Patrick Debois, again, and his definition of DevOps. As I said previously, if you take 100 Eficodeans, you will get 102 definitions at least. But Patrick Debois said that, well, we just want to break down the silos.

We want to minimize the friction between the silos. So the delivery and integration should be seamless. So I guess it should not differ that much from platform engineering, right?

[Darren] (17:23 - 18:59)

No, not really. And it's exactly like we talked about with Agile. It's breaking it down to the core concept.

What was DevOps supposed to do? And if you ask what DevOps was supposed to do and you think the answer to that is to implement platform engineering. Great.

You are absolutely right. And if you look at what you wanted DevOps to do and think the answer is to go back and reimplement DevOps properly. Congratulations.

You're right. That's exactly the correct answer. These things are, they're the same.

They're designed to make it so that the developer can do what they want. Because I've come back to this a number of times that I don't know anyone who is a developer because it's a job they felt was a good way to make money or a good stable career choice. I mean, I'm sure it can be both of those things, but the people I know who are developers are developers because they like to build things.

Development is a job of passion and interest. It's not, in my experience, a thing that people are doing because they need a nine-to-five. It's something they'd be doing anyway.

If they were working outside the tech industry, they'd be coding in their spare time. So it's a creative process more than it is anything else. And getting out of the way of creative people and allowing them to be creative is the best way to get out of them what you want.

And both DevOps and platform engineering have that as the core concept.

[Pinja] (19:00 - 19:21)

Yeah. And when we allow our creative people to actually create, again, we go back to the value. And with DevOps, so often we're focused on the CI/CD because that's at the very, I know it's at the very core of it, but there's so much more to it.

And the focus is on the delivery chain, but does our customer really care about our CI/CD?

[Darren] (19:21 - 19:22)

No, never.

[Pinja] (19:22 - 19:27)

And this is something perhaps controversial, but does the management really care about CI/CD?

[Darren] (19:27 - 20:36)

I think as the DevOps professionals, we would hope that they would, but no, like they care about a big picture. And that picture is that their software is getting into the hands of the people who will pay them for it. And that's entirely fine.

That's how business is supposed to work. So there's this kind of maybe a cynical idea that if we focus on CI/CD and this idea of platform engineering, that it is trying to pull back the idea of tech. Because as I said, the platform engineering involves all the tech parts that I like about DevOps and occasionally seems to exclude the critical human parts.

And that's not correct. That's not how platform engineering is designed. And that's not how platform engineering should be implemented.

As a counterpoint, we can look at cybersecurity. What is it like? 70-80% of incidents are caused by humans. You can't exclude humans from the development process.

And I think that's where some of the backlash towards platform engineering comes from, because it looks a lot like older systems, which were very tech focused.

[Pinja] (20:37 - 21:07)

And that's not, as you say, the core of platform engineering is completely the opposite of getting away from the human aspect here. So once again, we've all seen those crafts of how many different kinds of interruptions a developer gets during the day. And God knows how long it takes them to get back into the zone of actually creating things and from which they were interrupted.

So we cannot move away from the people, because the people are the core element that are creating the value. So it's not one or the other when it comes to tech versus non-tech here.

[Darren] (21:07 - 21:13)

Right? Yeah. And we should also, because we have to talk a little bit about AI in all of our podcasts, because it's 2025.

[Pinja] (21:14 - 21:14)

Obviously.

[Darren] (21:15 - 21:53)

This isn't going to change when it comes to artificial intelligence. You still need humans in the loop. They just switch more to the verification rules.

And this also means that they need their experience to be as seamless as possible. So if you're thinking I can get rid of the human side by getting rid of the humans. No, it doesn't work like that.

But we'll probably talk more about that in a different episode. The platform engineering to me is like, it's about the abstraction to reduce the cognitive overhead by putting it onto the platform team who know how to handle it, instead of relying on everyone to understand it, which they shouldn't need to.

[Pinja] (21:53 - 22:32)

Yeah. And again, if you're doing platform engineering, you still need the other parts of DevOps. They're not completely shutting each other out, but they're instead complementary.

And we do want to, everybody wants to do DevOps the right way. And yeah, we can call it platform engineering. I think it's still part of DevOps.

There are other new terms around this area, but it's more about figuring out in the whole value chain, what needs to be fixed? What are the points really where the value is created? Remove friction from that.

Who needs to be involved? Who do we need to talk to? And again, that highlights the human aspect of it, because we cannot remove the human aspect here.

[Darren] (22:33 - 23:06)

And I think another thing to take away from this is we're not all DevOps experts. And we have to remember that if we keep changing the target we're trying to sell, then we're just going to make it harder for the non-DevOps people to understand what it is. It's like the whole Henry Ford saying, you can have a car of any color you want as long as it's black.

We are pushing the same thing in two different directions, wrapping it up in slightly different branding. And all this is doing is confusing everyone who is not attached to DevOps and platform engineering.

[Pinja] (23:07 - 23:25)

Yeah. And if one thing that we can pull from our wonderful friends around the field of DevOps and this community, our lovely friends Emma Dahl-Jeppesen and Dan Grøndahl, what they said is that it's easier to stand on the shoulders of a giant if you kill them first. I think it applies here, too.

[Darren] (23:25 - 23:41)

Definitely. I feel like the idea of DevOps being dead is something we can just dismiss at this point. DevOps is still very much aliv,e and it needs platform engineering to keep going.

That neither are going to exist well without each other.

[Pinja] (23:41 - 23:44)

So I guess with this myth, we can say that this one was busted.

[Darren] (23:45 - 23:46)

Yeah, I guess we have to.

[Pinja] (23:47 - 23:48)

All right. That's good.

[Darren] (23:48 - 23:54)

Okay. That's all we have time for today. Thank you for joining us again in the sauna and we hope you join us next time.

Thank you, Pinja.

[Pinja] (23:54 - 24:01)

Thank you, Darren. We'll now tell you a little bit about who we are.

[Darren] (24:02 - 24:04)

I'm Darren Richardson, Security Consultant at Eficode.

[Pinja] (24:05 - 24:09)

I'm Pinja Kujala. I specialize in Agile and portfolio management topics at Eficode.

[Darren] (24:10 - 24:12)

Thanks for tuning in. We'll catch you next time.

[Pinja] (24:12 - 24:20)

And remember, if you like what you hear, please like, rate, and subscribe on your favorite podcast platform. It means the world to us.