Techstrong Gang – February 10, 2025

Hey, everyone got those post Super Bowl blues. We've got The Cure for What a's you you're watching Text Drunk Gang. Hi everyone, it's Alan Shimo.

Happy Monday to you all. It's Textron Gang Post Super Bowl edition. Uh, we've got some, we've got some good stuff out from the webs that we're gonna talk about today.

Let me introduce you to who's talking about it. Um, our gang for today, we have, well, we have some regulars, but, uh, joining us, I think she looks like she's home out there in New Mexico. She's the CEO of Deploy hub and involved in CDF and OSSF and a bunch of other good open source stuff.

It's our own. Tracy Reagan. Hey Tracy.

It's good to see you. Good to see you too. Alan.

Great to be here. Thank you. Moving from New Mexico down well, to the west of Texas, down to the east side of Texas, down Houston way.

He is a FU analyst, CTO at Visible Impact Guy Courier. Hey Guy. Good to see you, man.

Hey, Don't say Houston doing Austin night. Austin, Texas, central Texas. Did I say Houston?

Not East Texas? Yes, you did. Well, that's right.

Love used. Love my Houston people. But I happen to live in, uh, the great city of Boston, Texas, central Texas.

Well, I where we get warm Weather year round, whether we want it or not. Same here. I apologized to all my friends in Austin there.

I had a momentary lapse, I think it was too much Super Bowl stuff. Um, I was thinking you should ap you should apologize to the city of Houston, but what do I know? Yeah, well, it had something to do with the guacamole though, I'm sure.

Um, anyway, guy, wherever you're from and r welcome, um, Good to be here. All right. And we'll move up from Houston to Austin to Colorado, our man in the Rocky Mountains.

Mitch Ashley. Hey Mitch. How are you, man?

Good. Doing Good. Happy Monday, everybody.

Happy platform engineering day. I think we're gonna be talking about that. Yeah.

Great topic. Cool. Mitch, you're still in Colorado, right?

I am, yes, I am. I haven't moved, moved, and I'm not traveling. He moved.

Alright, good for you. Well, and then we'll round it out with the, uh, the, uh, man in Harrison, our Chief Content Officer, Mike Ard. Hey, Mike.

How are you? I'm well. You know, I can't figure out which President Harrison is actually named after, but I'm gonna look that up.

Well, it could, I don't What makes you think it's named after a president? Good question. I don't know, but I've been here long enough.

I should figure it Out. Yeah. Well, what are the, if it was a president, we've got William Henry Harrison, he's probably the oldest, right?

Mm-hmm. Then there was another Harrison Post Civil War with the long beard, right? That was William Harrison, wasn't it?

William Henry Harrison. Yeah. No, there was William Henry Harrison, I think is earlier.

I think, I think one of them caught a cold and died. That's What I think. Right?

One of them died pretty quickly. Yeah. Got a cold and died.

But that would be an interesting reason to name a town after someone. There you go, man. All right, well look, report back to us on that, Mike.

Yeah, I will. I'd ask an AI Get agent. A ai AI agents conference.

All right. Well, guys, before we jump into our first block, you know, for those at home, we don't do these live If you haven't figured out, we usually record the day before. But being that this is a Monday show, we record it on Friday, well, we, so we've got what they call a weekend in the middle.

And this weekend, as I mentioned earlier, is the Super Bowl. The Kansas City Chiefs are playing the Philadelphia Eagles. So I, so I thought I would do a little experiment taking advantage of the time warp here.

I'm gonna ask each of you to make your prediction for the Super Bowl score and winner today here on the show. People will see it Monday and real, and we'll see who was the closest and who was it. Right?

It's kinda like back to the future, you get to play Biff. Um, so Mike, I'm gonna ask you to lead off, what do you, what do you, what's your prediction for the Super Bowl? All right.

Realizing that I probably am not a fan of either one of these teams, but I'm going to, uh, go with the Eagles 27 21 over the cheaps Tight game, low score, relatively low scoring. I think the over is higher than that, but, okay. Mitch, how about you?

I thought you were gonna record this as, uh, two different endings to the movie, like, which, which team won, and then we can Well, no, I'm, I'm just doing that for mine, so I I, okay. You know, I, I come out Right, but go ahead. Well, You know, in, in, in a typically tight score, 13 to 14 weird score, you know, um, it, it came down to the, to the, uh, Kansas City.

It was maho at that last second to, to get that touchdown over the line. And, you know, the, uh, the Eagles weren't able to stop 'em given their great defense. It was, it was a pretty amazing game.

So it's 1413, you score pick. Yep. Mm-hmm.

Ooh, I love it. Tracy, how about you? Well, it doesn't involve a hockey stick, so I don't know anything about it, but I can tell you what chat GT says.

Okay, well that's as good as Annie. Yeah, exactly. 5.

So, there you go. Go. That's my prediction.

Go workings pretty close. So, Kansas City by a point and a half, I could guarantee you it won't be by a point and a half. 'cause Yeah, that was a weird points, you know, half points.

I was, I was taking candy from a baby, You know, but, but, but, but now you put this whole idea of chat GPT as a bookie in my head, and that's a whole other thing. Oh, it has the spread as well. So if you wanna know that, let me look back again.

It says, uh, a money line of minus one 20. Okay. Very cool.

I'm not a, I don't, I'm not enough of a gambler to know what that means. I'm sorry. I Don't either.

I don't know that one. Okay. How about you?

Uh, I think the Chiefs by 9 35 to 26 with one defensive score by the chiefs, A take away and defensive score by The Chiefs. So That, that sounds interesting. So I'm gonna go with my heart rather than my head, which is probably not a good move when you're betting, but I'm gonna pick the Philadelphia Eagles in a shootout, 42 to 36 a shootout, and there'll be some defensive touchdowns too here on both sides.

You know, there's gonna be turnovers. I think there's gonna be a high powered game, though. Both teams have a good defense.

Anyway, you're watching this on Monday, who, look, maybe we hit it, maybe we don't. But Mike, let's move on to our first story for today. Why don't you, uh, take the reins?

Yeah. com. We invite you to go over there and check that out.

'cause there's a lot of awesome, great content starting to show up over there. And it's a hot topics these days. It's a lot of debate about exactly what it is.

And, um, there's, now the CNCF has a set of certifications that you can get to become a platform engineer. And everybody's kind of trying to figure out, well, what does it mean to be a platform engineer versus, say, a DevOps engineer? Mitch, I know you're following this space.

You did some survey work on this last year, but what is your sense of what is the difference here in, because is platform engineering something a DevOps engineer does, or is it an actual different job with a different title and a different role? Well, I think you, first of all, you have to take the certification to find out. That'll answer your question.

Uh, at least according to the CNC. No, it, it's interesting, you know, platform engineering really kind of accelerated its emergence, uh, during the, the post covid, let's focus on developer productivity. We need to get more out, more for less, you know, with our developer community.

Um, 'cause finances are getting tight and things like that. And, and, you know, some folks, it's, we've been doing this all along. This has been, it's this admin work, or we called it ops something or whatever.

That's true of a lot of things, right? We do many of those things and then we kind of package 'em together. I think the difference is we're playing d different kinds of disciplines to some of those tasks.

And what has emerged to be is, first of all, making sure, in particular developers, but also testers and others have readily real, readily, readily access to tools that they use and somewhat standardization on those, and also support of those tool environments. It, it's more than just, you know, hanging up a bunch of spurs on the, on the wall and say, you know, pick your poison. Go, go ride one of those Broncos.

It's no, it's, it's like, here, this is what, where you develop code and here's the id, you can choose your id, but here's the plugins to use. Here's the, uh, you know, repository, et cetera. But it's more than that.

It's also trying to create standardized configurations, maybe more secure configurations, supporting of those things. It could be for a platforms for development, for testing, for different production environments. Lot of organizations run, especially if you're a SaaS company, may run different versions of the same app right.

In for different customers at different times. So it, it's the other area where it's really grown into is also also blending and kinda merging with DevOps. A lot of platform engineering teams support all the DevOps tools too.

Why separate those? It doesn't always mean it has to be that way, but it's certainly kind of easy migration to move that way. Um, I, I wanted to highlight too, Alan has started a new podcast, the DevOps platform engineering podcast with Luca, and I'm sure you'll talk about that, where they talked about, you know, the old adage of his DevOps dead and platform engineering is taking over.

There may be a few stalwarts that are holding onto that adage, but I think most of us know that's not true. It's really accelerating how we do DevOps and scaling it. I've got some, so, Mitch, thanks to the plug the show is called the Platform Engineering Show, right?

Plain and simple. There's an interesting move here on C'S part though, right? They, in addition to rolling out their certification, they're also, I think it's only the first or second time in Q Con London coming up, where on Monday zero day, they're actually having a platform engineering conference, you know, as one of the conferences that they do, usually on Monday you get, like all of the projects get to do their show.

Some of the daughter foundations do a, a, a gig, and then some subjects. In the past, it's been, uh, security Cloud, native Security, and OSSF started this year. They're doing a platform engineering one.

And from what I, uh, gathered, uh, Chris Ek, the CTO of, uh, cloud, CNCF said that it's, it's, it's like they're one of their most popular electives for that Monday zero day, uh, of, you know, lineup. Actually, it might be Tuesday, zero day, it's Tu no, it, it's Monday, then Tuesday. No, it's Tuesday.

I apologize. It is Tuesday. Then Wednesday, Thursday, Friday is the actual expo.

Tuesday, zero day, not Monday, Monday, zero day in RSA. But the point I was trying to make, what was the point I was trying to make, the point I was trying to make is my friend Luca, that Mitchell references Luca Galante. org.

They're the people who put on Platform Con for the last couple years, and it's probably the single biggest platform engineering conference. It's virtual. Oh, this year it'll be hybrid, uh, in the world.

They get 25, 30,000 people registered for that thing. Um, they've got about two to a hundred to 300,000 people on their community chat. And, you know, all of that.

They have all kinds of working groups and, and reference architectures and everything else. One of the things they have is the training certification course and platform engineering. org certification or course the right one for you?

Do you want to get both of them? Interesting? Usually these break off into the commercial versus non-commercial, the vendor versus the org kind of thing.

But here you both, you've got two not-for-profits, two, you know, communities with dueling orgs for what is, according to Mike and Mitch, maybe not as well as it defined a, uh, not as defined as some of the others. So, you know, I don't know. I mean, CNCF kind of has a bit of a minus touch right from there.

Yeah. Don't these things tend to run on vibes, though? Like, you guys have been paying attention this far longer than I have.

I, I feel like, you know, could be, you know, a movement, whether it's an anti CNCF movement or just a pro platform engineering movement because of whatever, like the purpose. There's a, there's a good, helpful purpose in this education certification. It's a way of someone saying, I I I I've studied, I know, right?

But the reason they're doing it is to get a job, to get a promotion, what have you. And the reason they're accepted is so that people hiring you can have confidence. And that can come from multiple organizations, is just by vibes.

I mean, there seems to be some sentiment that comes out of the soup of culture and community and all that stuff. And one becomes the one and another one disappears or becomes the other one. Uh, it's, it's as random as that.

No. That neither of these organizations are gonna do a poor job of training and certifying. org, I mean, certainly today has a much larger community of platform engineers anyway than perhaps CNCF does.

That's one of the things I was thinking, Alan, too. org community is a very fervent, passionate, engaged community and kind of kinda like early DevOps days, but maybe even more so, just a really strong vibe. Yeah, no, they've done a good job of, of organizing Luca and yeah.

And the team there. It May propel it to be the leading certification. Maybe it'll be unique and different that way.

Maybe enterprises will look more to CNCF. Who knows what'll Happen. You know, I, I think the platform engineering certification though is more, you know, more of the unconference unconventional, you know, you may be able to just take the test and not get the certification, but I took the test kind of thing.

'cause you know, there's a, some people revolt with the idea of, of having a certification, you know, too structured down with demand. A lot of them will say that the test is just people who are good at taking the test, pass the test. It's a DEI thing.

It's a DEI thing. So I, that's where my head goes immediately when I think certifications. I was like, you know, I want someone who's gotten their hands dirty and done this.

And even if it's in their own environment, they stood up a raspberry pie and they've been installing things and figuring out how to configure it and understanding how to start automating some of the configurations. So, um, it doesn't, you know, it gets certified. It's a really good thing to do, especially if this is an area that you've not been in before.

But we've had operations people and production control people for forever, right? They've been there forever. So why is platform engineering a discussion now?

Well, I'm glad it is because we have far more complex production environments or any environment test development environments than we ever did before. If you think about a, uh, a monolithic application being deployed to a Windows server, for example, pretty, actually, it's pretty straightforward and simple. And you can have a, uh, a either an SRE managing that, uh, you can have a production control person or a, a network engineer even managing that.

But when you start thinking about the complexity that we're going to see that we already see in just a Kubernetes environment, and then add AI to it with hundreds of AI agents that have to be configured with traffic going to all of them, that has to be looked at and managed on a regular basis. We are in a new world when it, when it comes to production control and, and what we're calling platform engineering. And it's good that we're, if, if it's true what Mitch has pointed out, that we may have DevOps and platform engineering in the same department, or at least working close together, I would love to see that because these platforms are built on a lot of scripts, and that's where we shoot ourselves in the foot or the face sometimes can be even more dangerous, right?

Because scripts are obfuscated, they're hard to go look through. And if we start doing more things in a templated way when it comes to platform engineering, we think of things like Terraform and, um, you know, open tofu. These products that are, are trying to help us through the process of templating and understanding and being able to repeat the creation of these environments, the better we'll get and the more prepared we will be for these broad AI environments, and it'll give us a better opportunity if we choose to, to move off of A-A-A-W-S environment and into our own.

So it's a, it's, it's the, the time is right, the conversation is correct, and go get certified. Uh, because if you haven't done this before, we'll have more jobs in it. And, you know, the Tels team, this has been such a discussion for them.

Um, one of our, uh, committers did eight, a series of eight blogs just to teach how to use all of these different tools. And there there's a lot, there's a lot to learn in it to get your hands. I'm so glad you used the, uh, you mentioned the SRE because I, I, I felt like, um, SRE had its moment and SRE were mountains striding, you know, uh, uh, infrastructure gods and goddesses who, uh, went around saying, you know, like, we, we are going to make your environment secure, solid and reliable, and all that stuff.

So you keep doing all your fun DevOps stuff. And I, I, I was a little confused by it mostly 'cause of the name. And my impression was that the idea of platform engineering as it, as a discipline arose helpfully out of site site reliability engineering, because it reached up into what really matters, which is the application, its functionality, and what people are trying to do with it and with data.

And, uh, uh, uh, uh, Ronnie Engar, uh, from Cloud Foundry, uh, uh, posted a really nice perspective about how the phrase platform engineering seems like marketing, but engineering a platform definitely is not. And I feel like it gi that name and that phrase marketing or not, gives us a really good focus on what, what is needed in this, as you say, increasingly complex, interconnected, uh, multi requirement host a requirement world for any application, which is somebody who is going to be not, not ensuring the reliability and functioning of an infrastructure, but someone who is engineering a platform to serve the business interest. So I disagree, it's guy, they do have to do, they, that platform has to be reliable.

Sure. But that's, that becomes that, you know, it, it almost subsumes the SRE function within the platform Engineering SREs. So look, these are all interrelated under this bigger umbrella that I call DevOps, but I've had a chance as part of doing this platform engineering show and talking to the platform engineering or people and some of the community there.

It's not as nebulous as you think it is, and it's not necessarily just ops by another name and, and stuff like that. And it's not meant to replace DevOps in spite of what they said from a marketing perspective. Here's the deal as far as they see DevOps is great, right?

The, the whole kumbaya, the whole cultural, the whole idea of breaking down silos, working together, when you get to large scale, it's hard to organize that chaos. And increasingly with DevOps, there was the shift left shift, left, shifted, it left, shifted further left, not left enough, shifted more left, where all of a sudden the mantra became where the developers building his own platform that he develops on. And that's, that's when, that's when the, the stuff hit the fan.

The developer shouldn't be tasked with building the platform they develop on. And wouldn't it be better if someone who is supposed to, who's certified, who is trained, who is experienced building a platform with the guardrails that allows the developer that then just develop, he doesn't have to build this platform or her platform. They develop their code, their apps, and they go faster.

So I'm just not sure where we're disagreeing, Alex, because I agree With all That. I, I would argue to a certain degree you would get a lot of folks who would say that's exactly how it used to be back in the day. And then the developer guys rebelled and said, we're gonna go out and build our own tools and platforms because you guys are too slow.

And now it feels like we're coming full circle. So people are standing there. It isn't got the way of the world.

It's always been, yeah, That started around 1970 with the PD P 11, I guess. Yeah, We've always done That circle of life. It's the circle of life Circle of, but there's a part of it, there's a part of this discussion about who's accountable.

So for most of you out there listening, I'm sure you will know and, and experience this, is that if there is a production problem, who gets called to look at it and fix it, the application team, even though they don't have access to production, they have somebody else who might be sitting there with them trying to sort out the problem. So we created a site reliability engineer who could have more control, but they were assigned to a team. But as Alan points out, they were also trying getting, having them do the hard work of actually building out the, the, the platform.

So these, there is a, there is something that we used to talk about called separation of duties, right? So we've constantly tried to, to achieve that separation of duties by having an SRE who might have production access. And he's the person sitting on that team working with them.

Yep. That person should still be there. Yep.

But there should be another team that is managing the platform itself. These are very different discussions. I I agree.

The platform is different than the application that they're managing. So we need the platform engineers to start standardizing and, and, and stabilizing these, these environments in order for us to move forward. We can't move forward without having that.

There's another thing happening here too, Alan, is I just wanna note that, yeah, I obviously talked to a lot of vendor technology companies in my role and, you know, as, as does Guy and more and more sort of platform engineering advocate is the new dev rail. It is the, it is the focus of companies because things come together at platform engineering where it's developer tools, it's, uh, Kubernetes running and production are running the underneath the tool chain security is starting to kind of connect there as well. I'm not saying it's the center for all activity, but is a connection point now.

And we kinda lacked that before when developers are creating platforms and doing all the supposedly operations themselves, but not, and so it's, it's, the market has responded to, I think, what's happening in, in the, uh, you know, development community. Just as an example, the latest one I was at, uh, Dynatrace, uh, last week. Dynatrace performing, you remember.

And Andreas Grabner, our friend at the CNCF, he's a Dynatrace, he's now, you know, uh, uh, advocate for, uh, platform engineering. He gave a whole talk about it. And that's clear as I talked to different people at the conference Much, wasn't it Mitch wasn't Andreas, CEO.

He was state New and then he, I can't remember where he was Before. Well, I didn't know. New out of the Netherlands.

Yeah. With some of our, uh, uh, the Cloud D marketing, some of the folks from there moved over there and, Uh, oh, state by the, um, who else was a, um, someone else was there that I saw. Anyway, there were some old friends that we have, um, good folks that we have on different, different, uh, uh, on different, uh, things.

Anyway, the the point was, you know, it was a whole main stage conversation. We're talking about platform engineering and they're all, It is main stage. Guys, we gotta move on to our next topic.

I'm gonna take the prerogative here to have the last word. You know what, all these people you're talking about work in the software factory, right? Kind of father knows best Dad went off to work in the factory, and they all work in the factory and there's a job there for all of 'em.

And it takes, it takes the village to build our software and run it today. So we have SREs and platform engineers and DevOps teams and developers and testers and all the, all of the things we need to make software what it is until AI comes along. And I'm only kidding, I don't know what AI's gonna do.

We're gonna take a break. We'll be back in a minute. Discover Techron group, the epicenter of tech innovation.

We are your go-to for reaching IT, leaders and practitioners worldwide. Our secret impactful content that sparks awareness, engagement, and top quality leads with us. You'll access editorial websites, streaming videos, virtual events, custom content analyst research, and more.

Join our satisfied clients. Let's revolutionize your tech journey. Contact us today and tell your story to the world in the most powerful way with Textron Group.

Hey folks, we're back and we're gonna continue this conversation a little bit with a little more focus on DevOps specifically. 'cause there's a lot of debate out there now about, well, does DevOps scale? Is it broken?

Other folks say, Hey, you know, look at all the great software we're putting out there because of DevOps. So maybe two things can be true at the same time, even though they're at polar opposites. com, done by Port Inc.

They are a provider of a internal developer platform. So they definitely have a stake in this conversation, and they only talk to, you know, very high end teams, but they found out that, well, developers are wasting a lot of time and more troubling still, it suggested that half of them don't trust the data that's actually in the DevOps platforms and tools. And that kind of stuck out with me as like, well, if I'm not trusting those tools, then what am I doing?

Just calling up people and asking them where things are doesn't sound very efficient to me. But Tracy, I know you've talked about this in the past where DevOps is broken, but the question I think is how broken, where is it broken and what, what can we do to make it better? Well, I wouldn't say DevOps is broken, um, but I would say that DevOps needs a bit of a tuneup.

Um, but going back to that survey, I read, read through that survey, and sometimes things don't feel right to me. And it may be, but one thing in there said that an average number of tools was seven. And I'm thinking seven.

Just seven tools, 700. Is that All? I think it's missing two digits.

I at least one digit. Right? At least one digit.

I mean, I probably can come up with seven tools right now just thinking about what you know, are in common. DevOps pipelines takes seven Tools to manage the seven Z or 700. Yes.

Right, right. So that maybe it's, Maybe it's seven approved tools and the rest are whatever I can find. Well, there are, we, there are so many.

And that's the whole point of a DevOps pipeline so that you can manage the tooling. Now, I know there's been to, there's been, um, similar tools that Port does, like task talk. And I do know that there is, uh, you know, having a layer that helps make this stuff easier is important, but I still don't feel like having seven tools is a problem.

So I had to question the, I it made me question the, the, the, the J Industry just still want the whole thing. Yeah, I, but I'm Sorry. Again, case DevOps.

DevOps does need to ha need, we're at a point that DevOps needs two things. We need to add security tooling to it, and we need to start adding what we need to do for, uh, testing, you know, LLMs and ML ops. So while I, uh, you know, questioned the survey, I, I wanna point out that we do have a lot more tooling that we need to add to the DevOps pipeline.

And seven is probably a li a very small number. And if you only have seven tools, you may not even need a DevOps pipeline. Yeah, I I, but I felt Tracy, like, it was like, it was like, um, bad data supporting a good point or something like that.

I don't wanna call it bad data. No, it was a Self, I dunno how they conducted this Prophecy. So, yeah, fair enough.

But the point is like, you know, I, I think the contention that developers, um, to, and, and specifically this is seven tools to build whatever build means. It doesn't mean to deploy or to, or any of that sort of thing, like necessarily. Um, but, uh, the, the general idea that, uh, there are a lot of multiplying tools, or let's say use the word platforms again, the developers are navigating on average, um, instead of having something that's a little more integrated and seamless, if you like, um, that is kind of an issue.

There's a lot of BYO there's a lot of stuff that's going on and I, I, I, the survey attempted to validate it in a poor way, but I think it's a real issue. I do too. A hundred percent Chase, I don't disagree with you and I and Guy, I don't disagree with you either, but, but lemme, that's, that's a set straight.

I just agree with that straight. Hang on. I gotta write in my diary real quick.

Alright, Lemme, let me just get this straight. A software vendor who makes an internal developer portal puts out a survey that says, developers say, the problem is they've got too many tools, they could use a portal to help manage it because they don't believe the data. They're in metrics, in the tools and platforms they're using.

They wish they had a portal to use. And what do I sell? A portal?

Come on, you wanna talk about self-serving much? We, we, I think we already established that point. The point is, Well, I just wanna make sure we, we hit it with a big fat sledgehammer.

The, The point is, the point is, in fact, we wouldn't be talking about platform engineering if everything was hunky dory in the land of DevOps. So things are not, Well, that's okay. It doesn't have to be hunky dory.

Life isn't that way. It's not all unicorns crapping rainbows. That's not what the way the world works.

There's gonna be issues, there's gonna be problems. We keep working at it. We, we constantly improve continuous improvement, right?

Iterate, reiterate. Now that being said, here's where I do think you have problems in the DevOps tool chain. As you get to the enterprise level and you're at enterprise level DevOps, it is a very rare burden deed where you have a standardized tool set, whether it's seven or seven, you don't have standardization of tool sets in your DevOps tool chain because this team chooses to use Jenkins.

This team might be doing GitLab, that team's doing harness uh, testing. I'm doing t tricentis, I do sauce, I do pure open. I, I'm, I'm running coop here, I'm running VMware there.

It's the enterprise. We don't have standardization of our tool sets. Well, Alan, just, just keep in mind the punchline here, which is supposedly 15 hours of lost productivity per developer per week.

But if they use a portal that gets cut by 90%, Well, yeah, sure, but that, that's the, that's the who cares part of it. Because, you know, part one part is the, it's a culture of, you know, innovation, freedom, trying things out, break fast, all others, or you do wanna enable that. So is it really 15 hours of wasted, wasted based on what, you know, like what's the Point?

I I don't think it's 15 hours wasted, but here's the point in my mind, there's this eternal combat between let's get efficient, let's slim down. I want one throat to choke. I want less tools.

We got too much, too many different software here, too many different security tools, too many different DevOps tools. We've gotta, it's, it's, it's, it's wasteful. It's inefficient.

We've gotta standardize, we've gotta standardize until I buy the next company. And they have their own way and they dig their heels in that they're not going to, you know, this is what they use to go change. Something's gonna be a major to do it.

It's the way DevOps evolved, right? DevOps very rarely came from the top down enterprise wise. My theory always was we, DevOps came in bubbles.

And you know, like when you're a kid playing in the bath with bubbles, as bubbles come together, they make bigger bubbles, and then they get bigger bubbles and then they pop. And that's how DevOps evolved. And that's how DevOps rolls out at enterprises.

They're, they're these bubbles of teams that use their own recipe. And they, and I think sometimes the, the mistake that we make is thinking about DevOps as tooling. When if we really built a DevOps, uh, framework, it wouldn't be based on the name of the tool.

It would be based on the, what we're trying to achieve at each state in the process. So a compliance scorecard, for example, so that every team can build their own DevOps pipeline because one's doing Java, one's doing Python, somebody else is doing rest. Because these environments are very, very different.

The compilers are different, the tools are different, but you can still define your compliance levels that you need to achieve. And we will end up with lots of tools. It's just going to happen.

And there's probably another 10 tools that we're missing in the pipeline just to add for security from repost scanning and signing to gathering, uh, data to doing vulnerability management on the out on post deploy. There's a lot of work we still have to do, but every single environment's gonna be a little bit different. Even an SBO different.

Lemme share. Just, just look the data with you just to give some perspective. 'cause I'm wrapping up a new survey that'll be out probably in about three weeks.

But we, we asked organizations, where are you on the maturity curve, both for DevOps and for platform engineering? And interesting, they're almost exactly the same in terms of the phases. The, the way I've always characterized it as other than, you know, once you're past the getting started phase, you go into kind of operationalizing how are you using it?

And different teams are doing different things and learnings, and then you enter this standardization phase where you start to boil it together, right? Especially in the larger organizations. Eventually you get to what you might consider your own level of mastery.

And both for platform engineering and for DevOps, they're both right about 44, 40 5% in that standardizing phase. This is at the same point in time. At the same time.

They both say they're about 25 to 26% in the mastering phase. So they're really in sync. And I think that's not by accident.

Um, you know, these are talking to the same organizations. So I think they're moving together and, and fortunately I think that Al also says that DevOps isn't staying stagnant, whether it's platform engineering kind of bringing it up, modernizing it, or they're both just heading in parallel and their kind of paths and working together, whatever the per whatever the reason, I think it's a good outcome. But that's what the data says.

All right, I'm launching a new, I'm launching a new platform engineering, um, platform. I'm gonna call it Mr. Bubbles.

Okay. You like that? Swear someone already had that name.

I just wanna know, uh, I, I don't want, I don't wanna know the source of those bubbles, Alan, but that's A whole nother thing. Well, you never, you never played with Mr. Bubbles when you were a kid.

You didn't have Mr. Bubbles. Yeah.

And, but I know that's not the only place that those bubbles come from. It Was like a little purple box with all the bubbles. He had eyes like googly eyes and your mom would pour the powder in.

It would make all those bubbles. As long as they're purple Blood. I'm so sorry For you.

If you didn't have a, a night with Mr, There's some things we just didn't have out there in the cornfields where I grew up, you know? Oh heavens, the cornfields. I didn't grow up in Corn.

Meanwhile, I'm thinking of Scrubbing bubbles Mr. Whole time. Tell the truth, guy, you didn't have Mr.

Bubbles. Oh, I had Mr. Bubbles.

Yeah. Come on, Mike. You had bubble Mr.

Bubbles. Of course, We had, I also had scrubbing Bubbles Afterwards, used the name. So of course we had, yeah.

Oh, that's all we got. Uh, what can I tell you? All right, let's take a, Explain a lot of thing about Nebraska.

There you go. Yes, that does. Poor guy never had Mr.

Bubbles. Imagine that. No wonder why you would make your jokes about other bubbles.

Necessity's the mother of invention out there. Just, just saying. Just saying.

Okay, we're gonna take a break. This is degrading quick. We better.

Let's get it together. We'll come back for, uh, part three of our episode today. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry.

com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more. com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more.

com. Home of security bloggers network. All right folks, and we're back with more IT issues.

And this time we're talking about the eternal quest for the unified IT platform. And you gotta wonder if this is a unicorn or not, but JumpCloud has a annual survey out talking about how this is what folks really want. I'm just not entirely clear it's gonna ever be possible.

Guy, you've been following this a long time. Now we have more tools and platforms across all. It, it's not just DevOps or platform engineering.

Is that just the way it's gonna be? Or can it one day get rationalized into some Uber platform? Uh, without mentioning ai, no.

Maybe with mentioning ai, no. I think, uh, how many times have you heard the pitch for the so-called single pane of glass thousand times, 2000 times? I think that, um, back in the day, uh, I led most of my Forrester research.

There was a really helpful ship to thinking instead of a single pane of glass, the preferred workspace. And thanks to the cloud and the rise of the API economy and all that other sort of stuff, we do have real possibilities there. So let's back up a step on, I, I read the story and, uh, the, the specifically it was for device, uh, and role, um, management, um, some and identity management that there was a desire for a single tool, unified tool.

But it does bring to mind the perpetual 'cause I be, there are other service methods. In fact, I just conducted one myself. Um, where there's a strong desire for unified, uh, management.

Let's say if forget a tool per second or painted glass or portal unified management of let's say ser uh, service health or, uh, infrastructure health or whatever it is. Here's what's working against it. Two things really.

The first one is, uh, it itself is not unified, particularly they're security experts and networking experts close to each other, but have different agendas and need their preferred tools to help or their preferred single platforms. Um, there's, you know, identity management device management, which are related to security. They're all related to each other.

Um, but even in a small shop, uh, there will be, for example, vendors and consultants who are helping to manage certain elements of it that whoever you happen to have in your IT shop can't do or shouldn't do, or you don't want, you don't wanna hire to do. So you're having multiple roles here. And even a lot of these, you know, really comprehensive, uh, it service management platforms like ServiceNow or BMC and so on and so forth, um, they, they, they struggle to unify operations for the simple reason that as, as this is the second part, which is that as, uh, the nature of infrastructure and application delivery and so forth evolves, um, there are new specialty tools that come up because the big unifying tools can't do everything everywhere.

So the API economy helps put all these together, but I think the idea of, um, unifying is the unicorn and maybe a, a helpful nor north star for everybody to think about, um, how to, uh, manage their entire estate and their whole landscape. Um, you know, how to put things together so that people, individuals and talents that they have on staff as well as developers, as well as business users to a certain degree, can all have their way of doing their jobs that still somehow interacts together with each other. But that is complexity and it will be a perpetual struggle in every operations team to, um, make things easier for the users, easier for them.

AI does show real promise in this area because it can do analytics including predictive analytics on very large data sets. So a large state doesn't really phase it particularly, and it helps concentrate the human operators on the areas that the most interest and concern, whether it's, you know, uh, device management and security or, or, or system health or any of those other sort of things. But in the end, unless we go down the rapid, uh, sat Nadella told us that we're just gonna have our AI buddies and, uh, we're not even gonna be using portals anymore, which is a, not even a unicorn, a mirage.

Uh, no, we're, we're, we're, we're not gonna get there. Well, I, I just, if you aren't aware that February 28th this month is, uh, when we have the Great Planet Parade, and that's when we'll have a unified platform. It's when we have Neptune and, and, uh, Pluto I guess, and all the other planets line up.

Pluto's not a planet Mitch. It is, it's still a planet, dammit. And in Nebraska, it's, I guess where they don't have MR Bubbles.

But either that, either that or it won't matter anyway, because in, in 2032 in Asteroids can hit Earth and even if we had the platform, we won't be here to enjoy it. But no, actually I did find there is one platform to rule them all. It's Called Precious.

Oh, okay. The one ring is, uh, yes, is not, is not here. It's the one platform, One of the ring.

This is the pendulum conversation, right? We need one platform, we need more tools. Oh, I'm hypnotized, hypnotized.

I don't think it's a pendulum. Uh, Mitch, I think that this desire, it has been perpetual. You ask people, you've talked to customers probably more than I do.

Um, I talked to a fair number of IT ops folks and they all want it. But then when you dig in a little bit and find out what the one platform is they want, it's actually the one platform that covers this part of the, the infrastructure is it from and all this other sort of Stuff. Is it from Microsoft or is it from Azure?

Okay, let's let's decide that first. I don't dunno if it's one platform they're looking for. I think what they really want is a single place to go to find out what tools they can use, right?

Because there's more than, you know, a handful as this survey indicates. And we did, we've done that. We've had c MDBs in the past where you could say, Hey, I'm gonna go stand up my environment.

I'm gonna download this version of Oracle. Or tools like, uh, that, you know, made an effort to pull together. This is where you can go find these on these different, um, repos.

And I, I feel like that's really what they were talking about more than having a single platform one ring to rule them all. And I understand that. I understand that desire, but we've done it.

And I don't, I don't, I don't think anybody's gonna spend money on it internally. I don't, Let me see if I could bring some order to the chaos here. I think you were gonna say something else, but go ahead.

No, no. So cut through the, anyway, yeah, let me cut through to the, to the, to the heart of this. First of all, shout out to JumpCloud for doing this, right?

For those who don't know, JumpCloud is founded and CEO by my good friend, Rajet Bava. Raj Mitchell and I co-founded Still Secure 25 plus years ago. I've been involved in Junk Cloud on a personal level since the day they started it.

And know a lot about who they are, what they are, and what they do. And I'll shout out to Greg Keller too, their chief strategy officer, another friend there who's does great work. So hi to Greg and Raja, if they're watching JumpCloud wants to have a directory that rules them all, right?

They, they think ad active directory, it doesn't work in the cloud era. It doesn't work with Max so well, it doesn't work with cloud resources, it doesn't work with iot, with machine, you know, AD has has had its day and they want a cloud directory. It's a directory to rule them all.

And why having that directory is, is not just identity based so that when you log on, I know it's Mike or Guy or, or Chay or Mitch, but it also makes it very easy then to give you access to my tools to, to your tools that are pre-approved on the corporate land, right? 4 tools we spoke about on the last segment. And you, you know, I don't want to use the word single sign on, but single sign on, right?

And so does that sound appealing that no matter what device you're on, where you are, I could sign on and automatically get access to my tool sets and files and everything I want. Yeah. Surprise, 85% of people want that.

Shocking. Mm-hmm. Shocking.

Well, I think the issue comes more towards, you know, and I remember having this conversation last year with uh, CIO in, in New York who was particularly colorful about it. And he was saying, you know, the problem with every time I get a new frigging tool is I gotta go hire somebody else to go manage that tool. And then everything in the costs all go up.

So he's like, you come to me with a new tool. He says, forget about it. I don't wanna hear about no more new tools.

Was he a CIO? Is he a construction guy? He's a, he's a, he's A, he's a, he's a Hardcore drop them over here.

He's a hardcore New Yorker who was not having it anymore. And he was saying, you know, I, I have these platforms and if I need something, I'm gonna beat them up to give it to me as a feature. But I am not adding any more new tools.

He was Adding this guy's in your tools, you guys, guys, Tools, tools. I think we're talking about two different things though. 'cause one that you're talking about, Alan, and I think you've touched upon as well, Tracy, is is features, capabilities, uh, uh, them being cross platform integrated, that sort of thing.

My lens on this is RA really the, the operations standpoint. I think the desire, I know the desire for single tools or unified tools comes from a craving for visibility and abil and an ability to be proactive. Because what none of these folks want CIO VP of, uh, ops or infrastructure, um, application managers, uh, enterprise architects, they, they, they, they dread the midnight call.

They don't want the midnight call anymore. And what they fear is that they have these six tools and these six people on the six tools, but then tool number seven happen to have a yo-yo working that day and didn't see something and trying to, the comprehensive idea is that they can organize all of it in one place and see everything going on in one place and they get the little red lights in advance and they help fix it and they're being proactive and they get few or no of those, what happens? Something's down, everybody's gotta pile in and figure it out.

I think that's what, what it's really from the operations standpoint, that this desire for uni, it's to give for unification comes from, is to get a full and complete view. Not of what's happening now or what happened just a minute ago, but you know how to ensure service health for the whole stack going forward. And every time you add a tool, you don't, you're not just adding a person, you're adding a, a dis uh, an interaction point, um, a potential weak link in a chain, all that sort of stuff.

That's, and, and they hate that. They hate that part of the job. And the part that the time when this is the most critical to have this kind of a unified platform is when you're onboarding new employees, you want them to be able to come into work and in a few days have everything that they need.

And, you know, I've seen organizations take two or three weeks for, uh, a, a single developer to get all the tools that they need. 'cause it takes so long to figure out what it is that they should have. So there's a point in time that this becomes super critical and then you forget about it.

Yeah, no, I think we're back through and I think that is the jump cloud kind of vision right there. Tracy guy listening to you, I'm reminded of, back when I was in inter reliant in the late nineties, we were in a SP and we had this whole lineup of apps. We were hosting Oracle people, sort, PeopleSoft, Onyx, you know, late nineties apps, pre-cloud.

And, and we were trying, and we actually called it a miracle layer that would sit below all these apps and let us manage them, provision them, bill them, you know, do everything from a unified platform and that we would be able to plug more applications into. As you know, they pop up up, it's a bit of a holy grail. I I don't know if we ever quite find that.

I think we're really talking about two things. One is, you know, there is no one one tool that's gonna solve all the problem. Yeah.

It just, not, even if there was, it wouldn't stay that way, right? Something else would come along. It would be that would disrupt it.

So we really have two things. We have, we have portals that get to help you with that onboarding. Here's the set of tools, here's the capabilities, here's all the stuff that you need to kind of get started, right?

You don't have to go looking for tools. The other, the other trend is towards what you're talking about, Alan, which is platforms, which isn't one thing to rule them all. What they are is a set of pre-integrated capabilities, usually from one vendor that also shares data across those tools.

So you're not, and also between the integration and the data, you're spending less time in the tools management, integration support business, but they all have to have very rich integration capabilities and not just lip service to integration to third party tools. 'cause people use other stuff. Maybe there's testing capabilities in the platform, but I'm a tricentis customer.

We've already got all of our stuff built in into that and or to, to whatever tool for security, et cetera. There are some things that you want, one of, you want one directory or at least a federated set of directories, right? That you want one, you want one, uh, I, uh, ID identification or ID management of people, devices, things like that.

You want one sign on? Well, there's a capability kind of tie those things together across applications. But even those aren't one platform, right?

Those are oftentimes things that are tied together. Uh, I don't, I don't know if I agree. I, I think, I think the single platforms of Kyra, I think that that being able to manage ad plus JumpCloud plus whatever in one place is both possible and desirable.

It's just when you start, like you, when you start to add more and more things that you're all seeing in one place, like you say e even if you succeed innovation, you know, uh, uh, puts that at a date, but yeah. Yeah. But I, I think, I don't think it's settling on.

I mean that's one approach, the single source approach, settle on one directory, just stick with that. Um, but also, uh, being able to, uh, add or use other, um, other directories and, and, you know, uh, identity systems while still not, without having to add a separate way to, to operate them. That's more the goal here.

And I just wanna open up a issue in GitHub so my platform engineer can set, set my environment up and I don't have to think about the directory. I wanna be served my environment and that's Another Yeah, no, I absolutely, well Is an important Talk. Doesn't that go back to the, or like when I first got involved in tech, I was the mantra of it.

Our customers are the employees, the developers, and we serve our customers. It's an internal customer changed over the years, but it's still true. Anyway, guys, we're, we're over time.

I gotta pull the plug. Um, what a great Monday back to work week. You know, I still think we should have a national holiday after the Super Bowl, but, um, we hope you enjoyed the show.

We'll be back tomorrow. We've got a ton of great text drunk TV following this today, so check that out. But until tomorrow, on behalf of the gang, have a great day everyone.

We're outta here.