Techstrong Gang – February 22, 2024

Hey everyone. I'm Alan Shimmel. He's Mike Baard, and you are watching The Textron Gang.

We're gonna be joined today by Mitchell Ashley and Sharon Florentina. We're gonna be discussing AppSec Dagger, Docker, and more. Don't go anywhere.

Welcome back everyone. Thanks for joining us here on Textron Gang. As I mentioned, uh, in additional Mike Ard here with me on our Boca headquarters.

com and Security Boulevard. Hi Sharon. Hi Mitchell.

Welcome. Hey guys. Thanks for having us.

Good To see you all. It, it's our pleasure. It's good to have you on.

Uh, we, we've got a lot of stuff to go over today, so let's jump right into it. Mike, you wanna kick it off? All right.

I want to talk about everybody's favorite redheaded stepchild, application security. I guess the, it's amazing to me is that we are seeing report after report lately coming out. We're talking about what is the state of application security, and it's kind of abysmal.

For example, Veracode put out a report saying that 42% of apps that they scanned had some sort of security flaw that had not been addressed for more than a year. And nearly as many also rated that security flaw was pretty serious. And there was something that, um, could be exploited in ways that, uh, nobody really wants to talk about or admit.

We have been talking about the need to secure our software supply chains ever since Log four J came around and the federal government issued a Biden and Executive order, and you would think maybe we were making progress. I don't know, Mitch, I'm gonna ask you, is it that we are discovering more vulnerabilities or that they already exist and we just started looking for 'em more? I think we're just writing more software.

I mean, we've always had security vulnerabilities and, you know, veracode's done this report year after year. I can't remember how, how many years that they've done this. 'cause they anonymized data from their service.

And so it's a pretty reliable measure, I think, of what's happening. The, the, the downside of it is, it's not just we're building in security problems or vulnerabilities into our software. It's also we don't have the time to fix 'em.

Or, or some of those, some of those vulnerabilities, quote unquote, are not really, uh, significant enough to necessarily address, they may be, uh, remediated through other practices itself. A and I know this from back in the vulnerability management days, you can sure, you can produce a long list of vulnerabilities of which a, a subset of 'em are the ones that you really have to fix. I actually think, uh, to our a Ai AI discussions we've had, there we go.

I got a IN in the first couple of minutes. This is a great area to, I'd love to see some LLMs and AI really specialize on, here's my code, here's the problem, suggest a fix to it. Make my job easy so I can fix those vulnerabilities.

Or is it something I need to worry about and help start cracking down on some of that. So anyway, lots of vulnerabilities. Doesn't mean lots of vulnerabilities in the same way.

Yep. Well, And let, let me jump in here real quick because another issue that tends to come up with the, with the AppSec discussion is prioritization. And that's kind of a bland term for sure.

You might have found hundreds of AppSec vulnerabilities, but are they really going to impact the, the overall security of your app, of your company, of anything going on? Like, how severe is the vulnerability? You might have a ton of alert noise going on, but maybe there's one out of 10 that you really need to get on and fix immediately, because that impacts your bottom line, for instance.

So, you know, are we talking about high priority, high risk, high impact vulnerabilities? Are we talking about nuisance, nuisance things that you could maybe push off to the next cycle? So I, first of all, uh, this, this Veracode, I know you did a great article.

com. I actually have an interview with Chris Ang, chief Research Officer friend of Mitchell and I for 20 years on this as well. And, and you're right, Mitchell Veracode's been doing this report a long time.

I have a bunch of comments and opinions on this. No surprise, first of all, is software more vulnerable now than it was before? And that's why we have all these vulnerabilities.

Hell no software. I'm gonna tell you, software is better today than it was 10, 20, 25 years ago. Right?

And it, and for the most part, it is scanned and checked much more than it was 20 to 25 years ago. Um, that being said, when we look at vulnerabilities though, and this was always, you know, vulnerabilities used to be a form of, uh, of employment security. 'cause if you were the guy fixing the vulnerability, it's like you're the man who paints the Veno Bridge.

And my friends in New York and Staten Island know this, right? They start painting the Veno Bridge, uh, right after New Year's and then right before Christmas, they finish, they take off that week between Christmas and New Years, and then they start again. And that's what vulnerability remediation used to be about.

But we do have things like AI now that are spotting vulnerabilities, right? In your IDE, right? In your GI ups, right?

As code is being, uh, committed, we are doing more scans, pre-deployment, as well as post-deployment when we, but overall, we're doing more scans. Totally. And so as a result, we find more vulnerabilities, right?

When you, when you look at things, you're gonna find things when you don't just sweep stuff under the rug. 'cause you're in a rush. You don't necessarily know they're there till they come bite you in the butt.

When we look at the world of vulnerabilities, though, yes, there's criticality issues of vulnerabilities and major minor and all that. The other thing is though, and I learned this from my friend Giddy Cohen, um, is it reachable? Is it exploitable?

Right? A lot of vulnerabilities. If you're gonna tell me, you know, this vulnerability, this machine has a vulnerability, but it's not accessible to the internet or anything that has a very different outcome in my remediation priorities than something that's in A DMZ or something like that.

So, you know, there's more to a vulnerability than just labeling it with a VI Think there's other things that foot here as well, though. I think if you go back, we all saw the Log four J thing and we all flipped out, right? Everybody went, oh my God, this is the most vulnerable thing ever.

And you know, sometimes we found issues and sometimes we didn't, but we created such a level of noise about it that I think the bad guys looked up and said, what are they all talking about? And then they're like, oh, I get it. We can actually insert malware in the code and all this stuff is insecure.

And so then they spent the last year figuring out how to do that. So I think maybe we are discovering more of this stuff because they're getting better and there's more of them trying to do it. Or, or we just woke up to what they've been doing for a long time, Right?

That is the, they weren't surprised by lock four J. They're just smart enough not to give out their zero days until they've had a chance to use them. Mm-Hmm.

Um, but look, I, no one should be sleeping at the wheel around vulnerabilities. That's for short. And I, I think that's the takeaway here.

You want to nitpick, do we have more or less, do we, are they reachable or not? People need active vulnerability management and remediation. The biggest thing I've seen is automated remediation catching on a lot more than it used to.

Mitch, if you remember right back in our van days, it's still secure. There was a company called Citadel, and they had a product called Hercules. Mm-Hmm.

And that was kind of the first automated patch management solution that I was aware of, right? Back in the day. They had a big diss contract.

I think the whole DOD was using them, but there was a lot of reluctance to use it. 'cause no one wanted to automatically remediate and patch things. Today, almost every vulnerability vendor I know is, is on to automated remediation.

People aren't so afraid of just patching their, their vulnerabilities without extensive tests to make sure it's something else doesn't break. And that, but Is that a level of comfort or is that just, uh, you know, the need for speed? They don't have time.

You don't want me to start rolling out? Uh, okay. I, I probably don't.

Okay. Top I was give you Top gun. Come on, goose.

Um, but anyway, there you go. I, I think it's a little of both. There is the need for speed.

Are we building apps too fast? Do we need to slow down? I know RSA is coming up And even if you want to even, first of all, shame on you, bite your tongue.

But, um, do, do you think the world's gonna slow down developing apps because you told them there might be vulnerabilities in it? I don't know. We could have it.

You need to hang out with more security people. Wait, we, we could be having a Ralph Nader moment here. Unsafe money.

Speed. Exactly. You'll get 3% of the vote.

Um, or 2% whenever you got a good job when you're running, no one is gonna slow down app development because of security. I'm sorry. That's, that's the world we live in.

Alright. I feel like this is a lot like watching the Coast Guard do drug interdiction. It's like every year they're like, Hey, we discovered yet another ship with billions of dollars worth of cocaine on it.

And meanwhile, you know, the 20 other ships that have cocaine on it, they didn't catch. So, Yeah. Yep.

That's the way it is. But, but it's been that way. But, but not, not to be the crumb, curmudgeon old security guy.

It has gotten better. Oh, absolutely. Really?

It has. We, we, for the most part, our software is more secure now than it was, as I said, 10, 20 years ago. I, I think one of the other things we haven't hit on is this, what they call software composition analysis, which is code word for open source.

And as software contains more open source components today, we're seeing, you know, a huge, we used to think open source was more secure than commercial. It's not necessarily true. I don't think open source is less secure per se.

But with all of the open source software components we use and the dependencies involved in them and everything else, it it, it creates issues. And, and, you know, this is why we see this whole SBO m and software supply chain, Mitch, who's in charge of this mess. 'cause we've been talking about shifting security left for a while now, but then the developers look up and go, you know, I got my day job and this is hard and my cognitive load is just too much.

So somebody else should figure this out. But the security people don't seem to know much about application security. So are we making any progress here or what?

Well, building software is not the expertise of security people. At least most security people, they don't come from that background though. They're, they're doing their best to learn and be part of, you know, working with development teams, you usually have like a, a, a champion and a security champion on a development team, or somebody who is kind of at the point that knows the most about security.

Ultimately, it's, it's in the hands of the creators. Now that could be developers, it could be the platform folks that are building the environment that you're working in. Uh, you know, the configuration of that, the DevOps tool, the supply chain of all the tools that you're using.

So, you know, you know, it is not one silver bullet that will solve it all. And I think you have to kinda lift all, uh, raise all boats, you know, rising tide kind of idea. You know, and I don't mean to be tilting at wind windmills here, but really it's not just one thing that will fix it.

And I'm, and I hope the more we have, you know, automated kind of smart code generation, the more that will help at least maybe help us fix it. You know? Let me introduce y'all to a term DevSecOps dev.

I heard that Once. Dev sec Ops. That's what this is about, right?

Oh, it's not that security people are responsible for it, but security's everyone's responsibility. We can't expect our security people, our, our developers to be security people. It's still the job of security people to, to provide security.

But we could build more security into our CICD processes. And that's where DevSecOps and AppSec is part of that come in, making security testing before code is deployed standard, right? Deciding whether vulnerabilities are showstoppers or not, right?

That need to get remediated and, and if need be, go back to the developer. Um, look, we're gonna, we've been doing it for eight years at the RSA conference, right? We put on DevOps, connect DevSecOps, and we discussed just these issues this year.

Mitchell, to your point, it's DevOps Connect is DevSecOps meets generative ai. And that's exactly what we're gonna be talking about here. It's Monday, May 6th.

It's at RSA, it's in the Moscone Center. You can get a free ticket to RSA to our event and the expo hall. If you go to, uh, tech Strong events and look up DevOps Connect, um, we've got an amazing lineup of speakers.

Mitchell's gonna be doing a panel there based upon some research he's doing. But in addition to that, we've got senior security people from meta, from open ai, from Google, from DeepMind, uh, anthropic there. I got it on the first try.

Bingo, anthropic. Um, and more in addition to David Bri, uh, we're now futurist sci-fi author, J nasa, JPL uh, person. And just great futurists on AI for many, many years.

Do you, if you're interested in this topic and you're going to San Francisco for RSA, we're a flower in your hair? No. But come to RSA and and we'll see you there.

Or, Or come to this event and then check out the rest of our, There you go. Well, you're getting a free expo pass anyway. Exactly.

Either way you're in. Alright. Alright.

Should we take a break? We're Gonna take a break and be back in a minute. 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. Alright. Hey, we're back here at Textron gang joined in case you're just joining us.

Mike Ard here to my left or right, I guess depending which way you're looking. And joining us remotely is Mitchell Ashley and, and Sharon Florentine. Happy to have both of our gang folks with us here.

Mike, what do we got up next? We're talking about EBPF, otherwise known as extended Berkeley packet filtering really flows off the tongue there. It's awesome stuff.

But as usual in tech, I think, you know, the more arcane something is, the more powerful it is. And we don't talk enough about it, but in it as an explanation, and I'm gonna simplify this as much as I can, but it's basically the idea that we're gonna create a subsystem within the Linux kernel that is isolated and safe. And we can then use that to run things, whether it's, um, networking software, security software, storage software, observability software in the microkernel versus up in the user space where it runs slower.

And if we put it down into the microkernel, things will scale higher, we'll have better performance, and we can do some interesting things like, um, observe from everything from the operating system up versus having always instrument everything and put agent software everywhere. And these are kinds of the things that we're excited about. But Sharon, I feel like we've been writing about this EBPF stuff now for a while and it's usually shows up on, uh, cloud native.

Now, have we, as the kids say, in the back of the car, are we there yet? Uh, I think we are getting there a little faster. Uh, there was some movement, I believe last year, so that now EVPF is not just for, uh, Linux operating systems, it's moved into Windows, which always to me says that's the mainstream on ramp kind of.

Um, you know, it's networking and Cloud native is incredibly complex and complicated. So adding EBPF to that is like now exponentially more complex. Um, I maybe, maybe we're getting there.

I don't know. Wait A second. You are telling me EBPF runs on Windows now.

It will soon Somewhere. Steve Balmer's losing his wings. Yeah.

Um, at least Microsoft is committed to make that happen. All right. I'll see it when I believe it.

Yes, There's a webpage for it. At least there's that much. I don't know if it's Really yet, but Yeah.

Yeah. That's how I feel about it too. Mitch, do you think we're gonna wind up swapping out all the stuff that we have, whether that's networking and storage and security related to, for the EBPF version, which is now available in like the last, I think three or four major releases of linnux.

So, um, it's starting to show up with support and actual, uh, distributions of linnux. So are we gonna, are we looking at a wave of change here that we're not talking enough about? I I think we're already starting to see that.

I mean, in essence it's, you know, we think back when Alan and I were doing intrusion prevention products or intrusion detention and in, uh, detection, and it's the down Ker that slow down de slows why it was the first answer was right. Yeah. That, that too.

I'm sorry that fian slipped there. Um, um, but it, it, it was the, uh, context switching, you know, the interrupts that would cause us to slow down. We couldn't handle traffic enough.

We wrote a hack around it. One of our engineers did that to be able to get higher performance. Now, what this is doing is essentially building that into, in a much more sophisticated way into the kernel space.

So you have your own protected name space for security. So you can't get to things that you should be, and then people can put code in that perfect for agents, perfect for monitoring, perfect for observability security, be able to look at all those things. So to me it, it's kind of like, you know, do you want, um, siping with your tires?

You just want regular tires? Well, siping will give you much better, you know, water, water to move moving away from your tires. Now the treads are better traction on the road.

Great. Then go do that. And that's kinda like you and I don't really care about that on a daily day basis, but people in that space do.

It's super important. Mm-Hmm. I think the security people are gonna love this because it'll allow them to scale.

One of the things that they've been complaining about for a while is that the volume of the attacks is so high that the software that they have doesn't necessarily keep pace without throwing a boatload of hardware at it. So, um, we might be able to fight this fight at a level of scale that we can at least maybe break even. I don't know when.

I mean, you would hope so. You would hope so. I, I don't know when either, to be honest with you.

All right, Well, one more tool. If you guys wanna learn more about EBPF. We have an interview with Bill Mulligan, who's one of the maintainers up on the Techstrong TV site.

But I would encourage everybody to take a good look at this 'cause it's gonna impact everybody and everything we do is just a question at this point. More of the when rather than the if. Alright, Cool.

Alright, let's take a break. Our last break of the day, we'll be back with our third topic on tech strung gang. Stay tuned.

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.

All right. Hey, we're back here on Textron Gang, uh, block three for today, Thursday. Hope you're enjoying the show.

Just a reminder, in addition to Textron Gang, we have a full day of Textron TV for you coming, uh, immediately following. So you don't wanna miss that, but let be, let's not get, put the horse before the cart and let's get right to, uh, block three for today. Mike, what do we have?

We have an interview on Textron tv where we talk to Solomon Hikes. And those of you who don't know who he is, he's, uh, the original founding CTO for Docker. And now he working on a project called Dagger.

And that's basically trying to help people create a level of abstraction for integrating microservices and a bunch of other things that you do as a developer. And it, it, I guess at one point people were thinking that maybe this is the second coming a docker, but it looks like it's just yet another tool. And I think in the interview that becomes apparent.

But Sharon and I talked about this interview in our podcast, and you and Mitch talked about it in your DevOps podcast. So we thought we'd all get together and have a little chat together and compare notes and see what we all think. But, um, one of his points was, Hey, there's no silver bullet in the land of DevOps and you gotta actually do the work.

And I feel like sometimes every day somebody showed up with a new platform that's gonna magically do everything. And I don't think this is a real conversation about that, but what is real about DevOps from your perspective these days? What is the current state and, you know, how much manual work do people need to be thinking about really doing?

Wow, this went down a rabbit hole. I wasn't thinking about. There you go.

I was you one minute. Know solo and hikes, um, is, but anyway, DevOps is very real. It's never been more real.

I think it, we are, Mitchell's doing a, uh, tech strong research is doing a whole, uh, report on this called DevOps next. And you know, i i, I don't want to steal anyone's thunder, but that report's gonna have a lot of that kind of information in it. Um, I think we forget that over the last 12 years that we've seen the rise of DevOps, things that we take for granted today, like cross-functional teams, um, publishing software using Agile and then into A-C-I-C-D process as the norm wasn't the norm.

Back then. We were running around doing waterfall and, and the idea of having a scrum meeting your daily scrum was revolutionary. And now it's become, you know, rather norm common place.

Yeah. Yeah. Mm-Hmm.

And, uh, automated testing and remediation and, you know, the whole Git ops and using Git and, and all of these things. Um, so DevOps is certainly real. Look, Solomon's a little younger than some of us here on the panel, right?

And he's a brilliant, brilliant engineer, right? I mean, he brought Docker and, and, and what changes Docker has wrought on our software infrastructure. Um, but there, you know, I, I don't want to bust anyone's bubble, but there's no Santa Claus, there's no tooth fairy, and there are no silver bullets, right?

There's no magic silver bullet that cures everything. Change comes in increments, especially in technology. And, and we're seeing incremental change, things getting better.

But anyone who, who's migrating or advocating for DevOps as if it's a silver bullet, you, you're crazy. Any more than there's a silver bullet for security or for world peace or for ending diseases and all of these things, they don't exist, right? It's, it's rolling up your sleeves and doing the work day to day, getting better at it, figuring out what works and what doesn't work that over time moves the needle.

Mitch, is there such a thing as kind of the universal DevOps platform? 'cause to his point, we tend to sweep our arms and we go CICD and best DevOps practices. And yet, you know, if you go into that, there's like, you know, gates and processes and all kinds of stuff that has to be managed, and each company's gonna do that differently.

So is there such a thing as, you know, DevOps as in we're all gonna do the same thing? Or is it more like, you know, something where it's different in every company and you just gotta figure out what suits you? Well, I think it's part Of its strength and also part of what it, you know, the challenge of what it takes to implement DevOps.

One of DevOps strengths is its flexibility. You don't have to do it in one way. And there is a sort of a religious war about how you do DevOps, right?

It's very adaptable. And frankly, it needs to be adaptable. It's not every organization works the same way.

That said, you know, we have seen the rise of platforms, uh, that kind of do an end-to-end job of DevOps and do a lot of, uh, integration, um, connectors things, things that help with the plugging in other tools. You can, you can go back to the days of Jenkins and say, that's really why, one of the reasons why Jenkins is still, we're still in the days of Jenkins successful, right? It's, it's, it's plugin architecture and the, the, the, uh, you know, the economy of all the plugins and things that it does that you can enhance it to.

And I think that's even in the platform world, that still is part of it, of what we have to do because, and my, in my world, people rarely find sign up for one tool and everybody will use it. It just never happens. Especially with developers who are gonna say, I see your one tool and here's my 20.

You know, they're gonna do it the way they wanna do it. So if you give 'em a flexible, flexible environment, they can do that. But I, I don't, I think that would've limited it if we tried to restrict it to one way or one set of tools that, that it can be done.

Now, what's interesting about Solomon's work is, you know, he early on kind of pretty DevOps really, uh, with the whole container idea and was doing this as part of a platform as a service to make it easier to deploy apps, right? He was just solving a problem and created this idea, and it became Docker and released it in, I think 2020 13. Um, and he's kind of done the same thing here with Dagger, which is now that you're doing all this managing A-C-C-I-C-D environment where you're trying to figure out how do I do builds and deploys across not two or three, but 20, 30, 40 different variations of maybe the same handful of environments.

It's, it's all scripts. It's kind of a house of cards, right? Tower Babel, it just, it, it can easily fall down with how much work it takes to maintain it.

And that's what he's trying to do here, is let's simplify that and make it more of a building block approach. Uh, kinda abstract it like you did with containers. Yeah.

You are Familiar with the I agree. Sorry. Oh, Sharon, go ahead.

I, I was just gonna say, I think, you know, the, there's the, the pendulum idea, right? Where DevOps was supposed to came in to solve the problem, and then it turns out, you know, there are so many different tools and approaches and ways that you can put these tools together to solve the problem that it became almost, um, you know, unmanageable. So then here comes platform engineering to kind of centralize all that.

But then the pushback to platform engineering is, well, this is what we, this is why we adopted DevOps to escape, to avoid this centralization, right? So I think the pendulum just keeps, eventually it's gonna settle somewhere in the middle like it, like pendulums do. But So I, I think there's a couple of things that we need to, to call out here.

First of all, Solomon Hikes did not invent containers, right? Containers have been around for 25, 30, 40 years. They're part of mainframe and everything else, and they've been part of Linux forever.

Mm-Hmm. What Solomon Hikes did was use containers in such a way that developers, it made it very easy for developers to containerize their applications and, and settle fire to this whole microservices industry or methodology. Um, but when we talk about DevOps, again, as Mitchell said, it was designed to be flexible.

It was designed to have no manifesto, no real definition. And part and parcel of that though is please don't confuse tools with culture or framework from a tools perspective. I think we're entering the DevOps platform era of tools, right?

Where prior to this, as, as my friend ti Banza, A CEO at, at, uh, at, uh, harness, founder at Harness says, we, you know, before this, we had the first era of DevOps tools, which were cobbled together. You had Jenkins and you plugged in this, and you're plugged in that, and the Phrase is Jenkin Jenkin. Exactly.

Yeah. And, and so now we're getting to the point where the leading DevOps players do have sort of end-to-end platforms, JFR, CloudBees, uh, GitLab, even harness right? Are starting to bring these next gen DevOps platforms.

And so you're seeing that, but the real, and, and it's powerful, don't get me wrong. It's good. But the real revolution here are evolution was the cultural aspects of DevOps even, that we're even talking and thinking this way, that developers aren't just tossing stuff over the wall and saying, Hey, ran on my machine, you know, have at it.

And, and we don't live in that world anymore, thank God. So don't underestimate the progress and the changes that DevOps have brought to the software delivery factory floor over these last 12 or so years. They've been substantial.

And they continue to be. I think to your point about culture and humans, I think what happens is people get a DevOps thing to work, and it took them forever to get it to work. And now they're like, don't touch it.

It's gonna break. But the developers are complaining that there's too many bottlenecks in the system. Still.

There's too many manual things that we're working our way around. So do we get lost in the notion that we didn't realize that this is a continuous process and it never ends, or we got it into our Heads? Hello, I got a book for you.

The Phoenix Project, right? That's the story of the Phoenix Project, which by the way, is just an it version of the goal, right? And, and for those of you who have never heard of the goal, please run out and get that book, Mitch, I always forget the author's name.

Gold Rat. Gold Rat Gold, the gold. Um, and that's, that's the revelation of Gold Rat.

And it, it goes to lean and it, it's manufacturing as well as it, which is the nature of the beast is as soon as we undo one bottleneck or get through a bottleneck, there's another bottleneck and another bottleneck. And, and that's, that's what life is, right? This is a, a metaphor for life, guys.

It's not all smooth sailing. We go from one bottleneck to the next one, crisis to the next. And, and that's what software development is too, right?

So for those developers who thought, you know, we were going to adopt DevOps and be done with bottlenecks, you didn't finish to the end of the book, go back and read the book. I think what we don't want to have happen though is, um, and it feels like this, people are kicking the bottleneck down the road. Well, they're kicking the can to the next bottleneck.

But, but again, that's, that's normal works. I I don't think it's abnormal, right? If it's too hard to pick the can up and open it, we just kick it to the next one and it be, and that becomes the next bottleneck and the next bottleneck.

But you're never gonna be through with the bottlenecks is the point. There's always the next Bottleneck. I think the, the bottleneck is that, and I, and I saw this in an article somewhere once, is if you, if you, if you're not working on the bottleneck, if you're working on stuff that go, that leads into the point where the bottleneck is, all you do is make work, arrive faster, you make your problem worse.

If you work on the things that after the bottleneck, they're just starved for work. 'cause the bottleneck is holding it up. So by working on the bottleneck, that's what smooths out that part of the process.

Well, guess up, guess what? It's kind of a, you know, it's one of those squeezy things. The little bubble pops out here and then it pops out here when you squeeze a little differently, it, it's what happens, it moves, and it may be a bigger bottleneck, maybe a small one, but the point of the bottleneck is that's what you work on.

The the biggest thing that's slowing you down, uh, that's what you improve and that will make the flow better. And that's a continual process. That's not a one-time thing.

That's, that's a whole quality management philosophy. We talked about silver bullets. Is AI gonna be the new silver bullet for DevOps?

Can we fix all these bottlenecks with a couple algorithms just in a model? And we're good to Go. The only, the only silver bullet Mike, is Coors and Coors Light.

That's the only silver bullet I, that I believe in, Spoken by the man from Denver, from Colorado. Yeah. Hallelujah.

Rocky Mountain High. And, um, is AI gonna help? Yes.

There are no silver bullets, man. Right? I, and I think, by the way, that being said, let me bring this full circle.

I think what Solomon's doing with Daggers great. I'm interested, you know, given his past and his talents and, and his, he has, I think he has a great sense of what developers and ops folks deal with and, and things that we can do to make it easier for them. So I'm, I'm, I'm, you know, I'm bullish on, on Dagger.

Let's see what it comes out to be here. But, you know, I I, I don't want to saddle it with the silver bullet Yeah. Label.

Well, but I gotta say as the, as the managing editor over here, um, you know, silver Bullet, holy Grail, whatever you wanna say, my job to bring traffic to the website. So those phrases definitely help writing headlines. Let's just say.

Well, Yes, EO loves that stuff. I thought you told me. No.

Clickbait stuff. You always yell at me. I do.

I do. I do. We can, we can walk the line a little bit, right?

Sure. It's a bounce. Sure, Sure.

Um, but, Uh, no, I mean, Mike and I talked about this a little bit on our, on our Cloud Native Now podcast, that there have, part of this continuous process is recognizing when there's the next holy grail or the next silver bullet. You know, it was, it was Docker and then it was Dagger and Dapper and all of these other tools and solutions that keep coming up, and that's none, just like Mitch was saying, not a single one of those is ever going to solve the issue, nor do we really want it to. Right?

Because that's painting the Veno Bridge, Job security. So you kind of, yeah. All right.

So it's DevOps. It's not just a job, it's an adventure. Is that where we're going?

Yeah, it always was. That's what attracted Me. A it's a calling, it's a mission journey.

It's the journey. Um, I'd like to throw out one other thing on our text on Gang today. I think it was, was it earlier this week we spoke about layoffs at Cisco?

Mm-Hmm. Yeah. Would've been the last.

So those, those were carried out late last week. And I, I was really chag grinned over, do you like that word? That was a good word.

Nice vocabulary word. I was, I shocked working that in. Yeah, I was chag grinned over the weekend.

Well, because the weather here was terrible. But beyond that, I saw several, more than several good friends of mine reach out that they were part of layoffs some at Cisco, some at other places. Another friend of mine, actually in the tech media world, hasn't been able to find a marketing position for seven months.

Seven plus months. He's ready to go work at Home Depot. Um, and it bothers me, right?

I mean, some of the people, look, there's some amazingly talented people looking for jobs right now. So if you are looking, you know, go check it out, especially in the security space, I'm, I'm amazed at the people I'm seeing that are out of work right now. Um, but this whole issue of the layoffs, Mike and I spoke about it recently, besides what we spoke about on, on Textron Gang, you know, there, there's multiple reasons for these layoffs.

I don't believe that the leading reason is that these companies are doing as bad as one might think with when you read the amount of people they're laying off. I, I think what we're seeing here is the, the hangover medicine from three years of, of drunken revelry, or maybe even more than three years, you know, of near free money and just trying to hire someone. 'cause you can't, um, I think that's definitely part of it.

Um, I, I do think it's also a lot of companies taking this opportunity to, to trim some dead wood off some branches. Um, I think in some cases it is a case of, you know, uh, with interest rates and money raising and the market and all of that, there is a return to value versus growth, profits versus growth bottom line versus top line. And, and that's, I guess, partly to, not to blame, I ought to blame.

That's a good word. That's partly to blame. But nevertheless, for those of you who are out there maybe watching this and looking for a job, look, I personally would love to do anything I can to help you.

If you're a friend of mine, reach out to me on LinkedIn. I'll do what I can. Um, Sharon, I know on DevOps, we always run the five top DevOps jobs or whatever.

Maybe we could expand that to other sites on security as well. But we hear you, we feel for you. I mean, good people will not be unemployed long.

I, I know, but nevertheless, it's a scary proposition, especially when you have a family and you're trying to figure out what the heck am I going to do? So, So, and hang in there because there's a lot of quote unquote AI washing going on. And while these tools are powerful, uh, if you read the press releases that go with these layoffs, these companies are all saying, we're going to be more efficient because of our use of ai.

I think that there's gains to be had there, but I don't think that they're really un understand exactly what that AI tool can and cannot do just yet. I agree with that. I, I, mm-Hmm.

As a matter of fact, I challenge one company to say, Hey, we replaced this person with ai. I, I don't, I, I'm, I love ai. I'm a big believer.

I use ai. It's not at the point of replacing people's jobs yet, though. I'm sorry.

And any company who's using that is, is being intellectually dish dishonest. Beer Mon green. Yeah.

Yep. All right. Is that it?

Stock prices are now falling because, Because of my outlook. EF hu. That's an old blast in the past.

Look it up. Um, all right, I think that's gonna call a wrap on this, uh, Textron Gang episode. Stay tuned.

We've got another, oh, at least two, three hours worth of programming here on Textron TV today. Don't miss it. But for now, this is Alan Shimel for Mike Ard, Mitchell Ashley, Sharon Florentine.

We're not gonna be live tomorrow. Have a great weekend, everyone.