DevOps platforms: The end of toolchain sprawl? – CTRL+ALT+DEPLOY Ep 04

Hey everyone. I'm Alan Schmo from techron, and you are watching Ctrl Alt Deploy. Thanks for joining us.

If you're not familiar with C Control Alt Deploy, it's a webcast slash podcast that we do every other week or so, and we talk about what's happening in the DevOps world, what's happening in the platform world, what's going on in the world of software development, and it, you know, ops around that. Um, we produced Control Alt Deploy in, uh, partnership with our friends at OpenText, and they sponsored, uh, our show. So many thanks to them.

Let me jump right in here and introduce you to our panel today, and then I'll introduce today's topic. First of all, joining us in Atlanta is my friend Rickey Zachary. Ricky, if you wouldn't mind, tell people a few words about you.

Yeah, very quickly. Uh, Rickey Zachary, um, as Alan mentioned, I'm in, I'm in Atlanta, Georgia, uh, temporarily. Um, I'm the global leader of platform engineering at ThoughtWorks.

So, um, I'm really responsible for, uh, defining and spreading the platform engineering practice, DevOps, cloud native infrastructure, SRE, and observability across all of our clients globally. Nice to have, uh, nice to be on the show, Alan. Thanks.

It's great to have you on. Ricky, I know you're heading out on a, a worldwide tour, so, uh, we'll take advantage of your time when we can. Next up is Tracy Ragan from Deploy Hub.

Tracy, welcome and give people a little bit about you. Well, um, yeah, I've been in doing the DevOps for my entire career. I'm now running a company called, uh, deploy Hub, and we gather DevOps data, and we're looking at doing auto remediation of CVE vulnerabilities through the pipeline.

I'd like to introduce you to Kelly Gundler, senior Solution architect at OpenText. Kelly, welcome. Tell people a little bit about you.

Hey, thank You. It's good to be here. Yep.

I'm here in North Carolina with OpenText, um, same as Tracy. This has been most of my career back to the, the late nineties, dare I say, um, in the field of application delivery. I'm part of the solutions consulting team and I run our worldwide practice.

Fantastic. Love having you on Kelly. Thank you.

Last, but certainly not least, my friend Garima Bo Powell Reemer joins us today from ca. We have an international cast today, man, joining us from Canada Garima. Tell people a little bit about yourself.

I'm Garima bfe Am, uh, here in Ottawa, Canada. Um, I'm the founder for the DevOps Community of practice here in Canada, which has several chapters, Ottawa, Toronto, Edmonton, Atlantic provinces. I do several things in the community.

My latest, uh, big thing is we are doing DevOps for Gen AI hackathons with John Willis, our close friend. And our next talk would be Toronto. I've written two books on CI/CD, um, CI/CD design pattern, which came out last year in December.

I've also written a book on strategizing content delivery in cloud, which was released in 2023. So these books are available on Amazon as well for you to look uh at. But yeah, that's me.

Hi, Karima. Thank you, Karima. Alright, so panel, today's topic, the rise of the DevOps platform.

You know, I, I've been around DevOps since the week. First Patrick, first Patrick Debar, first coin, coin coined the term. And you know, DevOps used to be a nice toolbox of little tools, right?

There was a little chef or puppet, maybe some Ansible. You used the little Jenkins here, a little GID ops there, you know, it was, it was you picture, you pick. And, and no two DevOps teams used the same set of tools.

Everybody had a, you know, a snowflake mix of DevOps tools. Well, with the rise of things like platform engineering and, and with the scalability demands of today's organizations, people want to, you know, standardize on a platform, right? And, and so we have platform engineering, we have the rise of DevOps platforms, and all of the leading DevOps players out here are, you know, platform providers as, as they say.

Um, it's a different, it's a different mindset than stitching together a bunch of programs. Um, and then we have sort of the next gen DevOps platforms that we're now starting to see that are AI native. Some of the older DevOps platforms are grafting AI into it.

We're seeing it with internal developer platforms and platform engineering. We're seeing it in cloud native, right? Kubernetes and, and managing that where AI is, is coming in there.

We're moving to these, you know, GI ops and, and platforms and all this Garima, you have your thumb on the pulse of this. What do you, what's your take? So I'll start with some industry reports and findings, uh, pointing out Gartner, what Gartner says is in 2026, uh, 80% of large software organizations are expected, uh, to dedicate, uh, their efforts into platform engineering.

And which is kind of, uh, good news for platform engineering teams. And I would like to kind of also, um, back propagate like why this rise or shift is happening and, you know, what is fueling the shift, right? So when we started with DevOps, and this is history reminds us, it was all about collaboration, automation, lean practices, and measuring how much progress we are making by sharing our goals, right?

But in the due course of time in a decade, what we have seen is an explosion of tools and applications around DevOps, right? And, uh, a lot of open source practitioners have come together. You know, a lot of cultural change has happened in the organizations.

Now, what, at this point in time, what is fueling, uh, platform engineering investment is twofold, in my mind. The first thing is, uh, the rise of AI integration, AI native capabilities. That is what we would talk about in later in the, uh, discussion as well.

And I think, uh, to a certain extent, uh, uh, cloud providers are also realizing these platform cap companies and capabilities, which are offering streamlined developer productivity workflows, they, that is also instigating a lot of investment into this area. So I think, uh, that is what I see from my perspective. And if you see what AWS is doing or Google is doing in terms of, you know, bringing platform capabilities, not only for large organizations, but also small organizations, right?

Because platform engineering was essentially a game of LA large, uh, ecosystem. But we also see dev box, for example, from Azure, which is like, uh, pivoting platform engineering to small organizations and solo printers. Love it.

Kelly, what's, what's the OpenText view on that? So, um, seeing the, the same, I guess, um, trend. I think the tricky thing is, as much as we love the platform concept, obviously we offer a a platform for this exact case.

It's tricky because depending on the profile of the customer, you may not have the luxury of saying, let's just throw out what we've got and start over. You know, it's like a, a house tear down as much as like, I don't like my kitchen, just tear the house down and start over. Sometimes you need to start with my, and talking To my wife.

Maybe I do a little add on. Yeah, I, I called her right before this guys. Um, so that makes a difference.

And I, I think to that point, um, you know, sometimes you, you have to pick and choose what you're gonna have, be part of the platform. Maybe it's not an an all or nothing. Some of it's new on the platform.

Some of it we keep what we have and, you know, try to improve as we go. Ricky, you talked to dozens of companies about their platform choices. Yeah.

Uh, the, I think Garima and, and Kelly are correct from a trend perspective, right? That we, we are seeing the same thing. That Gartner article, um, is something that I look at quite a bit of time.

It's in a lot of my conversations that I have with clients. Uh, I, I, I think the, one of the business drivers that is driving more and more of those organizations to move towards platform engineering is the same thing that is driving them to make AI investments, which is, I want my developers, the costly developers, right? The engineers that I'm paying the hundreds of thousands of dollars to, I want them to be as effective as possible, right?

Um, so I want to give them the right tools at the right time to be effective. And, and so DevOps, I think is something that is transforming into, Hey, how do I do that at enterprise wide scale? And then how do I bring in the right capabilities, right?

How do I use the investments that I've already made and leverage them with AWS or GCP or Azure at both the practitioner level and at the organizational level. So the conversations that we're having are very similar to what Kelly described, which is, how do I take those investments that I've already made in, you know, Jenkins or GitHub actions and then propagate them across the entire organization? And Alan, to your point, a lot of that is around harmonization, around how do I kind of take all of the individual parts and pieces that my developers are doing and then scale them out across the entire enterprise.

And, and that's what we're seeing is the trend that's leading towards kind of DevOps tool chains becoming platforms. Tracy, we haven't heard from you and I, I know you have thoughts on this. I have a lot of thoughts on this guy.

I saved you for last for a reason. Tracy, go ahead. I hope that all of you are correct.

Let me just say that, but I don't see what you're talking about. You may see something that's, you know, something that you're seeing that would be the future, but I don't think, I don't do not see DevOps engineers embracing platform engineering. And let's just put it, let's just like call it what it is right now.

DevOps is job scheduling. It's a job scheduler. Every DevOps platform, every, let's just say CI/CD, which is the heart of DevOps.

It's a job scheduler. It's all it is. It's nothing else to it.

It's just, and, and what does that job scheduler do? Calls jobs. One job might be call scanning.

One job might be call build. One job might be call a, uh, a, a deployment. And hopefully maybe you're doing yes, bobs and that as well.

But for the most part, I think that we have decided that our DevOps platforms are good the way they are, and they're, it's gonna be difficult to unify A-C-I-C-D pipeline. We've had, we have seen companies try to do it for quite some time. I think Codefresh ca beca became the closest to trying, creating easy way to add integrations.

Plugins have always been a, you know, a problem for us, and they, we we're still using them after 20 years, something like that. So we have, in terms of DevOp, I'm not saying the bigger, broader platform engineering, um, industry and the interest in that, I think what platform engineers are doing are essential. Um, but even platform engineering will be unified because they're, every team has a different set of tools that they use.

And not every piece of software is identical. C and Python and Java, they're all different. They all need different tools, but there may be a certain constraint or a certain requirement or certain compliance levels that they have to meet.

And that's where the standardization has to come from. But in terms of DevOps itself, I don't see a lot of new things. Um, you, you mention, you know, there are new tools out there that are using AI to help pull together DevOps information, DevOps data, because we are stuck with all of our critical, all the essential data to be able to evolve.

DevOps are stored underneath the covers in logs, because what are we executing a job scheduler that creates logs and the logs are in build directories. And at best, maybe they get checked in to gi, but they probably don't. So DevOps itself has a very long way to go to ST to really think about how to evolve and how to start playing in the game of platform engineering.

Um, I would encourage everybody listening to this to go out. Um, the CD foundation allowed me to do a focus group, A-C-I-C-D cybersecurity focus group at the open source summit hour and a half. And we had people really, um, you know, voicing their opinions about where we should be with this.

And it didn't look good to me, honestly, it didn't look good. Um, ai, they're afraid of it. They're say, you know, it's, you can't trust it.

Um, MCP servers, no, no, no. We can't get, and think about it, if you are a, if you're, if you're pushing a job scheduler and you have everything built around a job scheduler, and there are, you know, several big C-C-I-C-D tools out there that are job schedulers, the last thing you wanna do is see an MCP server come along and take over that job scheduling. So there is, we have some big barriers in, in this area, and I'm, like I say, I hope that everything you guys are talking about is gonna come true someday, but we have a big cultural shift.

And it may take a while before the older DevOps people retire, and the newer ones who are willing to use new tools, start embracing it and change the way we think about DevOps and get rid of job scheduling. So I, those are, those are my thoughts. There was so much, so much in there.

I know you guys are like, oh, this, this, I, I, I wanna jump in real quick while that's top of mind. So one is, I, I, I don't think what you're saying is, is, uh, in conflict with this one, two things that really jumped at me. One is what do we mean by DevOps platform?

And you're right, the core of it, the, the definition of it is that, but I think they're growing to encompass more automation around the whole life cycle, not just the CI/CD. The other thing is, to your point, and I actually had this in my note earlier, Tracy, is that them embracing it, not so sure at the practitioner level, which I think is part of the problem that, you know, at, at least for us, we run into a lot of companies that are in a continuous state of m and a. You know, they're buying new, buying new, excuse me.

They bring in these teams who have their own tools. They like their own tools. They're cheese, right?

We we're great. Don't mess us up. How do I get them into the fold quickly, you know, without the whole house tear down by not changing, you know, what they're doing, but getting them into a more cohesive place where we can report and see these things.

So I think the definition is morphing what we're talking about and what people call their DevOps platform, as well as it's more of a top down thing than a bottom up. 'cause from the bottom up, nobody's gonna say we should all change tools so that we can be, you know, more cohesive. I think is is part of it.

I I, I agree with that, Kelly. I I was just gonna say, I wrote, I wrote down a note that what Tracy said extremely resonates at the individual practitioner level. I think the pressure's coming from the top of the business, the CIOs and the SVPs of engineering that are saying, Hey, I can't manage, you know, 90 individual snowflakes teams having their own different tooling.

Is there a way that we can come to a Kelly or a Ricky or a garima and consolidate those into something that's a bit more manageable at their level? I do agree that the individual practitioners are definitely saying, I, I want my own individual tools. Why do I have to use CircleCI as a integrated job scheduler when I'm already using Jenkins as my job scheduler here?

I feel that pressure every single day at the individual practitioner level. So from a DevOps perspective, I do think that you're right that there is a lot of maturity. I won't say maturity, maturity's not the word.

There's a journey that we need to go through to get them, get, get individual practitioners to that point, even if it's, even if that's the point that we want to get them to. I, I think there's something unsaid that needs to be said. I think the individual level, it's people who are afraid of losing their jobs, that they're gonna be made obsolete.

Because if all you are is a scheduler, hey, AI is pretty good at doing scheduling AI agents and stuff like that. And I think a large part at the Ricky, you're dead on. It's coming the top down push to go to platforms because it makes sense from a organizational point of view, from an individual point of view, part of losing that individuality and losing the ability to pick your own tools is the idea of becoming obsolete and losing your job too.

And don't, don't, you know, you can't short that Kareem, or, I'm sorry, go ahead. Yeah, I, I think, uh, I resonate to the points which Tracy and everybody else has been making on this conversation, but I think it's more or less, I'm coming from a community perspective. I think it's more or less to do with cognitive load on practitioners and think about this, why this load is increasing off lately is because there is shifting demand, right?

I mean, yesterday it was DevOps, today it's platform engineering. Tomorrow it will be AI native development. So there's a substantial amount of shift in demand.

And whether it comes from top down or bottoms up, probably somebody has to fix this problem. And also uncertainty, right? I mean, there is so many tools, applications which are coming in the ecosystem.

And as practitioners at, as a community, I think we have a lot of responsibility to share, uh, that, you know, it's, it's the shift, it's the pendulum. You know, we, we do decentralization and then we centralize and then we decentralize. Because that is the nature of innovation, right?

So I think some of these mature application tools have reached to that stage where we can go to a centralized state, which is platform engineering, which we can actually embedding into platform engineering mode and look it at us as a product, right? And then enable more features to it while mm-hmm. These practitioners are innovating, uh, you know, more tools, applications, and, uh, moving forward the ecosystem.

I, I have a comment and, and a question if that's okay. Um, so I guess to this point, the exception is if there's something in it for the practitioner, I mean, we have all lived in, in the world of you need to do this new process. It has no benefit to you, but it's gonna benefit someone else in the company, a higher up or whatever.

And it feels like a colossal waste of time to us, right? I think that if there is some benefit for the practitioner to change, then you may be able to get them on board. I'm curious from all of you, is do practitioners see that, you know, a savings of time or something they're doing manually?

I, I see that in the different subdisciplines, I guess across the lifecycle, but I'm curious if you're seeing the same. It's, it's the process of making a platform. If you are having a developer centric developer first view on this, definitely your product, uh, platform will shine because, you know, there will be applications and tools which, uh, you will see that nobody's using.

So that's a graveyard of features, right? So you can push it out of the platform, but I think it's the, the recipe is in how you make it, right? Uh, Tracy, sorry.

Uh, you wanted to say Something? Yeah. Uh, if you look at that for DevOps engineers, um, not platform engineers, let's just talk about DevOps engineers.

'cause they're the ones that we have to pull along in this process. The one thing that will get them to change and shift is if we start solving their, uh, problems that they can't solve themselves. One of those is what happened in my pipeline?

What happened? Why did my bill break? Why did be, why did the script stop ru stop running?

Who made a quick change that created this particular plugin not to work? Why did the deploy fail? Why did it only run in, in, you know, why did it only run in these environments, not others?

They don't have tho those kinds of insights because they don't gather that, they don't centralize the data. So if we can start centralizing the data and start providing them a feedback loop, then they'll be more interested in playing in the game because they are doing everything they can to keep those workflows running. And there are millions of them, I think that, uh, cloud-based claims that they do about 70 million, uh, they do run about 70 million workflows a month in their CloudBees, uh, their, their supported version.

So there's a lot of workflows being executed and to expect them to start changing immediately, as Kelly has pointed out, you can't remodel the whole kitchen. You gotta, you gotta pull the hairball apart very carefully. And until we can do that, the one thing that will get 'em there is more insights.

Insights make my job easier. I, there's another dynamic at play here too, though, guys, and, and it's similar to the real estate market, right? We, for a long time from COVID on, we were in sort of a seller's market.

There wasn't a lot of inventory and prices kept going up, and sellers can get what they want. Well, that's changed, especially down here in Florida where I live. It's strictly a buyer's market.

Now all of a sudden, everything's for sale. It's been on the market forever, and prices are coming down during COVI and during this huge, let's call it like a big bang sort of expansion that we saw around C and all of that, developers, DevOps engineers were at a high premium. They, you know, there were, there were 10 jobs for every one person, and salaries were off the hook, but people weren't even caring about salaries anymore.

They wanted the freedom to pick what tools they want to pick, what environment they worked in to pick who they worked with, right? And so it was a, it was a employee's market, it was an engineer's market. And so they got to pick the tools they want.

And many CIO CTOs, CPOs, higher UPS managers were only too happy to let these technical engineer folks pick their tool of choice, because they knew what tool they wanted. But when you scale, that now becomes, you know, as someone said, 90 different snowflakes. And so from an organizational point of view, you just can't, you can't exist like that.

And quite frankly, a lot of people lost their job, and now there's a little bit more, uh, employers have a little bit more leverage in hiring these engineers and saying, Hey, these are the tools we use here, like it, or lump it. And I think that's part of the whole dynamic as well. I, I, I, I, I agree with that to to, to some extent.

I, I think Tracy had a, a really interesting point there about the, the, all of the parts and pieces that are at the center of that, right? So some of it is definitely driven, Alan, by what you just described, which is the job market, the, the industry pressures and those things. But if I'm an existing DevOps engineer, and I've been working on CloudBees Jenkins, managed, um, you know, managed Jenkins for the past, you know, 15 years, and a platform engineer comes along and says, Hey, I'm going to transition you over to GitHub actions.

You won't have to worry about that job scheduler in CloudBees anymore. But now I'm gonna actually solve a unique problem around build telemetry and pipeline telemetry, because GitHub actions will provide you with the insights that you need from a build perspective, because we're using Gradle now. So you see when builds fail.

So, so, so now you've got that part and, and GitHub actions gonna view this nice dashboard around the last 80 bills that just ran and what failed and why it failed. I'm seeing a lot of DevOps, traditional DevOps engineers say, yeah, you know what? I'll learn that new tool because it's actually solving a problem that I'm experiencing day to day.

And now I can go focus on, you know, tinkering around with a bunch of AI stuff that, that I might be interested in within the CI/CD pipeline. I think it always goes back to whether, whether, whether I'm a platform engineer or an actual developer working on some sort of customer facing application, it always kind of goes back, goes back to what problem am I solving for someone in the space? And if I'm not solving a problem, the organizations that I've seen have the most problems with adopting and transitioning to platform engineering are just doing it at the top down directive.

They're not talking to developers, they're not talking to DevOps engineers, and they're just saying, we have to do this. We have to add this, you know, new bureaucracy in the form of platform engineering because the CIO Paul said we gotta do it. Um, those are the organizations that are least successful in those types of, uh, transformations or, you know, bringing in platform engineering.

The ones that are most successful, do what you mentioned, Tracy, which is, Hey, what are the problems that are out there? Do we even need to do this to solve these problems? Or can we just continue down this path of, of DevOps engineering and continue to provide value to folks?

And Ricky, there was a time when people were trying to implement DevOps, that developers fought it tooth and nail. I was one of those developers, I was One of those developers, Right? I was like, why do I care?

They didn't wanna change, they didn't wanna change. Don't care about security. Atos, I don't, I don't need to care about that.

I'm just here writing C code. Get outta here. But we have to keep in mind too that every different development, um, environment is gonna have a different stack.

This is why I have, I struggle with this idea of a unified platform because each dev, each type of develop, and, uh, people are developers are working in AI, are gonna have a whole different stack as a person that's building some backend program that they probably are writing in something really efficient, like c So the stacks, there are gonna be different development stacks that require different, um, plugins and different processes in the, in the life cycle, uh, across the entire, uh, platform engineering process from code degra to from, you know, code to cloud. We'll say, instead of from cradle to grave, like we used to say. Yeah.

Yeah. So I can get, sorry, go Ahead. Say we have, we have to consider that in this process.

We still have to be agile. If we're thinking about unifying and maybe just more, better dashboarding, better insights is the direction we can go. So developers can remain agile and do what they need to do to get the job done.

And one last thing, Alan, during COVID, when all those developers are picking their own tools and working their butts off and getting paid a lot of money, they onboarded, they, they changed the way that we do software in, in the world. In, in, they've, in the span of about three years, they were incredibly agile, they were incredibly efficient and maybe productive. They were very productive because they were choosing their own tools.

So maybe we need to, upper management needs to consider that productivity when they're making these decisions. Kelly, you were gonna say something? I was just gonna say, I think even though this topic is about, you know, to platform, or it's not to platform, I, I don't think it's binary.

I think it's how much are we 80% platform and then we, you know, tie into these bits and, and it's not just, um, that, but also over time, you know, we start with, you know, 10% platform and maybe over time it makes more sense to add more, but some pieces maybe never will make sense. Um, it, it depends on the organization and their, uh, trajectory, I Suppose. Agreed.

Agreed. Hey guys, I'd love to talk about this for the rest of the day, but I gotta pull the plug here. Um, what a great control alt, the plea deploy episode.

This was Kelly Reem or Tracy. Uh, Ricky, thank you so much for being here. We'll be back in about two weeks with another episode, but I think there's a lot to chew on coming outta this.

We didn't even get a chance to talk about AI native platforms and AI grafted platforms. Maybe we'll save it for the next show. But for now, this is Alan Shimel.

Many thanks to OpenText for, for, uh, sponsoring Control Alt Deploy. We hope you enjoy this, and we'll talk to you soon.