Techstrong Gang – March 10, 2025
Alan, Mike, Mitch, Tracy Ragan and Guy Currier, chief analyst for the Visible Impact arm of The Futurum Group, dive into the degree to which machine learning operations (MLOps) and DevOps workflows need to converge before discussing how artificial intelligence (AI) agents will simplify application modernization.
Then, the gang turns its attention to the future of HashiCorp now that IBM’s $6.4 billion acquisition has been finalized.
Transcript
AIOps, ML Ops, DevOps, it's all Greek to me. You're watching Techstrong Gang. Hello everyone.
Happy Monday. It's Alan Shimmel here for Techstar Gang. Hope you've had a great weekend and you're ready to get back to work this morning.
There's a lot going on in the world. We're gonna try to just cover just three things. Just three things.
That's what we do here on Textron Gang. We just do three things every day. Um, got a great gang of, uh, cast of gang members to go over stuff with.
Let me quickly, quickly introduce you to them. First of all, the lady from New Mexico, she's the CEO of Deploy hub, open source expert extraordinaire, and one of our favorite people here at Techron World. Tracy Reagan.
Hey Tracy. How are you? Hey, Alan.
Thank you. Thank you for that. I like being a favorite person.
Well, you are. Thank you. Thank you.
Um, joining jc, he is in the streets of New York City Manhattan, that he is Futurum Chief, not Futurum, excuse me. Visible impact Chief Analyst, guy Courier. Hey guy.
I hope I got that right for you. You got it right. Thank you.
Just Wanted to clarify And it's great to be here again. You're not in New Jersey? Uh, what Exit?
What exit? That's right. I'm in.
Yeah, I'm in, I'm in, I'm staying in New Jersey, uh, with my nephew, but I'm coming into Manhattan every day. 'cause I not Near exit 13. Elizabeth Newark.
No, right by the bridge. Right by Fort Lee. Oh, okay.
You're up by the GW and the Henry Hudson. That's, you Know, we came up with congestion pricing to keep you people on that side of the bridge. But no, I love when you use You people and that's why I take the bus.
That's you people. You people. Alright, let's move over.
Take the buss over from you people. We'll stay in New York. We'll go up to Harrison.
Looking mighty Raddish pinkish today, our own life are, yeah, well I, I'm, I'm actually just back from a run, so There you go. Alright, good for you. I, I did a bike ride this morning myself.
It was cold. Well, it's all relative, but it was cold down here today. It was probably in the sixties.
I was freezing, um, moving there. I'm sure it's at least in the sixties up in, in the high mountains of Colorado. Uh, no one, no one commented on that.
It's our, uh, FU VP analyst for DevOps. Mitch Ashley. Hey, Mitch.
How are you? You're on mute. Yep.
Now you're not doing great. Always doing great. Good to see the gang.
Good to be on the gang again. All righty. All right, let's jump into it.
This fine fi this fine Monday, Mike, we, we had some text drawing AI coverage on, uh, on J Frog's. I think you were outta Jfr event in New York last week, weren't you? Yeah.
They had an event down in, uh, Rockefeller Center, and they had about 200 people show up for the launch of a jfr ML lops platform, which is based on, uh, a code, I guess, code they got from a startup that they acquired last year. And now we're productizing and it's much more integrated with their core DevOps platform. They gave out these lovely mugs here, you know, and, um, I gotta say, you know, it took me about 15 minutes to figure out how to move this thing actually works.
But what it does Is that the one that heats it up? Yeah. And it continuously stirs it.
Yes. I have one of those, Which is, um, you know, of course core to DevOps. We're continuously stirring things.
So I want to thank AFR for yet another first roll platform issue solved. I was gonna say, what are you putting in there? You need to have a continuous Well, that's my promise.
I'm not a coffee drinker. And, and so it's still sitting in the box. I've had it a while.
I think it's, So what was it you said in the, in, what was it? You said in the intro? Allen ml ops ai, AI ops, DevOps.
And we have Coffee ops, and now we have coffee ops. It's all ops, it's new ops, no ops. But what was really interesting about it is that the folks that came to this event were largely data science types, and they all work with these ML ops platform and J frog's making a case and a hard one.
Every speaker got up said, you know, if if those folks want people to use their AI models, they have to be integrated with the existing DevOps workflows, or the developers are never gonna find them. And what I was trying to puzzle out in my mind, and I'll start with Tracy on this, is, is there kind of a divide between these data science teams that are using these ML ops platforms and the rest of the DevOps teams, and each of them has like a different culture and we need to bridge that? I'm not sure it's a different culture.
Um, I think that the ML ops community have been somewhat underserved when it comes to DevOps. Um, you know, I, the reason why I love this, the reason why I totally love what's happening here is that we're finally stopping to think about ML ops and AI and the components that we use, like models and data sets. They're just components that need the same kind of management as any other kind of component.
So when we think of artifact management, we, you know, in, in Artifactory, we often think of just binaries. It's kind of what, where our brain goes, it's artifacts of binary, but artifact can be anything. So being able to start to bring in the AI components, models, data sets, as well as binaries into a central place and treat it just like any other DevOps, um, any other type of component pushed through the DevOps pipeline is going to be, um, a time saver.
And it's gonna offer a lot of clarity to those data scientists who may not have had that kind of products in the past. Now, I believe, I understand we have things like TensorFlow that help them build, uh, these models. Uh, but when it comes to all the other pieces of the DevOps pipeline, the ML ops teams have not had the luxury of, of these kinds of tools.
So imagine how hard it is to try to manage just a deployment of, of one of those without a DevOps engine. I, as a DevOps person, can't imagine doing it. So, you know, I, I saw last year, I think is when, um, JFR bought quack.
It's probably, it's been almost a year now. So, uh, they've taken some time to really, it looks like, to me, to kind of sort out how to integrate the, these, you know, the ML ops components into their process. Uh, but it, it's time.
Um, you know, I don't know if we're we're too late on the ML ops question because I know people are still doing it, but it doesn't feel like it's as, as popular as it once was. But for the data scientists, this is what they need. So yay jfr, they're, they're actually servicing that community from a DevOps perspective because it's the same, the problems are all the same.
It's just a different component. You know, the mike, there are differences in how the teams work, and I think that's great to see jfr taking that on through their acquisition of Quack. Um, you know, software has its own iterative process as, uh, ML and ML Ops also has its own kind of development workflow, which isn't exactly the way software is created.
Usually in, in machine learning type of applications. You have a, you have a data engineer, a data analyst, you'll have a developer, usually a domain expert that's helping you. And you iterate on the model.
You iterate on the format and the, the structure of the data that the model uses and the algorithms use. And you go through this iterative process where you create what they call features. This is like, okay, this is what it can answer for this kind of a question or this kind of analysis or this type of data that it's gonna analyze and re produce some predictable results.
That iterative process, you know, where is it released at? It's sort of kind of, when is the software ready? Same thing happens in ML ops.
When is, when is the model ready? And eventually those two things, uh, have to join the, the kind of traditional software and the machine learning language algorithms and, uh, and models. So it's good to see Jfr take that on.
I don't think it's just a matter of let's put your, our stuff in our, in our artifacts. I think it's also the workflow. So I'm curious to see how this is gonna be adopted.
And I, you know, I wish, uh, jfr the, the best at this. 'cause I think it's important for us to figure this out so we don't have this kind of chocolate peanut butter impedance mismatch between the two approaches to developing what we're creating. Yeah.
And I think that the model training is where the, that, you know, pulling the data sets and training the models and then, and storing them is where the ML ops, uh, workflow is the most important. Um, but centralizing that into a, a, a kind of a, a central platform, um, will make things easier in the long run. Just make it part of the DevOps workflow is a Win Right There.
Or vice versa, you know, DevOps part of the ML workflow. I actually think also the, uh, experiment tracking and, um, hyper parameter management, these are really important elements of what the data scientist does. Um, and, uh, having, you know, you know, a agile and agile workflow, um, for that sort of thing, um, is, uh, is, is really helpful as well.
I like the bridge here. Like everyone's noted, the bridge out to the data scientists and the data scientist's particular types of work that really differ significantly from the coder and yet still bringing them into this, uh, DevOps like paradigm. Hmm.
Hey, Allen, um, you know, we saw an outfit called, uh, a couple of weeks back. DataRobot bought some distributed computing platform startup. And I wonder if we're about to see some major convergence here.
Will all the DevOps companies kind of go after ML ops companies and will the ML ops people start acquiring DevOps companies? And, you know, are, are, are these two trains gonna coll? I don't know if they're gonna collide, but, you know, I sometimes things seems, things seem too forced, too forced.
I get why you would want the ML ops to help in developing, deploying AI apps, training LLMs. Not everything has to be part of my DevOps workflow. And I just, you know, I, I remember when they bought Quack.
I was at, um, swamp Up. I think I had a chance to meet the founder, one of the co-founders of Quack. Actually.
I interviewed, you know, I I I, I smell what they're cooking. I just don't know if we're eating it or if it's, if it's a necess, if it's on my food pyramid, I would argue that this conversation we've been having about platform engineering for a while will force this issue and that people are gonna start centralizing the management of application development. And they will naturally view those AI models as an extension of that conversation.
So I think it may happen. Well, to Alan's point, if we look at, uh, DBAs, DBAs have never embraced the DevOps pipeline, right? They have their own process and they've never, ever really, um, decided that that was a good idea.
DevOps, Well, there is this kind of, there is this kind of tiering, so to, I mean, it literally, it's called tiering of applications, the old monolithic model. And, and, and the data and the data services, um, are, and can be seen as a sort of a separate layer or tier. But I, Alan, I don't think, and Tracy, I guess I don't, I think, you know, I'm a fan of saying there's no such thing as an AI application.
What, what, there are AI services that get exposed or injected into other applications. And as such, AI has become just so pervasive that what I would think the problem, uh, uh, J Rog is solving for is all the developers using DevOps and wanting to do more and more of it now need to incorporate ai. Um, and those AI services, if they're being tuned, developed, tuned or, or, you know, rag based or whatever it is, there's a data scientist involved.
And that's, I think, a little bit more of a, of an opportunity. Let's not call it a problem, it's an opportunity. Um, compared to, uh, what I, I completely agree with Tracy's, you know, statement about how the DBAs have never really wedded with Dev DevOps very well, but I think this is, this is different because of how infused and integrated, um, AI is in every application.
It's going the other direction, right? It's not being pushed out from ai, it's being pulled in from the development. Exactly.
Well, this is a unique characteristic that you're pushing not just algorithms, machine learning algorithms, you're pushing data with it, right? The model includes data. So it, it is kinda incongruent with what we think about a normal DevOps up, uh, workflow of pushing software, right?
Usually not pushing a lot of data through the process, which is also, to your point, Tracy, about why data and data database engineers, analysts ha, haven't been kind of part of that DevOps workflow, right? It has its own flow, it's own process. And I think that's the key to this is Alan, it's not just about does jfr bolt on a AI or ML ops into their products?
That is not gonna solve the problem. You're not gonna attract people, you know, it's like saying, I have open APIs. As long as you use my APIs, they're open.
Right? No, it is. It's like you have to adapt to the workflow and, and intersect those workflows in the way that it makes sense.
I don't think we know enough about that yet, or, or have experimented enough to really truly know what the right approach is. So hopefully we have some folks that, uh, make some progress in that area. Well, I hope that we continue just thinking about parts or parts, right?
And obviously different parts have different requirements around them, and there may be different workflows for different parts, but it's still a component. It still has to do a vulnerable, we still have to think about how to add testing and vulnerability scanning. It's a part that has to go through the software factory floor and the DevOps engine is the best place to do that.
And these are developers, even though we have new terms like data, data scientists, they're still developers and they're still part of the development community. And to embrace them and provide them tools that allow them to support the DevOps pipeline is the direction we should go with this. Because we all know it helps things move faster and we always want to go faster.
Yeah. I would say, you know, we talked about this in a previous show, but the DVAs are gonna get rolled up theoretically into this platform engineering motion as well. So, you know, maybe we're coming for the data scientists, the DBAs, and they're little dogs too.
I dunno. Well, when they come for the data scientists, we didn't say anything. That's a different thing.
Um, but, but let me just tell you that the, there one more chip here that Jfr has in their pocket to play, and that is they've announced a, a partnership with NVIDIA and this ML ops platform and Flow is supposed to be integrated into the, uh, NVIDIA of dawn. What's the NVIDIA software? NI's NIM is the framework.
Nim, I actually learned what it stands for. It's Nvidia inference microservices. Nim, who knew?
There you go. Yeah. It's a, it's a tool set for, for a deploying AI into containerized environments.
Uh, yeah. And, and hugging face also, Alan, that's, that's really significant. Hugging face is a quasi standard now, uh, yes.
For model development and, uh, um, benchmarking of systems, um, for ML and, and, and ai. Yeah. And it's just like going out and pulling a package down, an open source package.
We're pulling down an open source LLM, treating it like a component and then starting to track the changes in it, right? Right. This, it's, it's basic to what we've always done.
Agreed not, not to be left out, but they brought in Databricks and they got an outfit called Bowl Plan, which makes some sort of serverless data lake. So they got it. And Three maker AW Ws part of their JF frauds, doing their, you know, we, we spoke yesterday about playing checkers versus three dimensional chess.
Jfr definitely is playing three dimensional chess in, in this market with that. Right? And you look at, you know, who their traditional competitors are in the DevOps DevSecOps platform.
You look at GitHub, GitLab cloud based harness, and you see, you know, well Harness is, is making some moves along in this space as well. I'm not sure if the others are yet. But anyway, I'll leave that to the analyst to, to comment on.
I'm just, I'm just, what? I don't know what I am. But let's take a break here on Techron gang.
We'll come back and we'll talk about our next block. 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 the gang's gonna talk about this new AI agentic offering that goes on top of a platform called Open Rewrite that was created by Modern. And what they've done is made it more accessible to a broader number of folks. 'cause it's at the core of a lot of the application modernization efforts that people have.
A KAI am gonna upgrade from Java, single digit number, pick your favorite double digit number, and you can use this tool to automate a lot of that workflow. It doesn't do it all entirely, but it might take something that might have taken you, I don't know, a year and a half to cut it down to maybe six months. And now they're putting some AI agents in front of that.
Um, Mitch, I guess, you know, when I looked at this, I was wondering if the cost of switching from different platforms is about to drop and maybe people won't be as locked in as they used to be because it won't take as much time to migrate. Well think about migration in a couple ways, or modernization in a couple ways. One is, to your point about upgrading versions of Java, right?
Some of those changes are no, no small attempt. I mean, it's, it's a big effort to go between different versions of say, you know, between Python two and three, it was a big deal, right? Things are different in those languages.
So it takes more than just syntax changes and new features that are in the language when we talk about converting COBOL to something else, right? To, uh, Python or c or or whatever it might be. Now you're talking about architecturally some really big differences between how that application and all of its different programs code were put together and how you would build that, whether it's in a monolith or semi monolith or more microservice oriented.
So we're, we're talking about, you know, baby steps here. We're not throwing COBOL systems at it and said, great, it's all done. We're all good.
But I think to the point is, they've taken what they've created so far and now put this into this lossless tree structure, um, that has kind of more semantic richness about understanding the interdependencies between code and analyzing different code bases. I'm not sure all the things that it does. Sounds pretty interesting.
I'd like to learn more about it. But this is something that they have also open sourced, um, as well as built into their product. I think the important thing, really interesting thing is the agent part of it is sending that off to do specific tasks.
That task around analyzing multiple code bases, doing some rewrites, finding issues that can be addressed. And again, this is a stair step process of maturity of what it can do. Ally versus guided versus it still takes a human.
Mm-hmm. It takes us, go ahead. It takes us back to that conversation of mono versus poly repos and the problems that they do create.
But, and you're, when you're in a decoupled architecture in particular, microservices, we talked, we used that word the last, last block. We know that we are, when one application is going to be, uh, an aggregation of, of several repos, it's not just one application is not, does not have one repo. So tools like this makes it a lot easier to say, I need to aggregate, I need to scan all of these because this is one application, right?
And this isn't just a problem here. It's a problem in, in other ways as well. So I, I think taking on that poly repo problem, um, for doing this, for doing rewrites and, um, you know, updating your code is a super useful thing to use.
I I will tell you, they were a little miff because all these companies are out there claiming that they have, uh, upgraded something using AI tools. And they were like, the truth of the matter is, yeah, they pointed their AI tool, but they used our repository to do it and all. So most of the work was done on the repository side from them and not by the AI agent, according to them at least.
And they feel like, um, some folks are taking too much credit for things that their open source platform actually does. I have a hard time believing that because tell me what, what code base, what repository, especially when it's been around for a long time, is that organized? That cleaned up that easy to, to work with?
Those things tend to, they're like wiring closets, you know, for your network and your office. So as you close the door, it's a mess the next time you open it. Um, so, so I, I wouldn't put as much stock into that.
Maybe they're take getting some advantages of course, of what's there, but there's a lot of work to go from point A to point B on this. I, I don't know. I want, I kind of wanna challenge you on this, Mitch, 'cause I kind of feel like that's one of these things that generative AI does so well is masses of seemingly disorganized data and information and, um, I mean, it's not a pattern detection tool.
Exactly. Um, but, uh, through that iterative, you know, training process, it, it, it finds plausible further strings of data based on input strings of data. And, and this is far beyond what, you know, uh, what the human mind right now can, can do.
So like, isn't it sort of like, uh, I don't know, a new weapon to, to deploy against what everybody has put together in a disorganized fashion and therefore can't use, uh, in the same way It's kind of the, there's a pony in there syndrome, right? Like, what does this, all this stuff do? And if I'm gonna modernize it or migrate it or replatform it, whatever it is, you know, what do I have and what do I need to modernize?
What can I leave behind? I don't wanna leave things behind that need to be there. So generative ai, and there's a lot of different products that are doing this now are really good or getting better, let's put it that way, at analyzing code bases and first telling you functionally what the requirements or what this software does.
Second is the architecture of it, describing of it, how it, it is organized or disorganized to whatever degree it is. So then you can make some decisions that human can about, well then how am I gonna re-architect this? How do I move forward with this?
And maybe I use AI to do some of the development with it. Maybe I don't. But to your point, guy, it's an extremely useful tool.
I think it's gonna be even more useful over time as it gets better and better. Let me give you a use case that we talked about. 'cause and this will become readily apparent to all of you, I think.
So vendor A decides that it wants to raise licensing fees for its platforms. We've seen a lot of that lately. Um, and they pick a, a price point for that hike that's just kind of right below the cost of moving off that platform.
So people suck it up, but imagine it didn't cost as much to move off that platform. And then maybe vendor a that rose prices miscalculated and more people will migrate away to something else, which we've seen a lot of people trying to at least experiment with. So is there any specific vendor you have in mind there, Mike?
This is like the, all the characters in this are fictional and don't, if they may resemble some real, We, we changed the names to protect the guilty Boy. A little transparent there. Mike.
Uh, Hi, Joe. Friday here. We, we have, we have always done this.
I mean, you know, we're, we're talking about this like, it's a new brand new tool, but come on. We've had COBOL to CC to Java. We've done this for a long, quite a long time.
We've had these converters. Uh, you know, maybe AI makes it better. Um, I'm hoping it does because I've used some of those conversion tools you go from see to Java and there's a lot of, it gives you a baseline, but there's a lot of work yet to do.
So I'm hoping that it does a better job of what we used to have in the past. I hope so. I, I, well, Yeah.
You know, from a VC point of view, right? That typical VC looking at how it looks at the world, there's a big opportunity, there's a big market, right? There's a lot of legacy applications that are gonna have to be converted to a cloud native architecture over the next three years, five years.
You know, they, I I was reading and think 85% of greenfield new applications will maybe even more will be cloud native architected from, from scratch. But you've literally got millions and billions of existing applications that need to be converted that need to be modernized, is the word. And, uh, Uh, but, but to Tracy's point, the way it's been done historically has been, you know, people went out and they hired some global SI to come in and they said they would do this project for them, and then the bus shows up and about 30 kids roll off and they move in for a year and a half, and then they never actually finished the gig.
So I'm hoping that this gets better to enable what you just described. But, But you know, uh, I think a better analogy is moving from private data center to cloud, right? What'd we see?
That first wave was just lift and shift, right? And, and it's only now 20 years later, 15 years, 20 years later, that we're seeing real cloud migration that maybe even not some of it's cloud native, but even the ones that are not cloud native, really taking advantage of a cloud architecture versus just lift and shift off the on-prem data center or the closet. Well, we're li we're living this in another kind of parallel universe, and that's not called modernization, but it's called development using AI tools.
7, you know, it, it we're, we're in an era now where we're interactively saying analyze the code. Doesn't have to be COBOL from 30 years ago or 40 years ago. It's my code I just wrote or I picked up in this new job or part of a code I haven't worked with before.
Maybe I know it really well. But we have AI now analyzing existing code ba code bases and making changes to it, recommending changes, genetically making changes in some cases with, uh, with Claude code. So it's, you know, it's on a spectrum now.
It isn't just moving the old stuff to something new. It's taking what we have and using AI to continue to develop it. I think we need Mel Gibson from Braveheart just screaming freedom, and then everybody will, uh, get going.
Yeah, it didn't end well For him. I think we got enough people doing that in the country. Mike, take it easy.
But, you know, Aaron's, I think the, the taking the monolithic and breaking it up into, to decoupled components and features is probably the biggest challenge companies have, and these kinds of tools can do that better. At least get, again, like I said, it's not perfect, it's a baseline, but to be able to break it up is really, can be really challenging. And so if we're using AI to make, you know, you know, modernizing our monolithic into decouple architecture that we can take advantage of cloud native, all the cloud native features we've been talking about for the last, I don't know, seven, eight years, um, it's probably about time we have a tool like this, and that will help a lot of companies move into that direction.
Fair enough. Here's what I find interesting. So you described earlier, Tracy, you know, the, the sort of the old way, the old way up until last year still going on now, which is, which is, you know, like originally just all this manual lay we're talking 30 years ago or whatever, and only for those applications where you, you really needed to do some kind of translation and experience and logging and then starting to post these things.
Here's how you do it. And then, then automated tools, like you say, started to appear. These were not AI based and all this work has gone in and it's such that we now have an open source community.
com, how to glue this to that, right? This is now like how to move from this code base to that code base. And then here comes modern and says, Hey, thanks for all the work.
We just trained an AI on this and you can pay to do all of this so much faster. You know, that's the story that sort of popped out at me is, uh, you know, thanks, thanks for all the work over the decades, guys. We got, we, we now have an AI trained to do it.
But isn't isn't That the AI way? That is the AI way. And, and I completely agree about the usefulness of this.
It's wonderful. It's terrific. Um, it's an interesting example of something, uh, uh, that's not me by the way.
I, I, I have the horns. Someone else has No, no. Mitchell has the dog sound effects.
Um, You know, so, so something you were sort of talking about, Alan, uh, uh, we've been talking about a little bit is, is open source under threat? Mm-hmm. It's an under threat because now we have all of this community work over decades and all these different areas, and we can, we, you know, AI is trained and then we're gonna put more human data in, and then maybe we're gonna start using, we use synthetic data already.
And at what point does it become this recursive circle that's draining itself and going off, I dunno, the edge of the world, Isn't there A tipping point guy is, is we, we generate so much more code using AI or, or modify it at some point. You have to have AI to be able to manage it. You know, we have so much code.
You can't hire humans to do all the work on it. You have to be able to kinda reest it, modify it, change it, whatever it is. So we're kind of creating this world where it is inevitable that you have to have ai if you're gonna be generating this much, this amount of code this fast, I think you can.
I think so. If you ever saw the bill from a global SI on one of these projects, you will lose your sympathy quickly. Oh, for sure.
Yeah. I was in one of those buses that pulled up Outside early in my career. Yep.
All right. Let's take a break here on the gang. We're gonna come back and discuss C block.
You know, HashiCorp part of IBM? Is it a kinder, gentler Hashi? You're watching?
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.
Hey folks, we're back. And as Alan alluded to, yes, Hashi Corp is now finally formally part of IBMI think it operates semi-independently, but the issue becomes, well, where does Hashi Corp fit in with the rest of IBM, including Red Hat and Apio? And they have some ambitions in that space, but Guy, you've been following this for a little while, talked to a lot of the folks at Hashi Corp over the years.
What's your take on all of this? Where do you think it all winds up? Well, I think it, what what's really interesting here is, um, so IBM right, uh, original gangster of, uh, of, uh, um, you know, computer systems that transformed itself through, um, software delivery to now, um, essentially a, a a A services, uh, firm for building, um, and deploying and acquiring and managing enterprise software and other types of software.
Um, where, you know, the acquisition of Red Hat seemed to start this latest phase of, um, enabling organizations, uh, owning and running off the shelf, as well as building and deploying their own applications on various platforms, puts IPM in a pretty strong position, both in the public and the private sector. So where does HashiCorp fit into this? I mean, most famous product, Terraform infrastructures code, um, ways to, uh, tighten the integration and responsiveness back and forth between the, um, the, the code, the software where they're off the shelf or developed, um, and the infrastructure.
Um, I don't think it necessarily means we're bringing Terraform Disease systems or anything like that. Sys is being the big mainframes that IBM has, but maybe it does. Maybe it does.
And this sort of general enablement of IBM in the enterprise and in the public sector, which the two big areas where IBM plays of DevOps, um, has been, I think, you know, uh, a maybe surprising force of good in the industry. Um, red Hat remains independent. You can expect HashiCorp itself to remain independent, Apptio's remain independent, you know, as brands with their own go to market, their own user base and so forth.
While the main line IBM, uh, uh, uh, you know, product lines or service lines really get to incorporate and use and influence development of all of these, they all have a part to play in application development, um, uh, production and, you know, delivery to user basis for the business or the agency goal. Uh, the only other thing I'd add, um, is that, um, uh, you know, uh, Hashi Corp in particular has a really robust set of tools around automating and running and maintaining service health of all kinds of infrastructure. And that helps broaden IBM's ability to also be an additional player as opposed to a single source.
They've had this sort of single source model forever. They take on the entire application. And by the way, when you talk about off the shelf enterprise applications, every off the shelf enterprise application has all kinds of, you know, customized and own code in the enterprise or in the institution, um, that adapts that enterprise software to the particular needs and uses of the organization.
There's lots for IBM to do there, even if they are, you know, secondary vendor or secondary player to begin with. Mm-hmm. So, Mitch, go ahead.
I'm sorry. Hold On, Mitch. They were describing it somewhat like this where Terraform is kind of like day zero and Ansible is day two management of the environment, and those will be those different automations.
And I'm not quite clear if that makes sense or how much overlap there is between Terraform and Ansible as we kind of go forward. And frankly, in the age of ai, I am wondering, you know, are those just all gonna wind up being backend services that some AI agent is gonna deliver and they all just kind of fade away in the background? I think of it as just platforms that are automated, right?
Processes for provisioning, updating configurations, configuration management of that. You have to remember, you have a huge embedded base of Terraform users, open source and HashiCorp, um, and uh, so open to tofu kind of folks. Um, but of course also Ansible, you know, it's been one of their early earliest, um, that and Chef, um, been around a long time.
So it Puppet and Puppet. Yes. Thanks.
Exactly. So I, I don't, I don't think you can say this is day zero and this is day one, and this is day two. People use these tools across the, both the operational and development life cycles.
They use 'em to create development environments. They use 'em to create test environments. They use 'em in production.
So you know what the blending of all that will look like. Maybe they stay somewhat separate since they're in business, different business units, maybe they all benefit from Watson ai that becomes a feature, a part of these technologies as part of the AI strategies take place. But we'll see.
Can I be a bit of a jerk, Mitch, and say that, uh, Ansible is the, is the, you know, Linux cloud native, ERL sort of, uh, you know, religion quote unquote, whereas Terraform is a lot more the enterprise religion Enterprise. Uh, we use both. I mean, one of, there's to me, they're completely separate tools.
Yeah. You know, I see as overlap a configuration. Yeah.
The Ansible is, you know, that's what, that is a full on DevOps tool. Terraform is a platform engineering tool, you know, that's a good Way of, of looking at it. Yeah.
And I, I get using both because you have to go and stand up an environment before you can deploy to it. But guys, I I wanna take off the rose colored glasses here for a second. If you think Red Hat Apptio name other IBM acquisitions exist as quasi independent companies and have not been assimilated into Big Blue, I've got a bridge for you guy.
There's one right out the window there. Okay. Red.
This ain't, this ain't, this ain't Red Hat pre IBM, But well, no, no, I, I referred to the brands remaining independent. Yeah. Sales teams, independent marketing teams, they're allowed to go and continues to develop their own Customers.
Yeah. Because it goes to the heart of what is IBM today, right? They spun off NDL right then, but IBM itself still remains a, a consulting firm.
And now, and, and they always prided themselves on being able to, and NDL still does we'll, we'll help you deploy whatever the right tool for your job is, but now they have some favorite tools. They have Red Hat, they've got Apptio now they've got Hashi. And so the IBM consulting team, you know, those are their favorite tools.
I'm going assume the, the underlying the, the, the brands Red Hat, and I assume it'll be Hashi and, and Aptio, you know, they're still selling those products. But in a perfect IBM world, those products are wrapped around some sort of version of the IBM Cloud, some sort of version of, of Watson X or Granite or whatever the IBM AI's gonna be. But it's all wrapped around IBM services.
Right? Because that's still the mothership here. And It Yeah, go ahead.
It, it buttresses, it not buttresses, it supports greatly the IBM services offering. But you use the word consulting. RY is the consulting arm that got spun off.
Yes. I, I think of IBM when I said services. Well, ND is Global services That that's, that's not entirely correct.
NDL is a services company that does manage services in a lot of maintenance work, but Ken Builds the old B Global Services built within IBM and that's still a huge, huge Driver. That's right. Okay.
Yeah. Now Hasi, let's remember how Hasi got into this mess, Right? And, and look, Mitchell Hashimoto did an amazing job with Hashi and he started that company, I think he was 18 years old and he built, there are two or three Terraform is probably in and of itself a multi-billion dollar pla uh, project, uh, you know, product.
And then don't forget, vault and Secrets Management and all that good stuff is, is big. And there's a third and I'm not remembering it right now. Or a service match console.
Yes. And you know, they changed their open source licensing and there was a big pushback in the community, right. That was quite a, quite a row over at C**n, uh, two years ago or whatever it was.
4 billion. If you know a billionaire. A billionaire, that's a big deal.
4, it's a great pickup. They've got three great products. I think the issue is gonna be how well they integrate into Red Hat, how well IBM services wraps around these things.
How well they work with Ansible or, or in the finops or the rest of the I-B-M-I-B-M security. IBM security's still a major player in the game, right? Man, they got Vault to play with, you know, to, to lead with.
Now that's gonna be a big tip of the spear for them as well. So I think overall, this, this, I always thought this was a great deal for IBM. It was a great outcome for Mitchell.
I think Hashi could have gone on to do Hashi Corp could have gone on to do bigger and better things, perhaps independent. It'll, I think we will have to see how the big bluing of, has she corp. You know, talk to me in two or three years if you have brain drain, if you have continued development of product, if you have continued integration that that's Well if you My take, yeah.
If you want me to be equally pessimistic about, well you're not really being pessimistic. No, I'm not less, less rosy about it. Um, I do think you have a point because IBM acquires these companies and they start to turn more towards details.
Right. Really important and helpful and valuable details as opposed to pushing envelopes or, or, or innovation. And that is not, that's just a different business model, uh, and a necessary one.
And I really, I want to emphasize that. Um, I don't think that's a bad thing. I don't think standing up will.
It's be doing, It's IBM incredible what new things no one has done before is as is as much as it's, Hey, there's reason they're around guy. There's a reason they're around a hundred plus years, right? This is what they do now is Red Hat the daring darling of, of the Linux open source world that it was seven years ago?
Probably not. So, so I have a question for Mitch. Will IBM Open Source Terraform under some sort of consortium play and, and, and, and maybe much the way that Red Hat has been adding more things to the consortium later, and then will that bring open Tofu and Terraform back together?
Or is Open Tofu off on its own and maybe we will gain momentum because, you know, there's a lot of folks out there that aren't in love with IBM and Red Hat. I don't think Open Tofu is going anywhere. No, I think it's Gonna stay right there.
It's cfcf. Yeah. And they're not gonna, they're not gonna open source bring, uh, bring, uh, sorry.
They're not gonna open source their, any of their products. They're gonna leave 'em as is what I'm saying about Mike. Wait, wait, wait, wait.
Mitch, let, let's, I, you know, there's, there's, there's, what's the word I'm looking here? There's nuances here. Yes, there is is An open Source version of Terraform.
Terraform was open source. They just, they changed the license a little bit, but why Would, why would they go back and Open? I don't think they, I don't, they'll go back to an OSI license.
I mean, you step back and look at all the things we're talking about, whether it's Red Hat or Ansible or Terraform Vault, all of these things have been around for a while. At least 10 years if not more. When you go back to, to Red Hat.
And so what is IBM acquiring? Yes, they're acquiring product companies. No, they're acquiring customer bases that use all these products, right.
That they can serve. Right. They're not buying it just to sell a lot more product.
They're buying it. 'cause they're getting massive customer bases from this. It's huge.
Ansible's been around for a long time. There are a lot of people that use it. Same for, for, uh, Terraform.
So I, you know, you talk about the consulting services in, in the kind of what got spun off with ndl. IBM is still an operations infrastructure process kind of company. That's what they serve really well.
That's what their bread and butter has been for a long time since they've shifted out of just doing mainframes. You can argue mainframes were infrastructure too. So, Well, don't don't that Application management, I just wanna put No, no, that's, but that's part of it.
It's not, we're not talking about IBM's buying cursor. You know, we're talking about IBM buying staples that have been out in the industry for a while because That's, they got, they got got some red letter brands here with Hashi. They got 3 billion.
They're Great companies. I'm not disparaging them am all, I'm just saying they're not on the bleeding edge of acquisitions, let's be Frank. No, but, and also to the point on the open source.
Hey, red Hat changed Rails license too. And a lot of people push back. Oh yeah, yeah.
But they're still around. They're still around. I, so no, I do not see IBM going back on the licensing change.
I think Open Tofu is doing just fine under CNCF and, and whatever your cup of tea is, your cup of tea is. But Mitch, and as we've all been, yeah, we've been saying that this has been, so these tools are pretty, I don't wanna don't wanna call 'em old, but respectively they are, they are old, They're stable, mature tools. They're Mature.
And many of, many of their competitors we don't even talk about anymore. You know, puppet and Chef. Those tools have, you know, they're slowly being replaced by other tools.
And I, I think what we should be looking at is if IBM has, you know, Terraform and Ansible together and some of these other tools, isn't this a way for them to start looking at how to put some money behind this space in terms of ai, right. They, they basically own. Now the, there aren't too many other tools that we've talked about in this space.
Terraform and Open Tofu kind of are it, I mean, Lummi has something out, some stuff out there. Cross Plane got a lot of attention for, uh, quite some time. I don't see those very, very often anymore.
Um, I see Terraform and Open Tofu being the two that are, uh, most competitive with each other. So, uh, I think that there's a bigger play that we're, we're, we may not be seeing, um, that IBM sees. And how do we disrupt both this configuration management and IAC, uh, these platforms?
And Don't, To your point, Tracy, I think we, the reason why we talk about Ansible is 'cause Red Hat bottom, otherwise we Were talk about way because Right. If it was progress or who bought Puppet, the people in Minneapolis, uh, Um, The testing company Perforce Or, or Right. And you, you see where those are.
But let me just add one other thing. And why bullish on IBM, they do have the ai don't, don't underestimate the work they've done with Watson all these years. That's What I'm saying.
Yep. And don't underestimate what they've come, you know, there's this granite thing actually, if UR is the Ryan Shroud over its signal, 65 Labs has done some work on, uh, on uh, granite. I think the report is available.
We're gonna feature, I I interviewed Ryan on Tech Drunk tv. I think it's out today. It's a great paper.
Definitely check It out. Don't, don't discount their quantum work too, which Is and their qua, right. Quantum's a whole look all of a sudden, guys.
I don't know. No, That's, that's a, that's a, that's a service to expose. Just like, you know, talking about Ai that's, but the last two, three weeks we're seeing, we're seeing quantum sneakingly becoming real before our eyes.
I actually, can I give you That's, that's why I mention it. Yeah, exactly. Can I, can I give you a nice word for old just so you have it in the future?
It's called venerable, as in mainframes are venerable. So then, you know, You don't have to Well, thank you from the Dean of Harrison. That's your word for today, folks.
You college or something. You get that venerable. And I want everybody to acknowledge that Alan has said that we might be on the, you know, that quantum might be here sooner than 10 to 15 years, which was another conversation we had.
And I was like, but we might be here. No. So now I'm seeing maybe 2028.
I, I actually copied a offer of LinkedIn. Someone posted a quantum ecosystem with all the logos for it. I, I'm thinking instead.
So yeah, this is not a quantum discussion, but Tracy, I think it's next year. I don't think it's 28. I think it's next year.
com, something like that. Not It's time. It's time.
Just gimme an Yeah, we're good to go. Just going back to this conversation, I wanna point out that any of these, uh, tools that are infrastructures, code, um, what other kinds of tool, even Ansible, GI Ops, they are in a position to be disrupted at this point with ai, all of these tools. So we should be looking at what that disruption looks like.
We should look, be looking forward, uh, and looking forward to it because it is time. And, and, and this is the case for, you know, helm charts, uh, the Docker files, uh, Jenkins workflow files, all of these types of scripts that we've been relying On. All vulner, not vulnerable.
Vulnerable. They are vulnerable for disruption and the disruptions needed. It's time Here, here We check out cloud code if you wanna talk about disruption.
I think that's All there guys. I gotta reign this in. What a great discussion.
Tracy. I think you're dead on, by the way, that might have been one of the best closings we've ever had on Techstrong deck. Mike, would you say that was venerable?
I, I would say you're venerable, so there you go. I'm Venerable. Yeah.
Age, like fine wide. Alright. I think We All are.
Hey, we've Got she vulnerable. I feel vulnerable. Vulnerable Mitchell.
And I wanted to do a commercial like that when we did still secure. It was supposed to be like, are you feeling vulnerable? Have you been intruded upon?
Um, come to Still secure anyway. Yep. Yes.
Um, okay. I lost my train, but hey, we've got Techstrong TV coming up after this. Stay tuned for the rest of our day's programming.
Tracy, Mitch, guy Mike, thanks for joining in. Thank you for watching Ms. Allen.
Sch, we're out.