Techstrong Gang – April 18, 2024
Alan, Mike, Bonnie and special guest Mark Hinkle debate the real state of DevOps in the enterprise, before diving into exactly how artificial intelligence (AI) is being applied to application development. Then, the discussion turns to what parts of the machine learning operations (MLOps) workflow should really be managed by a DevOps team.
Transcript
Hey, everyone. Happy Thursday to you. Nothing new here at Techstrong.
Actually, there's plenty new, I hope you've been, uh, keeping abreast of some of our announcements later on today on Techstrong tv. You can find out more about our announcement of Partnering Upward being acquired by the FU Group. Um, but for now, you're watching Techstrong Gang.
Welcome back, everyone. Yes, it, it was a bit of an unusual opening here 'cause it's been a bit of an unusual day or two here at Techstar Week. We made a major announcement here.
We're looking forward to some really shaking up the world of media. But on text, on gang, we're gonna keep it the way we always do. We'll have our gang members talking about stuff that we think you wanna know about.
Today we're gonna talk about what's the real state of DevOps. We're gonna talk about how our developers embracing ai. How and where does DevOps meet ML ops on the road here?
And maybe more than that, let me introduce you quickly to who we've got on the gang today. Joining us remotely from Raleigh. He is our AI expert, the one and only Mark Hinkle.
Hey, mark, how are you? Great, Alan. Congratulations.
Thank you. It's good to have you here. Joining us in our bulk of Raton headquarters, uh, to my immediate left, it's really very easy to tell the difference between them.
But to my immediate left is our Echo Insights editor well as, uh, contributor, Bonnie Schneider. Bonnie, welcome. Thanks.
Great to be here. Thank you. And then on my far left, again, Haing from the Bronx, actually, was it far?
Not, not Cardinal Spellman. It was, it was Cardinal Spellman Outta Cardinal Spellman High School. Mike Ard, our Chief Content Officer.
Hey, Mike. Hey guys. Everybody happy to be here as always.
So, Mike, why don't you kick us off today? Well, Let's get started with the state of DevOps because our friends over there at the CDF, uh, the Continuous Delivery Foundation, I think is what it stands for. Yes.
Um, they're part of the, the Linux Foundation, and they have a report out that kind of did a survey of where developers are in their DevOps maturity. And it kind of seems to indicate there hasn't been a lot of progress in the last three or four years. And folks are kind, 80% say they're involved in some level, but when you look at the level of involvement, they're not that deep and more about using it occasionally for testing and only a third or into continuous integration.
And I guess my question is, and I'll start with you on this one, is that, is that an an, an issue in your mind is do we need everybody to have this, you know, may it massive amount of maturity, or is DevOps just kind of finding its right level by organization? And each developer team will decide what's good for them? I think this survey was paid for by the Platform engineering squad.
Um, anyway, you know, we, we do a show on Techstrong tv, and you can check it out. It's called CD Pipeline. And I, it should done in, uh, in cooperation with the CDF.
And we actually covered this on a recent, uh, CD pipeline show. And we, we actually had a platform engineering guy, two people, well, one was the chairman of CDF, and one was a guy from the, uh, Spinnaker to, you know, people, uh, the Spinnaker governing board and myself. And it did unfortunately, uh, degraded into a little bit of a, of a, not a shouting match, but, you know, I had to remind someone, if you don't learn history, you're destined to repeat it.
And, um, I, I don't, I'm not faulting their survey. I just don't buy it. I don't buy a lot of these numbers.
I, I don't know if the sample size is big enough. I don't know what the biases were. My, my feeling is this, you know, uh, Andrew Clay Schaffer, right?
Uh, John's friend Andrew, he always says, the DevOps you get is the DevOps you deserve. These people get the DevOps they deserve. I I do think, and it's not DevOps, when you look at any adoption wave of technology, you, you have the, uh, you know, the crossing the chasm model, right?
You got your 15% of early adopters, and then 70% of the market is main mainstream. 35% of that is, you know, the beginning of the mainstream. And 35% of that is kind of the end of the mainstream.
And then the last 15% are, are laggards. I think it is very, very clear that DevOps has gone across the chasm to mainstream and is well into the second 35% of the mainstream. Is it adopted enterprise wide at every large enterprise?
No. But is there DevOps going on? Yes.
Are people still experimenting? Because your DevOps is never done. Your DevOps journey is never done.
Yes. Is that a reason to say, oh, DevOps, uh, you know, DevOps is a failure, or DevOps isn't working? Absolutely not.
Mark, you want, Mark you want to jump in here? I know you've been around the DevOps space for a while, but what's your take on, where are we on this curve? Well, I mean, first off, I gotta concur with Alan.
These numbers are sort of wacky. Um, and so I really, I I would think that, um, there would be a lot more folks doing continuous delivery and deployment than this seems to indicate. And I think that they probably do do that, but they do that in methods that are not, you know, circle ci, cloud native methods.
They're probably, you know, a different patching and provisioning feedback. But I, I mean, I do feel like everybody wants to be DevOps. I meet a lot of folks who are simply just engineers or developers who tell me they're DevOps.
And there's a lot of folks that really embody those, you know, DevOps practices that, that Andrew Clay Schafer and the John Willis' and the Patrick Devo talked about early on. But, um, I do think that there's a lot more folks that are talking the talk than walking the walk and that. But I am surprised, I would think that, you know, where does this all start?
CICD, you know, deploying your, your applications is, and doing it effectively seems to me to be pot odds. And it seems a little low in my, my estimation from what the survey says. Here's What I hear a lot of, I hear developers are kind of into the CI part of the CI ICD equation, and they kind of get that to varying degrees.
I don't hear a lot of success on the CD side, and it has nothing to do with the nature of the CI ICD platform. It has everything to do with the end platform that you're deploying stuff on. It doesn't have a standard set of APIs.
There's a lot of snowflakes. It's very hard to automate it. I mean, one of the nice things about Kubernetes is at least you get a standard API, but it's not everywhere.
So it seems to me the whole CD side of this equation is still very early stages, despite the fact that we've been doing this for a long time. Um, it will get better, I think, but mm-Hmm. Um, and a lot of people are trying to separate or more loosely couple CI ICD because the platform engineering team might do the CD side and the developers will keep the CI side of this equation.
So I think it's evolving, but I don't think there's a one size fits all. Yeah. There definitely isn't a one size fits all.
Um, you know, I I, I'd be interested, and I haven't seen a survey on this in a while, what percentage of people are doing, let's say, waterfall Mm-Hmm. Versus CICD. I think that's a valid way of looking at it.
But I think you also gotta remember that DevOps may not be the right tool or the right, you know, methodology for every instance. I think there are some times where waterfall is the right way to do things. Mm-Hmm.
I think there are other instances where DevOps absolutely is the right. I think there are other interest instances where you should use, you have to use Kubernetes and Cloud Native, but there are other instances where you shouldn't cloud OnPrem. It's a, it's a, it's a wild mixed up world, except for Lola.
It Is, I talked to, I talked to a lot of folks who use a mix of things, right? The front end with the developers is very DevOps centered, and the back end where the deployment takes place is very waterfall centered, just because it's the nature of their fault. Yeah.
Yeah. This, there's a lot of that. So I think we get ourselves in trouble when we try to say, everything should be this or everything.
The CD pipeline show, that's where they went. Everything should be guard railed for the developer because, you know, stop, it's, it's, as I've gotten older, you know, I think I've learned that the most, one of the most important things is you gotta use the right tool for the job. And, and if you are using the wrong tool, you work a lot harder.
Trying to fit that square peg into the round hole is, is just, Does it take you more time? If it takes you more time, it takes you more effort and it doesn't work. So I, I think today's developers today, dev, today's DevOps teams, today's platform engineers, today's sre, it's about using the right tool for the job.
And each job has its own parameters and its own requirements. You know, mark, are we too, shall we say, zealous in our opinions about what DevOps is? And maybe it seems like the people using this or tailoring it to whatever need they want.
And it's, I think, uh, McVety once said, DevOps is like water. It finds its right level in each organization. Yeah.
I think, you know, I think it's important to have a clear understanding of what it is, um, and how that, what that methodology is applied. 'cause if you don't understand something, it's hard to, you know, manage that process. Um, while you guys were talking, I was, I, the thing that I, this is just intuition, but I think the cloud native folks, we were the, were talking about the, the CICD target than you mentioned is I would guess that they were probably more along the lines of using CICD.
And this 10,000 people came from, you know, data that, that was, uh, collected by an outside firm, not the CICD foundation itself, it looks like. But what I did see in the appendix that's really interesting is a lot of these DevOps practices that we talk about, like source control management, CICD, they are, um, in use with, uh, developer software developers with more experience. So six to 16 plus years has a lot more of the folks that are doing CICD, that are doing source control, that are doing all these things that make it easy.
And I suspect that's because the first six of the years of their career, like mine, I just got hit in the head by not, you know, putting a process in place to make it repeatable. So, you know, so They got the T-shirt Yeah. To prove it.
Yeah. Benjamin Dera said, you know, lies, damn lies and statistics. You know, I, I think the takeaway is that, a, we, we don't have a clearly defined DevOps definition.
And BI think that it tends to be something adopted by folks at least from this data, that have more experience. And that, that would be my, my sort of takeaway personally as well. I gotta give Mark Hinkle a shout out here.
I think in all the years of doing the videos on Dhar tv, he's the first one to use a Israeli quote. There you go. Kudos to you, mark.
Excellent, excellent. Most people would say that was Samuel, uh, Clemens. But, um, no, We've had Sam Clemens quotes.
Usually rumors of mag demise have been greatly exaggerated, right? Mm-Hmm. Yeah.
I don't think we've had a Israeli gears quote. A little cream reference there for my music. Yeah, it Is.
All right. Yeah. All, all your researchers out there direct your emails to Mark.
Okay. Yeah, exactly. Alright, hey, I think, I think we've beaten this one for a while.
Let's take a quick break here on the gang and we'll be back with our developers. 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. And we're talking about this survey that Docker did more statistics by the way, um, talk.
And it shows that a large percentage of developers are definitely using gen ai. They're using it for everything from actual coding to documentation and all kinds of interesting capabilities. But buried in, there was an interesting stat in my mind.
Nearly half of them said that we're making too much of ai. They're kinda like looking at it and saying, you know, it's already old hat. It's like, kinda like in their kid already.
And they're kind of sitting there going, you know, I'm just doing my day job here and thanks for the little help. But they're not like going, this is changing my world. They're certainly not thinking that they're gonna be made obsolete.
So, mark, let's stop, start with you. But, you know, have we like seen the AI thing come and go so quickly now that people are taking it for granted? Or what?
I think that it has been so overhyped and I think, uh, bill Gates used has a quote about this, is that we tend to, um, overestimate new technology trends in the beginning and underestimate them in the, in the long term. And I think that's, that's exactly what's happening here is, you know, it's AI everywhere. And at the, you know, as you look at these stats, everybody's interested in it, but it's interested in the promise of ai, not the, you know, today, you know, I've, I I can't just type in something into chat GBT and get the exact, you know, output.
I want it, it helps, it makes it better whether I'm developing code or writing prose or analyzing documents, but it's not a silver bullet. And I think that's probably, you know, where we're at today. I call it the sex and high school phase.
Um, everybody's talking about it. No one's doing it. But, uh, I think there are very few are at least.
And I think that's where we're at right now. You know what, just a shout out, the man follows up a Benjamin de Israeli quote with a Bill Gates quote, mark, you're on fire, man. Good for you.
I, I have a, I have a kid going into high school this fall, so I'm hoping it stays that way. Mark. Um, let, let me weigh in here though quickly.
You know, I see, I saw a survey that something like 61% of all the code that we're seeing generated now has AI fingerprints on it. Meaning it was either written by ai, checked with ai, argumented with ai, or somehow AI was involved. That's an incredible amount given the, the timeframe for how long we've been, you know, using AI in writing code.
Um, I, I think like everything else, people try to normalize, right? You get a new technology, a new tool, a new way of doing things, you try to normalize that into your routine. So they're like, oh yeah, I'm using ai.
Know what AI is. You know, you ask you kid in high school asked my kids in college, oh yeah, we're using AI to help write papers and stuff and research or what have you. So people have started normalizing ai.
But to your earlier quote, mark, you know, that we overhype in the beginning and under high hype at the end, what they don't realize is that the AI we're using today is, is relatively rudimentary to the ai we'll probably be using even a year or 18 months ago. What I find fascinating about the whole AI adoption cycle is that, you know, we we're all in tech for a long time, right? And we've all seen internet time, how, you know, how the adoption cycles have shortened.
I've never seen anything as shortened as ai. It seems like AI is taking adoption cycles into a wormhole, right? And, and it's just, it warped speed.
I was just gonna say, is there some subjectivity though to, to that survey where developers are been hearing from everybody, AI could replace you, AI could replace you. So on some self-preservation, wouldn't they say, well, it's not a big deal anyway. I mean, this seems like a human nature thing.
They might say, You're saying that the folks taking the survey might be a little biased. Biased. Yeah, there you go.
Possible. I see same platform engineers. I think it's one of these, it's a lot like the last, uh, subject we had where it's, it depends on where you are as a developer, right?
I've talked to developers who haven't written code in years, and they love ai. 'cause now they can code again. And they're like, you know, they were never great developers in the first place, but now they're better developers.
But then there's more experienced developers who are kinda like, I can't get this thing to gimme the same thing back twice. And it, and so I'm only gonna use it maybe to write a script, but they would never use it for business logic. So it kind of seems to me we need to, uh, maybe define some spectrums of usage and kind of have a little more nuance and how we're thinking about how developers use ai.
Mark, I don't know, you code a little bit. What do you think? Yeah, So, or the, I think you and Bonnie both hit on something is, is we see in the reports 64% use AI for work, but 33% do coding and 29% to documentation.
And that's a big thing. So if you're looking at it, documentation, writing tests, um, those two things are almost as high in the percentages. And those things are not nearly as difficult.
Well, writing tests are time consuming, documentation is time consuming, but not as difficult as writing good code in my personal opinion. So I think, think that they're seeing a big uptick. And this is anecdotally what I hear as well is people, if you don't like to write documentation now, have an easy way to write good documentation and to write their unit tests.
At the end of the day, if it's a complex piece of code that's still, you know, an architect or a senior developer skill that I don't feel like, uh, um, you know, get an GitHub copilot or, you know, some of these other sensationalized things like Devon and get a touch, I think it will get better though. Because to your point, the underlying engines are getting smarter. There's more parameters in there.
The context windows are getting larger, it's more expensive to run as a result, but, uh, we can train it using a set of code that's been vetted. I think if you look at chat GBT, they pull code from everywhere they can find, and you get to an average, and the average is kind of relatively low. I think there's a lot of vulnerabilities in that code that gets generated 'cause it came from code that it has vulnerabilities.
But I, it seems to me the whole thing is gonna get a lot better in, uh, I don't know, nine months, maybe sooner. It just depends on how much you're willing to spend to drive the outputs you want. So there'll be tears.
Yeah. Just one other point to, to both you and Alan's point is, everything we're doing today is accretive towards the result we're gonna get tomorrow. And that's one of the reasons is this training is accretive to making it better every single day versus some previous technologies to not build necessarily in the same way as AI does.
All right. Let me ask you the core, core question then. Would you tell your kids to become developers today based on the fact that we have all these AI capabilities?
Or would you say that's just gonna be a service you're gonna call? That's a great question. You know, Benjamin Dera said, grow up to be AI engineers.
Um, but no, seriously, I've had this conversation with both of my sons, one who's going to be a, a sports, uh, journalist, broadcaster, one who's going to law school. I had the same conversation with one of my very good friend sons who's in, uh, college right now is a marketing major. And the thing I ask all three of them is, when you think about where you are going and what you're gonna do in your life and what you wanna do, how is AI gonna play into that?
Is it gonna replace you? Is it gonna enhance you? Is it a non-factor?
Right? And let's be honest and, and take a hard look at it and first of all, who the hell knows for sure, but we'd like to think and based upon pre previous technology adoption cycles, that the smarter people learn how to take that technology and enhance their skillset. Upskill enhance their value as an employee or a entrepreneur or what have you.
However, there are always people who are casualties of new technology, right? Typewriter manufacturers have had a hard time. IBM at one time made a good business from those electrics.
A vintage typewriter is very expensive though. Yeah. First find some way to use it, right?
The whiteout people and the, the what was the little white thing you would put in the correct type thing or whatever. Um, so I truly believe that, hey, if you are mark age, or you, heaven forbid my age, and you're a coder, you don't gotta worry about AI replacing you. But my kid who's in college now or high school or just coming out, I would think, you know, by the, let's say the year 20, 35, 10 years from now or so, they gotta think long and hard about what being a developer means.
This, it just a glorified prompt engineer telling the AI what to write. Mm-Hmm. And, and I, and I think that's, you know, I I'm sorry if that upsets people, but I, I think that's the, the, the crux of it.
I wonder what AI would say if you put that question in. Would AI be biased? Turn itself and say, well, that's of course I'm gonna take over everything.
No, I, I think according to the second law of AI robotics, it'll say no, we would never take, oh, you're right. A human. Yeah.
Uh, I don't know. I mean, I don't, Mark, I'd like to get your take on that because I Believe believed that there is a, a way software needs to be constructed that requires a sense of flow and logic that I'm not sure the machine is ever quite gonna get to. So there's a difference between writing code and maybe orchestrating some, uh, tasks and actually constructing the application.
So where do you think that, um, person to machine interface is gonna be? You know, there's, there's a reason why we take those philosophy classes, like introduction to logic when you get a compsci degree up than the fact that it keeps us out of the computer labs. But, uh, I think that critical thinking, that ability to put stuff together is still gonna be essential.
Um, I I think it's gonna be more about guiding it, but not so much, um, about, you know, writing JavaScript or Go or Rust or, or whatever for the, um, um, do whatever's going on. And just for the record, while you guys were, uh, pontificating about what AI would tell you about growing demand for developers, according to Jack GPT, despite the advances in ai, the demand for skilled software developers continues to rise. So I think it's covering its tracks.
Hold on a minute. How much money does Microsoft have invested in opening? I mean, again, back to what I said in the previous G block, you got to not, you know, it's not the AI of today, it's the AI of tomorrow.
You gotta be thinking of. And, and that to me is what this question is. Anyway, fascinating stuff.
You know, I I, and, and I, and I say this in all honesty to all of our watchers and readers and listeners out there, it's not the effect it's gonna have on us here on the show, but if you've got children or you're a young person coming outta school recently outta school, um, you gotta be, and I, whether you're a coder or a marketer, or a lawyer or a doctor, you gotta be thinking about what role is AI gonna have on my career going forward, right? And you could, and, and there's two kind of reactions to this. You could curl up in a fetal position and say, woe is me.
What's the sense of, you know, going forward? Or you could say, how do I make my lemonade out of the lemons here and, and leverage this thing to be even more valuable? And I think those, that's what separates the winners from the losers.
All right there. Hey, we're gonna take a break. No, I was just gonna say, so the AI bear is chasing us, and I just gotta be faster than the next guy.
That's always the case, isn't it? All right, we're gonna take a break here on the gang. We'll be back in a second.
All right, folks, we're back one more time. And we're talking now about the rise of ML ops, otherwise known as machine learning operations. And this is the whole process used to construct the AI model, which is different than the applying of the AI model into something that feels more like what we call AI ops, which is a slightly different connotation for the thing.
But if, if we are getting to the point now where AI is gonna be pervasive, it seems like we are reaching a point where ML ops needs to be everywhere. And the question is, is where does ML ops begin and where does DevOps end and where's the handoffs? And how is all that gonna come to play?
Um, mark, I know you've been kind of messing around in this whole AI space for a while, but it seems to me that maybe the data scientists should build the models and the DevOps team should deploy them. But what's your sense of what's going on? You're hitting right in my heart there.
I I, the fact that we have like little labels and fiefdoms of e like it made sense when ML ops was a very specialized discipline and didn't do a lot in production. Now it's gonna be pervasive across the enterprise with geni. And the funny thing is, you mentioned it, AI ops versus ML ops.
Like, do we gotta get that fine-grained, or do we just have to adopt Gen AI and ML throughout the enterprise and, you know, leverage the systems that are already in place to manage them. We're just gonna have to evolve them. That's my, you know, my very opinionated thoughts on it.
I don't Think that's so opinionated, but you, but you're right. We're I, I think we gotta get over ourselves on that. Yeah.
To me though, here, so I, I take a very simplistic, I'm a simple person. I take a very simplistic view towards the difference, you know, the divisions between, let's call it ML ops. And if you're saying AI ops involves gen ai, that's one thing.
I think a lot of people say AI ops, and it's interchangeable with ML ops, so we gotta get that clear. Are you talking about machine learning pattern recognition kind of stuff? Or are you talking about generative AI kind of thing?
And they're, they're not the same. I think one is an igniter for the other Mm-Hmm. Right.
But they're not the same. But when I look, to me, the whole ML ops thing is just what I said. It's about pattern recognition.
It's a big data thing, right? I remember when, I think I was still writing at, uh, network World Hadoop, everybody remembers Hadoop, right? Hadoop came out of Yahoo.
And it was this idea of, my God, the data sets we're dealing with, it's one thing to put it in an Oracle or a sequel or DB two or whatever, but to get actionable intelligence to recognize the, to make to, to make that reams and reams of data useful, we've gotta be able to get our hands around big data, these big data. And then we, and we've gotta run programs that allow us to get actionable intelligence from oodles and oodles of data. To me, that was ML lops and it's still ML ops.
Mm-Hmm. And, and the fact of the matter is today, the amount of data that, whether you're a developer or a DevOps or a platform engineer or an SRE or an observability engineer, whatever you wanna call it, the amount of data that we process is so vast that it's a big data problem. Everything's a big data problem.
And, and the best solution for big data problems is ML ops. I think this issue is, the ML ops in general is kinda where DevOps was a decade ago. If you kinda look at the models themselves, you can't patch the model.
You have to pretty much replace the entire model. They don't really have a sense of what a version control system is for the model. So when you're kind of rolling out the model and you wanna roll back parts of it, that's not quite as mature as it could be either.
And so I think that the whole space could benefit from some DevOps thinking, it's just, it's a different kind of artifact. So, I don't know, mark, maybe you have some thoughts here about how does that artifact get managed differently from other software artifacts? And can I do that in a pipeline where I'm updating code, you know, a couple of times a week versus an artifact that's an AI model might not be updated every once a month, maybe.
I don't know. So I think that there's, you know, a couple things to unpack there is, I think that the ML ops practices, so the ML ops need, need to meet the DevOps. They do have a set of tests for testing these things to make sure that, that they're fair and unbiased and they're, they're accurate.
Um, and I'm, and this I just did, what Alan says people do is I just munged ML ops and AI ops into one great big puddle. But, um, some of those tests already exist. So I think you'll see things like Datadog and observability platforms like Honeycomb and others incorporate those same kind of tests.
But instead of performance based on throughput and CP usage, they're gonna be on fairness and bias. They're gonna be on accuracy. It's just automating a test against, you know, a machine service.
Um, then the other thing is there is, you know, sort of inklings of that patching and provisioning within the model, these large language models that will probably make it there. So there's something called Laura, which is the patching and provisioning, um, around those large language models, but they're not necessarily, as you men mentioned, they're not nearly as mature as like patching and provisioning, um, you know, production services. Unless you read that, um, um, you know, continuous delivery survey from earlier, then it's, it's probably right on target.
But, um, um, anyhow, I think that they, basically, what we need to do is map these sort of ML ops, AI ops into the DevOps and the operations practices that are already enterprise-wide. 'cause they're not, the context is different, but you know, the methods are not all that, um, dissimilar in how you would patch, provision, monitor, you know, do those deployments. They're just, you know, just like a new system.
They're a little different. It seems like all these artifacts at the end of the day wind up in some sort of GIT repository somewhere. So if that's where they all are and they all have to be integrated at the back end, seems to stand to reason that somewhere between the Git repository and the delivery, there needs to be a unified workflow.
Yeah, I, you know, again, I think this is a work in Progress. I, I, and I think the gen the gen AI aspect of it is gonna be, is that the ML ops is going to do the, the herding and the sorting, if you will, based upon that, going to drive some patterns, some conclusions that gen AI then builds on. And that's where a lot of the automation will come in.
A lot of the actionable intelligence will come in and a lot of, you know, real, maybe even coding comes in, right? Think of ML ops on a feedback loop, right? You get, you get your app out there, you got feedback loop, you got all these data, all this data come in, and that ML ops does its thing, AI ops or AI agenda, AI grabs that and the next iteration of your code Mark, do you think the data science teams are willing to give up a lot of this operational stuff?
Or they gonna be like the old fashioned tree huggers and they're gonna be like, Nope, it's mine. I will not give this up to you. Well, uh, I mean, the data science folks are really the rock stars in the enterprise.
Everybody's scrambling for them. So before, I feel like they were sort of the, you know, pointy headed, you know, deep tech folks in the back room, and now they're sort of the rock stars rock center enterprise. Yeah.
You, so, I mean, I think that they'll, you know, they're gonna have their, their domain knowledge is one of the most valuable assets these companies have now. So I think they'll probably, you know, help inform how this works. Um, just one point on what Alan said there is I think the, you know, the ML leaders or the ML data scientists are gonna use that to show them how to do observability around ai.
And then the gen AI is actually, so that's gonna be the monitoring and then the gen AI is gonna be the orchestration and the sort of artificially intelligent enterprise, in my opinion. Love to get your opinion on this one thing. Since you kinda, you know, you've been with us for a while now.
Did, did you ever occur to you that there were so many fiefdoms in it and that we could be arguing over so many little pieces of this thing when you, when you first started and, you know, yeah, I mean, I think you're right. I mean, it can be, it can make an analogy to a lot of different things where everybody's trying to hold onto to what's theirs. But it, it makes sense though because, um, as AI grows and machine learning has to do more, and we're, and we're constantly getting data, and obviously everybody wants, like Chachi, bt, for example, to improve, be better, be faster, um, it, it makes sense to me that that would be yet another division.
I don't know if we're gonna have a, any website, ml dot ops com. No, I, I think we, we, uh, actually we do cover a lot of ML ops over on the AI site. I am an AI builder That very purpose.
Yep. But look, it's, it's fascinating stuff. And again, it's part of this, not where we are today, but where we're going tomorrow, conversation that's gonna wrap up, I think our Textron gang for this beautiful Thursday.
Um, stay tuned. We have a lot of good stuff coming up on Textron, uh, TV today, including some follow up video and, and commentary on the announcement yesterday on, uh, Textron Group, uh, joining the Futura Group. So check that out until then, or until our next textural gang, which I guess will be Monday.
This is Alan Chennel for Text Gang, we're out. com is the number one online destination for DevOps education and community building. com covers all aspects of DevOps, including DevOps, best practices and tools, DevOps culture, DevSecOps, business impact, continuous testing, continuous delivery, and more.
com has the largest collection of original DevOps content, featuring breaking news, blog posts, podcasts, and more. com to learn more. com where the world meets DevOps.