Techstrong Gang – March 4, 2024

Hey everyone. I'm Alan Shimmel. You're watching The Textron Gang.

Stick with us today as we talk about, uh, modernizing DevOps, ML ops and our newest text Drunk Site. This is the Text Drunk Gang. All right.

Hi everyone. We're back here on TechOne Gang. We've got a great, uh, section or a couple sections of topics to discuss.

We've got a great group of people to discuss them. Let me introduce you real quickly joining us from the DC area, our good friend and, and original gang member. Don't take that the wrong way.

Tracy Bannon. Hey, trace. Welcome.

Hey, how are you guys doing today? Great, thanks for the invite. Great, thank you.

Thanks for joining us. Joining Trace, uh, from Colorado, where, where he's based, uh, tech Strong CTO, and, uh, principal, researcher, friend, head of, uh, tech Strong Research, our own Mitchell. Ashley.

Hey, Mitchell. Good morning as always. Good to see everybody.

All right. And then here in Techstrong HQ in Lovely Boca Raton, Florida. I'm joined to my immediate left by our Echo Insights editor and, and general expert on all things green and meteorology and more.

Bonnie Schneider. Thanks. Great to be here.

Thanks, Bonnie. Welcome. And then last but not least is our chief Content Officer, uh, Mike Ard.

Mike, welcome. Happy to be here. Why don't you kick it off?

So there's a lot going on in the land of DevOps, and it's, we of a deeper conversation about what exactly people should take away from all of this stuff. 'cause most recently we saw, um, a company called Octopus Deploy, acquire another company called Codefresh. And if you dive into that, there's a lot of conversation in there about how to modernize DevOps.

And we hear the same thing from jfr. We hear the same thing from CloudBees. We hear it from Harness, and we hear it from, uh, GitLab.

And everybody's kind of talking about the same general motion, but in all slightly different, uh, parlance maybe, and slightly different context. So I'd love to get Tracy's perspective on what's going on here, because, um, I saw her a couple of months back up at a CloudBees event in New Jersey, and it was very similar conversation. What are we talking about here with the modernization of DevOps?

I think there are a couple of things. I'm gonna cover three items that popped into my mind. What the first one is, what we're calling platform engineering.

And when we met at Cloud-based, one of the things that was happening was that they were rolling out their new DevOps platform or application platform. So we're going, we're seeing a dramatic increase in trying to figure out ways to keep humans from making mistakes. So codifying leading practices, taking it down so that there's more than just a DevOps pipeline, extending it into development, keeping it, uh, you know, in full blown into your runtime, your production environment.

So that's the, the first thing. And that will, will, we will be seeing an intersection with low code, no code, I'd say in about 18 months to, to two years, because they're all trying to do the same thing. Make it easier for people to deliver value faster.

Uh, that's the first thing. The second thing is the rise of derel. You guys have heard of developer relations.

DevOps has a DevOps evangelist. The, that role is still there. But helping to create that relationship between the, the technical folks and the business is still a need.

We still have to get this alignment of business and tech, whether or not we're talking about all the new technologies or not. And the third thing is hyper automation, whether you talk about it from a generative AI perspective, ai, whether you're talking about it from using some of the existing RPA, the robotics process automations, hyper automation, continuing to reduce that cognitive load. So those are like the, the three biggies in my mind right now.

Mitch, do you agree with that perspective? And I'd like to add you a little something else on that, where Sure. How easy is it to do that?

Am I ripping and replacing an existing platform, or I trying to extend what I currently have, and what does that, how do you, we get from where we are to what Tracy just described? Well, first I agree with Tracy. She, she touched on three really great topics that are all part of modernizing this.

Um, you, you know, you mentioned platforms. One of the things that, that always is a challenge is once you've invested in setting up A-C-I-C-D process or whatever it might be, that's part of your DevOps workflow. You know, those things don't just rip and replace easily, right?

Just take Jenkins for example, and the, and the popularity of how it's still in use today. There's different numbers around. But, um, I, I think what's happening though is, is while those things have sustained us, we're, the market is working in a kind of challenging financial climate, trying to figure out how people continue to innovate.

And I think that's one of the reasons why, you know, we saw Octopus deploy, uh, acquire codefresh, which is all based around Argo and, and, and open source platform. And trying to innovate that and also bring in sort of the gi GI ops perspective. I don't think GI ops is necessarily gonna take over the world.

It's not for everybody, but it's great for some teams as well. So right now, I think we're still in this incremental development, though. That's something we're looking at as part of our DevOps next report that Alan mentioned will come out in May.

Alright, I saw you shaking. So I, yeah, I got call BS on all of this. I think you got it all wrong.

I can't imagine you got it wrong. It's all wrong. No, strongly disagree.

Strongly disagree. Okay. You looking at point solutions and trying to pick point solutions as makers of trends Mm-Hmm.

Trends are in points, right? Trends are trends. When we talk about modernizing DevOps, you know what, it's not even my thought.

I got this from Jody Bonsai, who's the CEO at harness. What we're seeing in DevOps right now is the evolution of a, of a, of a concept that was born 13 or 14 years ago. Mm-Hmm.

Right? And, and it was very much tools were, were were the third shortest, uh, leg on the stool. Um, culture process was equally or more important.

But as Jodi says, you, you are talking about coming from a, uh, uh, a landscape of point solutions of, of cobbled together DevOps solutions. I had Jenkins, I used one of the 1500 plugins that come with it to make it work with that. And then I hope put something else in here to make it work with that.

And, and I, I, I moved from waterfall to DevOps. Well, guess what's happened? We've got cloud native.

Cloud native is the dominant new stack these days for, especially for new deployments, right? Mm-Hmm. For greenfield deployments, cloud native means Kubernetes for 95% of that.

If you are doing DevOps and your DevOps solution can't work in a cloud native environment, hang it up and go home, you're done. Right? This is the problem with Jenkins.

Why we saw Jenkins X and why we see all of these things. This is what's driving Octopus deploy and, and an Argo, right? Because the fact of the matter is code CODEFRESH is Argo, right?

Which is probably the north I'm not Disagreeing on. Yeah. I I, I'm wondering, I don't know that we're disagreeing.

I'm wondering if you're just violently agreeing with Her. No, I'm not. I, because I I don't think it's about platform engineering.

I don't think it's necessarily GI ups. I think it's a much bigger wave of, of maturation of, of platform to a platform from from point solutions. Yeah.

I think what I would add to that, Alan, is we're at the, you know, some, there are some, uh, DevOps companies that have been taking this platform approach and kind of leading the charge, if you will. Mm-Hmm. And others are figuring out how do they play in that world, right?

Yeah. Can they, can they stitch together or can they re-architect under a, a platform approach, uh, across it isn't, isn't just integrated, you know, various products across customers. Those folks are in a different place than, you know, the folks who've been doing platforms that are DevOps for some time.

So, well, it'd be interesting to see where that goes. Some have got head start, some are playing catch up, especially where you're not gonna raise a bunch of money, which is one of the reasons why I pointed that out about, but I'm gonna come back to The Argo engineering, Why there's a rise of that. Oh, go Ahead, Tracy.

I was just gonna pose a question to you. Mm-Hmm. In terms of modernizing, uh, DevOps, you know, one of the things we're seeing, um, is a movement towards more sustainable, sustainable operations, reducing energy, reducing, um, the physical, um, architecture of, of each, uh, of different elements.

And I'm wondering if that's something that you're seeing that's coming together as part of modernization of DevOps? Definitely green. It is absolutely a part of it, though.

Folks are getting sometimes mixed up when they think that their data center and the cloud are, somehow, the cloud is not taking those valuable resources. Water is the next resource that we're starting to talk about, not just of the energy itself, but the water consumption. And that touches in on our incorporation of the automation into modern software.

Because as we're automating, we are leveraging newer and different technologies like AI that require vast amounts of compute. Um, so the, the platform piece of this kind of to track back and tie this all together, platforms have been around for decades. I created them to help developers 20 years ago.

The point of, uh, DevOps morphing back and readopting what's old is new again, has been to increase value delivery, reduce the, the likelihood that developers make mistakes. So better codifying those things. For me, it hasn't been which platform do I buy, but how am I going to accomplish the mission based on where we already have the investment and waste on based on where the future.

Now you guys know, though that my goal is always to come at things very objectively. I wanna leverage, if you already have something that we can leverage and it works and it gives you what you need, uh, it doesn't mean that you have to rip and replace. I actually don't advocate that because there's a fair, fair amount of cost in replacement.

It's evolution like Alan said, Okay, we're good with this argument. No, I, I, I said what I had to say, I look, he said his piece, I think it's gonna be in DevOps next, right? That this is, this the evolution of DevOps and, you know, the, the, there may be a thousand points of light, but it, when it all comes together, it's a picture.

And, But hasn't it always been that way, Alan? Yeah. DevOps from the very beginning has been continuous improvement, continuous change.

And part of the problem has been that people didn't, didn't really adopt that mindset. We're gonna get to DevOps. We're gonna have a DevOps maturity model.

We're gonna have a DevOps. We are going to be DevOps. Part of the, what's happening now is this realization that, oh, this is all about continuous change.

It is all about being able to tool your organization to continually adopt and embrace new technologies, right? At the speed of relevance, at the speed of the threat that's emerged, et cetera. So I think we're seeing a whole bunch of industry and everybody rationalizing.

We said we were gonna do that, we didn't really do that. And now it's pressing forward and it's, it's coming and dropping in our laps that we need to change. It is, DevOps is a journey, not a destination.

Yeah. And DevOps is never done. Okay.

Agreed. It seems like to me though, there's a lot more debate about DevOps lately because I mean, Tracy had a post up on LinkedIn and talking about some arguments that people are having, uh, about various philosophies of DevOps. And we have a piece where a fellow's talking about shouldn't be shift left at all.

We should just fix things in production as we go along. And it doesn't seem like there's a lot of consensus about what DevOps means to each individual Team, but that's always been true of Dev. When you have a, a framework, and if we're gonna call it DevOps, a framework, when you have a framework that doesn't have a, a standardized definition or manifesto or, and purposely didn't want that, you are gonna have differing opinions and differing schools of thought.

And that's okay because of, you know, that's the whole thesis synthesis kind of argument, right? Out of thesis and going back and forth. Consensus is reached.

And I, I think that's what modernizing DevOps is about, is reaching the consensus. You know, when we first started DevOps Institute, people were really upset. How could you, how could you be teaching DevOps?

There's not, there's not a best practices of DevOps yet. We don't have a best practices. And one of the things we used to say is, there's an emerging practice, emerging best practices.

Here we are, 10 years later, we're still emerging best practices. And, and it'll continue to be that as because it's continuous progress. And I think that's what people need to realize.

You know, Alan, as I think about it systemically, you know, when we started and all of us started in DevOps, we thought of it as CICD, right? That's kind of where the nucle of, of this, of it started and grew. You think it's essentially expanded left and right, embrace Mm-Hmm.

You know, essentially all parts of the development cycle. But we used, we used words like DevOps tool chain. Okay?

There's your integrated point to point, to point to point, right? Kinda links in the chain. And at some point that chain gets really heavy.

The more links you add on, the more maintenance you have to do, the more kind of care and feeding that takes. And I think that's part of what's driving this evolution to platforms, right? You know, every, every development leader, manager, engineering manager asks the question frequently, are we a DevOps tool or are we a tool shop?

Or are we a software shop for our business? What are we doing? I'm spending so much resource on managing this stack for the tools.

And I think that's what's gotta change about how we mm-hmm. Implement DevOps on the technology side. Think about it from a platform perspective.

Um, if you to build on that me mature spot on, when we, uh, you guys know, for a long time I've been an advocate against the term a DevOps engineer, which implied that I have a jockey focused on just managing and maintaining tool change and pulling those things together. 'cause it's not the person that's designing the software to deliver out. And they weren't monitoring and managing production.

So there was this awkwardness platform. Engineering actually starts to merge, uh, and get after leading practices from a software delivery perspective. Because those platform engineers are not tool jockey.

They are stitching together, necessary lean amount of tools, but working with the developers who have to be pushing that, you know, pushing value out on top of that. So it's actually building better consensus in the organization by having a platform engineering team, which is acting as a service provider as opposed to the tool team that was, you know, to your point, providing a really heavy and sometimes burdensome shouldn't have to have that big a team to create those tools to support those tools, right? Platform engineering allows you to get smaller.

Why? Because the platform engineering team is smaller than the DevOps engineering team. Mm-Hmm.

Yep. Fewer of them. Yep.

When I see it, I'll believe it. Alright. Challenge accept.

Alright. All right. Like most philosophical debates, it never ends, but I Think, uh, I think it meet the old boss, same as the new boss.

Just opinions. Mm-Hmm. Let's move on.

Actually, before we move on, let's take a quick word from our sponsors. All right. We're back here at TechOne gang.

Hope you enjoyed a, a contentious block one here on, uh, where we are with modernizing DevOps. If this is of interest to you, though, again, DevOps next our Techron research report, uh, Mitchell and team are leading the effort there. And, uh, we're gonna cover a lot of that stuff.

Mike, what else do we have up for today? All right, Well, at the risk of throwing yet another grenade down the aisle, um, we're gonna be talking about what is the relationship between ML ops and DevOps supposed to be, we've seen Jfr is kind of extending its reach from its CICD platform into, um, machine learning operations that data scientists use. And a little bit of that distinction is that, you know, the ML ops folks have a set of best practices for creating the AI model.

A lot of times they have been managing the deployment of that themselves. There's an argument that says that the model is just another software artifact, and therefore it should be part of the DevOps pipeline. And we need to meld these things together.

I don't know where we are on this journey. The cultures are fundamentally different. Thoughts, opinion, um, there goes the grenade, Ooh, I'll jump in on this one.

So, something that I've said for quite a while now is that we have to figure out how AI ML ops, a AI models expert systems, now generative AI flow into a workflow that's part of DevOps or part of how we deliver software. But understand that there are different characteristics because what you're delivering with a, in, in ML ops is a model, a set of algorithms. Oftentimes it's also data, especially if you're doing generative AI data.

And so you, you don't release that in the same way that you would release a new, you know, piece of code or microservices or whatever you might have co uh, update to the model, but you might also have, uh, new data or training of the model that also gets released. And so there's a new kind of synchronization about how if we're releasing this, maybe it goes on a different cadence than the software does. Are there any interdependencies between that?

Right now they've kind of been on these two parallel train tracks and they sort of get really close to each other and hopefully nobody reaches out and loses a, an arm at touching the other one. So I think it's really good that that Jfr and others are looking at how we kind of embrace ML lops and make that part of our delivery process. So I think if you looked at this deal, right, it's, it was, uh, JFR doing a partnership with a company called Quack.

Mm-Hmm. And you know, just as a side note, one of the lessons I always learned in business development was when companies do OEM or partnership deals with you, like that generally means they didn't, not buying you or acquiring you. I, I would've thought if Jfr was a little, you know, I think this is a, a toe in the water versus jumping in the pool of ML ops for jfr, otherwise they would've bought quack.

I Don't think, I don't think I agree with that specific point. 'cause Jfr already has deals with Amazon for SageMaker and a bunch of these other things. There's 27 different ML ops platforms.

You can't get 'em all. Yeah. But when you're jfr and you want to own the platform, you buy the ML ops platform, they're not gonna be content using 27 different other ones.

I think you alienate 97% of the market when you do that. That I think, I think both things are true With That's the platform to point. That's your decision, right?

You make that choice where when another, like a, a GitLab for instance, has the same kind of thing. AWS does this all the time. They'll have an entry in a given category, but you could use a best of breed or something else if you want, but they need an entry in that category.

And I think had they, I think the fact that this was a partnership and not an acquisition says something. Secondly though, to me, there's mls, ml ops, the technology of machine learning data scientists and stuff like this. But then there's also ML Ops slash AOPs, which is a category we've seen develop over the last couple years more than that, my friend Dave Link, science logic, right?

Uh, big AI ops and ML ops. So, you know, when I hear ML ops, I, I start thinking, was this, was this a shift, right? For jfr or for any of these DevOps platform providers?

Because the action's been on the shift left, right? Working with Dev and, and getting software released where ML ops starts, starts talking about observability and sort of post-deployment in info information, you know, metric gathering. Is this a shift?

Right? Into, you know, and, and it's still part of DevOps, right? You get your feedback loops and your helps you iterate and reiterate and all that good stuff, but it's a shift, right?

Tracy, you want to jump in here and set everybody straight? Uh, well, sure. Uh, I've been working with an AI assurance lab.

Uh, and what does that mean? Well, it means that we have software. We have to have a DevOps mentality.

We also are DevSecOps mentality, quite frankly. We have to have, uh, ML ops, but we also have to have data ops. So there's this massive bifurcation.

How many different ops types do we need? So we've been looking at how do we distill that down? I've been calling it personally X ops, I don't care how many different types of ops you have.

You have to understand what's the collaboration, the integration, what are the automations that are shared? And what, what is your continuous improvement? And how do you make sure that you have agility and flexibility?

Like those are the basic principles of all the ops. Now, Mitch had said that, you know, an algorithm is different than migrating code. No.

An algorithm is code, code is code is code. When I deploy via DevSecOps, I deploy data too. So it's not as though we're suddenly doing things differently.

What has changed is testing. That is the big piece that changes in all of this. Whether I'm deploying software where I can complete all of the automations, right?

And I'm thinking DevSecOps, or I'm thinking about data ops, ML ops or whatever we call it X ops. The testing is the very different piece that that's there, that assurance piece and the roles of the individuals that are involved in that testing. We don't automate entirely all algorithm testing.

We don't, there are humans in the loop there, boy, say that to somebody who's a DevOps aficionado and their, you know, their hair sets on fire. So yes, we are seeing an evolution. And at the same time, if we look at the, if we make a quick map and lay out the key principles of each one of them, they distill down to those same things we've got to get after continuous improvement.

We have to understand what our agreement is on the problem that's there. Are we seeing ML ops platforms? Yeah, we are.

Do we need ML ops platforms different than our DevOps platforms? If you are deploying generative ai, AI ml, if you are deploying algorithms as a capability to your end user, you should be thinking about how you intertwine those things. Because that interface to get at that algorithm is that DevSecOps.

So do I put it through pipeline A or pipeline B? Platform A, platform B. So we actually have to pause just a little bit.

I don't mean stop pump the brakes and think about what you're trying to accomplish. To Mitch's point, it may be at a different cadence, but it doesn't mean that you have to have completely separate platforms, completely separate, um, approaches to doing this. We should be looking to collapse those in.

And that's what we're actually doing right now, isn't it? It's physically what I'm doing at the moment. It Seems like, how Do I collapse that in?

If you're Per I'm sorry, go ahead Bonnie. No, I was just gonna say, if you're, um, integrating more processes together, you are reducing the amount of redundancy, which is in turn gonna use less energy and make things just more automated and, and flow better. So I'm just thinking that, that these, I'm seeing a bigger picture in across our conversations that we're having, that we are finding ways to do, do these processes with, uh, less resources, more streamlined and in a way that can still produce great results, but not quite a hundred percent everything altogether.

That's just my takeaway. I think I, I think I, I I see it a little differently too. It, it, it isn't, the ultimate goal isn't one platform to rule them all, or one workflow to rule them are right them all.

And I think you do need different platforms for data management. You do need different platforms for model management and, and training and development. Um, because not only are they on a different kind of cadence, you don't develop models, you don't write algorithms alone.

They work with within a data environment that you're feeding to it and constantly training. Um, and that, and that takes a different skill. It isn't just writing code and testing it against a database.

Uh, just like managing a data environment isn't, um, you know, data has gravity, right? You, you deploy it into production, you just don't pull it back easily, right? Because it, it's state has changed drastically since you might have put it into production.

And the same is true about models. So I think, I think we don't want to, we don't want to try to collapse all this into the singularity of DevOps workflow. Oh, I, and we wanna didn't recommend that we back to say, a model's gonna be a model.

Generative AI is, we're still early in the process of learning how to deploy these mm-Hmm. More or less create 'em. Mm-Hmm.

So to me it's kind of rushing to the end zone and we haven't kicked off yet, right? So I'm, I'm not going to disagree with you. I'm going to sort of agree with you.

Okay. So I don't believe in a great singularity. I never have, you'll never hear me say that ever.

It's always based on context. What I'm driving at is recently, I think it was two or three weeks ago, GAO, right? The, the government's office accountability office or accounting office released an ai uh, uh, um, framework.

And it has seven or nine different types of ops that have to be somehow integrated to create some big discipline. And many of us in looking at this and, and understanding what they're trying to get at, they are looking at the bigger picture, as Bonnie mentioned, right? We need to look at the bigger picture and at the same time where there is unnecessary, that's the key term, unnecessary duplication.

And we need to be cognizant of that. Yes, there are different workflows. Yes, there are different individuals involved and some of the things are similar.

Every one of those, every one of those ops has an automated reproducible workflow. Do I need five workflow engines? Or do can one work can two work?

So I don't wanna get tools mixed up with process mixed up with the value that we're trying to deliver, right? Yeah. Ultimately the tools are important, but they are the least important in making the decisions on how we are getting after and value delivery.

What are we trying to accomplish? Who am I delivering to and what am I delivering at the end of the day? Last word on this, I, I think, Tracy, you made some excellent points, as did Mitchell.

Look, you really gotta ask yourself though, what do we mean by ML ops? I, I get there's a whole bunch of different ops. God bless 'em.

I get that. This generator of ai, it blesses itself, right? But what is ML ops for most of us watching out here?

ML ops is tied into observability, really. It's become observability, AI ops. And is that what Jfr is making the deal with here?

Or are they making the deal with doing multiple platforms with generator of AI and all these other kinds of ops? I, I don't think, I think it's a much simpler equation. But anyway, we're gonna take a break 'cause I, I got the last burden.

Why not? Oh, you're so funny. We're gonna take a break.

We'll be back here in a moment with our next segment. 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, back here on Text Drunk Gang. We've been having some great conversations.

It's great to have Trace Bannon with us, Mitchell, myself, and Bonnie and Mike Ard. com. ITSM.

That's not new. What are you doing? I asked the same question of our chief content officer, Mike, why'd we do it?

I think in our last segment we explained why we're doing this. 'cause there are so many different flavors of ops, right? And to Tracy's point, there's X Ops and I think early on we got into this DevOps versus ITSM debate and conversation that probably in hindsight was kind of silly.

Um, I think what we're seeing today is the two get melded together. A lot of times you'll see software engineers are using the same tool that a IT administrator uses just 'cause it's simpler. Conversely, a lot of the ITSM tools have programming extensions that you're see in a lot of the, um, IT folks learning Python so that they can essentially do DevOps kind of things.

So I think the world is melding together and we want be a part of that conversation. And a tech strong ITSM site gives us a site that speaks to the traditional IT administrator in a context with DevOps. And ultimately I think that's where the dialogue and the conversation is going.

But, you know, that's my opinion. I don't know if you guys are seeing something else, but that's how I see it. I'll just give you a high five because I agree with you.

I'm dev, married to ops, and we've been having this discussion for years. There's never been a reason to kick ITSM to the curb. Quite the opposite.

It's been, it exceptionally helpful. Why do we not marry the two? There have been pockets of goodness this way, but I think standing up a site around this to really bring the conversation together and build out that community spot on, very much an advocate.

Thank you guys When there's a nice evolution of this too, because I think it's, IT TSM four took a relook at I tsm IIL four, Mitch, IL four, ILE four, sorry, IL four. Um, and adopted a lot of the ideas behind DevOps and tried to incorporate that into, so, so it wasn't such an a, uh, ops only centric. It's like, how do we fit into this bigger paradigm?

And I like how, um, we've positioned it, you, you and Mike have positioned this as kind of filling in the gaps, right? Between Agile and DevOps and ITSM and how these things happen. So it be interesting, you know, I think we're in a unique position to help bring those communities together through a site, through content, through discussion, you know, um, more inclusive of that.

I'm excited to see where this goes. I think that's a good point because the more you're bringing these communities together, even within organizations that might come to our site, it's forging a, a culture of, with one hand knowing what the other's doing and just being more cohesive. 'cause that seems to be an issue with all the, the different ops we were just discussing.

And even ITSM within larger companies, there has to be, uh, communications between all hands. So first of all, let me put a quick plugin, uh, later this month. I think it's March 23rd.

I'm not a hundred percent sure. It might be the 24th. com, you'll see it on there.

We are working with our good friends at People Cert, who are the people behind it, o and also the people who now operate DevOps Institute. And, you know, DevOps Institute always put on people's, uh, skill updates once a month where they would examine relevant subjects within DevOps. We're now doing that once a month, but one month it's it o one month it's DevOps.

Another month it might be a project management print two. So this month is an ITIL ITSM month. com.

Um, again, that is with people search the people, you know, the owners of it, l and and DevOps Institute. I wrote an article for the launch of the site and, and it kind of sums up my thoughts on this, which is, it is a continuum today, right? Whether you go from the far far left, where, believe it or not, it's the business people who are involved.

What do we need? What do we need from it? What does it, what can it do to help us with our business through what today is agile?

It's pretty much, you know, not to say that there's not plenty of waterfall out there, but Agile's 25 years old, well established people, you know, think of incremental development and, and stuff like that. com said, you know, DevOps picks off, picks up where idle leaves off. And in my mind, ITSM and it o as part of that kind of pick off or pick up where DevOps starts trailing off, right?

So there's an overlap there, but clearly towards the tail end. And so this continuum of the software development life cycle is an, is one continuum. And now we, we don't have an agile site.

Maybe that's something for you to work on, Mike, but we, we certainly have DevOps and um, and now we have ITSM. And so to me that's why it really does make sense to have this Tracy, do opposites attract? I mean, are we gonna have more of these romantic relationships between DevOps and ITSM folks or where I actually am?

I believe in that entirely. Like I, so, and, and the reason that I do is that you've often heard me say in DevOps, oftentimes in DevOps, we just forget the ops part. We talk about it and we bring ops into the conversations, but we're not focused on operational excellence.

And that is ITSM. That's why the ITIL frameworks were created in the first place. Yep.

So y'all, y'all, It's, we have to do it. It's long overdue. Yes, It is.

Long overdue's Proof in the pudding. And by the way, the, the event is on March 26th, I believe. Okay, Alan.

Um, but some of it, I was looking over the topics of what people are speaking on, and it isn't just ITSM or idle, right? It's, some of the topics range from how idle can fuel your, uh, event or your rapid response plan. Um, how integrating idle with emerging technologies, how the power DevOps tools and supercharge charging idle process.

So it's, it's naturally evolving to this conversation of not just about one vertical discipline, but how the benefits and power capabilities of different disciplines can work together to achieve more. That's all for the good far as I'm concerned. I'm gonna take it back to what we said in, in segment in the first section that we talked about earlier today.

Continuous improvement, continuous evaluation, continuous evolution. Continuous, continuous, continuous. Be open to that mindset of changing.

And we're seeing that. I think there's a bit of a forcing function, making people change, right? You're either pushed by circumstance, pulled by dream.

I think we're being pushed in a good way to have to merge these things. We have to just be more cohesive in order to have the operational excellence is necessary now long Lived continuum. All right.

Just Just to, just to curious, a plug for everybody who's watching this, we need you to contribute content to make this little vision a reality. com. Sorry.

Yeah. com. It gets to us.

Good. This way Mike doesn't get spammed. I do.

Um, Mitch, did you have a question for Bonnie? Yeah, I was just thinking, um, I don't know if it'll show up in this particular event, but it seems like sustainability, whether you're talking about writing more efficient applications, more efficient infrastructure, operational processes, flows through this whole, um, through, through all these topics. It's a river.

There's at least one thread that ties 'em together. There are multiple, but I'm curious your perspective on how that's being embraced by the different communities. Uh, well I'm, that's an interesting point 'cause I was just having a conversation with some, uh, folks in Europe about this yesterday.

And it seems like there we're getting, um, it's readily being embraced, um, particularly on any way we can reduce redundancy, um, limit energy over overuse. Um, and that does go towards observability, but also just in general of how we're empowering data centers and things like that. So I would say that looking at, okay, looking at 2023 to 2024, I'm seeing an increase in this overriding theme of sustainability and watching how we're using energy and becoming more energy efficient than I saw just a year ago.

So it is a, a growing interest even in, in North America as well. Very cool. I think that's also tied to cost.

People have figured out that energy equals more consumption and it equals money. I would love to say that people are doing this because, you know, they care about the environment, but I think the green part they do care about is in their wallet, There Are multiple green. I would disagree with you on that based on the audience that you're talking to.

I was talking to some folks in, in the UK yesterday, and it was very much about their passion for sustainability, right. Especially when it comes to water. Yeah.

Right. We really, people are not, we we're all talking about the sustainability of the electricity needed for this, but these things need to be cooled. All of these data centers need a massive amount of water.

And that's not as renewable. Mm-Hmm. It's just not.

So where are the, you know, talking about the infrastructure that's necessary to get to the compute power that we want and the blast zone of all of this generative AI and the amazing compute that's necessary for that. It, it's daunting. I'm, I'm really gonna be following you, Bonnie, to see, you know, where you go with reporting and during the research on the sustainability aspect of this.

I say bring your motivation, whatever it is, I'll take it. Yeah, no, bring whether, whether it's green or green green water. Yeah.

But you know, and I will say as an American, unfortunately, I think you get that kind of sentiment over in the EU a lot more than you do here, where we can't even stop fracking knowing the damage it does. So As a, as a Pennsylvania resident with friends who own farms where fracking has been, you know, has caused environmental issues for them. Yeah.

You are spot on. Sometimes the physical, It's the American way. It's all about the dollar, unfortunately.

It Is. It is. Oh, Whatever.

Um, Now we have to end on a positive though, Alan. Take us Positive. Let's end it on a positive though.

You know what? We've got an ITSM site up. There's all kinds of great things going on in DevOps and, um, this is our first show of next of the week.

We've got two more days of great Textron gang coming up. Join us for those. We'll be back with the gang and, and maybe some new gang members.

Uh, until then though, this is Alan Shimel for Textron Textron Gang. Have a great day. Discover the cutting edge insights of our new show, AI Times, a series that explores the limitless potential of artificial intelligence sponsored by the AI Infrastructure Alliance.

The AI Times is at the forefront of the AI revolution, tackling the crucial questions of how we can leverage AI for the betterment of humanity. Stay ahead of the curve as this show delves into all things surrounding ai, including trends, pressing concerns, and the positive impact AI is making around the globe. AI times.