Techstrong TV – August 7, 2024

Hello everybody. I'm Mike Biard. Alan Shimmel is out at Black Hat today, so he won't be on the show with, I mean, but we have an awesome lineup of guests, and we're gonna be talking about DevOps and ai.

Then we're gonna be talking about a little reverse engineering of code using ai. And finally, we're gonna have a deep discussion about what it means for Google to be a convicted monopolist. Hey, you're watching Textron Gang, and we'll be back in a minute.

All right, folks, we're back in. Let me introduce our guest for today 'cause we have some new ones. But let's start with Mitch, who is not in Denver today for Mitch.

Where are you? Hi Min, actually in Las Vegas had Black Hat. There you go.

Which I'm not sure everybody knows what Black Hat is, but it's one of the big security conferences that take place during the course of the year. And of course we have Amanda Ani, who's home in Texas, I believe. Yes, that is correct.

And then finally, our newest guest, Dave Nicholson, is out in California. Dave, welcome to the show. Thanks.

Glad to be here. All right. Dave is with Fu Toum, and do you have a particular specialty in Fu Toum since this is your first time at joining us on the Gang?

Um, I think, I think sort of the specialty that I bring is, uh, voice of the tech customer, because I'm adjunct faculty in the Wharton CTO Academy. So if, if I had to be nailed down to something to a single hat, that would be it. Dave's the guy who talks to CIOs and CTOs every day, that would be me.

All right. That's an impressive program that you're part of too, David. It's a pretty amazing what they do at Warden with you.

All right, awesome. So, and it is fair to say that you are a geeks geek. Try to be.

All right. Well, let's jump into our first topic 'cause we got a lot of geeky stuff going on today. Our first article that we want to talk about is a new report from Techstrong Research authored by Mitch Ashley.

And it goes into, well, what is the level of adoption of AI among DevOps folks, and what are we seeing? And I know, Mitch, you authored this report and did all the research. So why don't you kind walk us through the highlights a little bit.

Well, bit of a, a labor of love. 'cause this is actually an update to a report we did in 2022. Textron Research did a report about what are the anticipated benefits of ai.

You know, that was pre gen ai, um, and in copilots and things were starting to be used and AI being introduced in some of the DevOps and testing and other kinds of tools. So this gave us a chance to come back and say, okay, now a lot of things have happened, right? You know, the new cycle's about two hours these days.

So, and it seems like the AI is on a shorter cycle. So it was really interesting. Um, we, we talked to a variety of people, folks primarily involved in developing software, ranging from architects to engineering leadership to developers and testers, uh, systems in, uh, system reliability engineers, platform engineers, et cetera.

And trying to understand, so, you know, what's happening, what are people, are people seeing any benefit from AI yet? And using it anywhere in the SDLC. And there were, uh, some, I think some really surprising in a way, findings.

Um, in terms of people that are using it, about 24%, um, said that they're, excuse me, about 20% said that they're using artificial, uh, intelligence in some phases, any of the, any one or more of the phases of the software development life cycle. So they're consciously knowing that we're using ai, part of our development, part of our testing part of whatever phase that might be. Um, and at least 24% had at least one, one, uh, one phase that they were using in it.

But the two standouts, probably not too surprising, were the, uh, we're using AI today and writing code, and also preventing defects and doing testing. Those are the three standouts, but not that far behind where other areas of the software development lifecycle, um, I think there were some real eye openers there. Uh, the people who were, what we call the more, uh, mature phases of DevOps.

'cause we did ask, you know, how long you've been doing DevOps. Um, how would you assess your maturity of DevOps? And do you, uh, how do you see your performing?

Are you assessing your, your abilities, uh, as a DevOps oriented organization? And, uh, those who are using AI and are in the more mature stages of DevOps, we call it adoption, we call it the unicorns, kinda at the very top end. And also, uh, people who are standardizing, meaning they've gone through the adoption, they've learned they're really standardizing DevOps or have standardized it across their organization, uh, rated themselves higher in their performance, or either the higher medium, two categories as compared to the group who were not using DevOps.

So actually not using AI as part of their DevOps. So, um, it's really, it is really, it's a great report. Um, by the way, it's a very approachable approach, uh, report to, uh, a lot of graphics and, you know, content that you certainly can read it, but you can also skim through it.

And there's a highlight section of some of the findings. So that's just a quick recap. But, uh, again, labor of love.

Do these things take a little while to, to get done. And, and it was a real pleasure, uh, publishing it. And, uh, Tricentis was the sponsor.

You know, they had some input on the questions and, and gives some feedback on the writeup. Um, but the, the research is our, so we're, we're happy to be publishing it. Let me ask you this about it.

'cause what struck me was it seemed like, well, maybe not everybody's using AI just yet, but those that are, seem to be rapidly moving it through the entire software development lifecycle. And, um, so once you get into ai, it seems like you kind of want to use it everywhere. Very, very true.

Um, kind of, there are some, there are some easy entry points, you know, the co-pilots and development is one obvious place because it's already built into many ides and a lot of organizations are, they're not using it, they're experimenting with it. Like, how much do we use it for code completion or do we actually generate some code, um, with it as well? So that, that seems to be the most common entry point.

And then of course, any tools that you're using, like you're using a testing tool that's, that has AI built into it. If you're using A-C-I-C-D platform, um, GitHub, for example, repository, whatever you're using, those are also kind of ways that it's introduced into the SDLC. Uh, one of the other interesting findings is, you know, are, I think you kind of know the answer to this, but are we just turning AI loose?

Do we just let it do what it's gonna do? Or do, do people have to still be in the loop? And very much, very heavily, um, folks saw that being a human in the loop, looking at the output of, uh, of, of AI in any place in of those places, uh, in the SDC was very important.

Just a small fraction said, yeah, we kinda let it do what it's doing. I imagine that's not too, too big a shot doing that. From that standpoint.

We also looked at productivity. You know, what, what is the impact on the people processes and, uh, productivity of people? And, uh, you know, how much is it impacting your productivity?

Uh, how does it help you keep up with the demands and, and across the board of the kind of positive ratings, um, the kind of somewhat more productive, somewhat, uh, usually hitting demands, things like that were, were pretty substantial. Um, but even those in the significantly, in those two categories were, were always, were also fairly high there. There's a middle of the road, you know, we're, we're not seeing an impact yet, but, uh, there was very little who were saying it's negative on productivity.

And we've heard some things about AI taking more time, you know, particularly if you're using Gen AI for writing or things like that. So it's, it doesn't seem like it's getting in the way or taking people too far off course to introduce it into their development. David, I know, I think it's fair to say that we are in the hype cycle of AI for specialty, for software development.

What's your assessment of what's really going on here? I mean, last year there was probably a lot of what you might call irrational exuberance. So where are we on this actual journey?

I think we're in the, um, if you, if you go sort of down to the lowest levels of the IT stack, uh, I think some rationality has returned. Uh, folks who are making decisions about building these stacks realize that there isn't only a single blessed way to accomplish what they wanna accomplish in the world of ai. So I think that there, there will be a lot of, uh, realignment of players in this space.

You know, Nvidia, of course is going to dominate, again, diving down to the lower part of the stack. So I think we're in sort of the, the place where we start to get more rational about these conversations. Um, but, but on AI for DevOps in particular, uh, it's, it's important always when we use either a a if the, uh, if the TLA is a two letter acronym or a three letter acronym, that we sort of define what we're talking about.

Because yes, ai, artificial intelligence, well that's a big, that's a big umbrella. People immediately leap to this concept of generative ai, auto aggressive generative ai because we're so familiar with it at the consumer level. So people, people hear AI and DevOps and the conclusion they generally leap to is, oh, you've got this, you've got this engine that's going to generate code by the use of plain language, uh, computer, uh, I shouldn't say that.

'cause my device will go off here. Sorry. I'm sorry.

I have my Alexa programmed that had to, had to unplug little start reference there. So, you know, you, you say, you say, you say computer, write me a software program with a caterpillar that catches butterflies and the system, oh, okay. It goes out and it generates the code.

That's not, that's not really where we are now. To, to Mitch's point, if you go back in, if you go back in history, we call it paraprogramming. Um, now you have an artificial copilot with you at your shoulder sort of making suggestions.

But the person is very much in charge of the tool. But the vast majority of AI that's happening in DevOps today and everywhere, frankly, is what we would, we would call sophisticated machine learning and automation. And there's nothing wrong with that.

That's awesome. It's where it's gonna begin. Um, and I guess my final thought on, on, on AI is much like cloud.

I think at some point in the not too distant future, we're just not gonna talk about ai. It's all gonna be considered it just like cloud, is it, it's all it, it's information technology. Yes.

What we're doing in AI is revolutionary to a degree, but really it's just the next thing in information technology development. Yeah, it's interesting you, you place it that way. 'cause one of the things we discussed is what do we title this report?

Is that AI and DevOps is that, you know, software generated code with, with ai. And, and we, we stayed with the AI augmented DevOps because yes, it's not AI in the driver's seat, it's the copilot or it's behind the scenes. Yes.

Um, it's, you know, like your pair programming example, you know, I'm, I'm gonna look at the code 'cause we don't have code generators that we know generate better quality code or more secure code, things like that, more reliable code. So there's, you know, we're relying on some general LLMs to ADIs, at least in terms of generative AI and the code writing part. There's a, there's a long ways to go.

And that's part of the theme of the report is here's the impact we're seeing so far, but we're at the beginning of all this, this is, and, And, and augmentation. IIII love augmented, um, because at some point it almost becomes absurd for us as humans to say that, well, it's me augmented. It's like, no, dude, you were driving a freight train.

The freight train was towing everything along the tracks. It's like, no, no, no, it was just augmenting my strength. Uh, it's like, Well, I, I should say no, AI was harmed in the making of this.

So we're all clear. I had a question in regard to the report, and Mike and I were talking about this yesterday in our podcast. Um, it was another report that we were reviewing, but it was saying, while AI was increasing efficiency, in fact what it was doing was causing more burnout in a lot of employees because they had more of a workload because of the efficiency.

They had so much more of a workload, their brain capacity couldn't really handle it. So they were struggling from burnout. So what are your thoughts on this?

Um, it, it's a great question. It's not something we looked directly at Amanda. Um, and I'm familiar with that report too, of, you know, just, just trying to figure out how to use ai, create more workload on top of trying to get what you're were done in the first place.

So are you having a net productivity gain? Um, when, when we saw kind of, when we saw what the changes in people's work, um, productivity was the first thing that they kind of pointed out. And real closely for developers as well as for test teams.

So, which tends to be, you know, that's, that's, I don't wanna say they're the bottlenecks, but that's kind of two of the things that are essential to get code, get, get software developed and, and get it out the door. There's a lot of other elements as well. Um, and, and they did say fewer resources, full-time people, things like that.

But that we started kind of falling off on what are the changes to people's jobs. I think there's a lot of shakeout to do yet. And, and I would, I've never been a believer of, you know, oh, the cloud is gonna replace everybody's job.

No, it replaced, you know, people that, that hung machines on racks. It didn't replace, uh, people doing work. Uh, same thing for ai.

I think it's largely, uh, augmenting what we do. You know, I'd love to have LLMs, we're not here, LLMs that, uh, help us reduce technical debt. If we had an LM to do that, turn that loose on all those things that Dell, the developers don't want to go back or helping us figure out what those systems do, that the people that wrote 'em are long gone and, and we're afraid to touch those parts of the applications.

I think that's, there's some real productivity gains there. So, bottom line, we didn't look at that specifically, but I didn't see anything, the data that, that I got that sense that people are, if anything, they may be trying to figure out where the best cases in their applications are to use ai. That's where there's new Work.

I would look at, I would look at this productivity question. I, I would ask Amanda, see, you, you see this, you're familiar with the, the mobile device, obviously. Is this, does this give you more freedom or is it a ball and chain?

Right? Oh, it's like, I can work, I can work from anywhere. I have to work from everywhere.

I think that I think those AI tools are, are going, there's gonna be a mixed bag as we go forward with that. Uh, an individual developer inevitably will be able to be more productive if they let that bury them. Like some people let their mobile devices bury them.

It's gonna be tough. It's gonna be tough. Of course, your mileage may vary if you're asking my family versus me, right?

David, Let just, You're absolutely right. Good point there. David, let me just ask you one last question here.

It seems like one of the things that's in this survey that leapt out at me was only 9% or so of the folks who are, you know, totally trusting the output of these gen AI platforms. Um, so have we reached a point where, you know, it's great, I got a little tool, it's gonna help me do something a little bit faster, but it's the reality of is it is not this end-to-end magical button. It is a thing that helps us get something started, but it won't complete nearly any task.

Or if we let it complete any task, we should look at it really hard. Yeah. Let's say you're, let's say you're using a tool like this.

How many times does it have to be wrong for you to say, you know, this is a waste of my time. Now I'm proofreading the work of a kindergartner. This, this doesn't make sense.

Eventually people will, will start to trust it. There's a parallel with, um, uh, driving aids, self-driving systems in vehicles. It's the same sort of thing.

It's one thing, Hey, straight highway, I have a three hour monotonous drive. You very quickly will trust the system, try driving that same car with the same system in stop and go traffic in a construction zone on a rainy day. It doesn't take too many.

Whoa, whoa. What were you doing for you to say, forget about this and turn the system off? So, um, I think we're, I think there are gonna be fits and starts as we go, but it's gonna be an upward slant to adoption.

There will be people who will try it, say, ah, forget this. I'll come back later. There will be people who stick with it because they're early adopters.

But over time, more and more people will learn to trust it as it gets better and better. Hey, David, a question for you. Um, uh, this is a big question, but could, are there any highlights you can share of what are the conversations about AI in, in the program at Wharton that you're part of?

What are the things that are bubbling up to the surface? Um, I, well, it's sort of funny. I would say, I'd say going back six, 12 months ago, a lot of the conversation was, um, and I'm being silly, but I'm serious.

These, these, this, this is the way that the conversation goes. The CIO says, I'm really, really upset that we fired all of our people who could be doing work on this stuff, on premises in favor of, of, of moving everything we do to the cloud. Because now we have no data center muscle.

We have no one who can come in and create something that will be a unique value proposition in the world of ai. We're a slave to the cloud providers. We can't even buy Nvidia GPUs if we can get our hands on them.

And the thing that makes me the most mad is that I'm the one who fired all those people. You know, that's their thing. They're, they're realizing, oh, wow, if I had known what I know now, maybe I would've held into reserve some of this smarts internally.

So that's, that's one dynamic. But then the other is, is the, the, um, um, what I alluded to earlier, this idea that people are realizing, wait a minute, maybe you don't need the Ferrari highest end Nvidia, GPU based infrastructure completely integrated, uh, stack. Maybe I don't need that for everything.

Maybe I don't need it for anything. Um, people are just learning the difference between inference and training. We focus a lot on training.

People don't realize that there's, in aggregate, there's gonna be way more inference than there will be training. It's just training is concentrated into these mega clusters. So that I, I, I think that's, uh, that's a good, uh, that's a good sampling.

There's a lot, a lot of other, a lot of other stuff. Oh, and the, the final, the final thought I would say is, um, because I work with folks on, on their papers that they're writing over the course of the year on what they're doing with ai, and I would say 80% of it, um, we would all look at it and we would say, yeah, that's ai. It's ml.

It has nothing to do. It's machine learning. It's, which is great.

Has nothing to do with, um, with, uh, generative ai. Not yet in some of these cases. And that's perfectly fine.

Not everything has to be the sexy, shiny, new object for it to be valuable. All right, folks, we can talk about this probably for the entire show, but we can, well, Please, yes, you continue, Mike. Thank you.

We can, we have to move on to our other segments. I would just conclude with remember that thing about trust, right? It's hard to win and easily lost.

We'll be back in a minute. All right, we're back, and Mitch kind of brought this up in the first segment when he was talking about technical debt, and there's now a whole movement afoot to kind of reverse engineer a lot of the existing code that's out there. DARPA has a project where they wanna turn c and c plus plus code into rust, which is, uh, said to be a more secure language because it, uh, doesn't leave so much stuff visible in memory.

Um, and then we also have an article on, uh, text drawing AI talking about the rise of software intelligence, which is kind of like business intelligence for software, where we're gonna do a lot more analytics and understanding how the software is constructed so that we can change it or reverse engineer it when the time comes. I'm gonna start with Mitch. Um, we've been hearing a lot about this stuff, about rewriting entire applications into different languages.

Folks are doing co ball to Java, other folks are trying to convert things into go or whatever it might be. Is, from your perspective, is this gonna be like a major trend? Is this the new face of application modernization?

Well, I think it's, I think it's a thread through that process. Um, very few organizations are gonna go say, let's go back and rewrite everything in blah to Russ, for example. Um, but they may say, going forward, here's what we wanna start using.

Uh, I, I'll use AWS as an example. Um, they made a conscious decision a few years back about what they wanna develop their software in, and they chose rush, excuse me, rust. Uh, I love rush.

Different band, different topic. Um, but for a couple of reasons. You know, c and c plus plus Kenny Lee is a programmer, right?

Kenny love Teddy Lee. Absolutely love all three of them. Um, yeah, and you remember the days we used to talk about c plus plus and SEA of, uh, oh, there's memory leaks right there.

There's things having processes would run a mock and take over and have to get killed and restart it and things like that. There's a lot of housekeeping that you have to do in those traditional languages, um, object oriented or not. And then we kinda shift to the other end of the spectrum where we use, you used to use Pearl heavily now.

We use a lot of, uh, Python, um, and, and any, any number of programming LAN languages, which tape a lot of that housekeeping away from you, and it's easier to develop in, it's much more approachable. Um, but they don't have things that Rust has. Rust has, um, what they call type safety, meaning this variable is an integer, and it will always be an integer and nothing, it can never become something else so that it doesn't get exploited and get SQL injected into it.

Just a really simple example, it also had me memory protections. And that's one of the biggest features because once we're running code, it's not, you know, sitting on the disc, it's running in the memory of a computer, and it's both susceptible to being attacked, but also to getting into other parts of the system into the operating system or other parts of the application. And one of the big pushes around AI is how do I protect my data that AI is using, whether it's generative ai, machine learning, et cetera, all the way down to the chip load.

So I don't want code that's running in, in a, in a processing unit, whether it's a GPU or IPU or CPU, um, that's, that's also post-processing AI type data to share that memory together. So there's a lot of focus on all the way down to the hard level hardware level, which has a lot of implications for the programming, uh, languages that you use. So long explanation, but I, but I went into that because it is important.

Um, it could, we could reach a day where, what are you doing to, in the programming that you're programs that you're writing to add memory protections, to add type safety and things like that. I don't think we're there yet, maybe except for defense and government kind of contracts, but I think we're headed down that path. David, are CIOs talking about technical debt in these issues, or are they just kind of pretending they don't exist?

Well, which ones? The ones, the ones who are just about to get fired, they just, they ignore it. They ignore it.

They figure CIO stands for careers over, and it just doesn't matter. Um, no, part of, part of what we, what we talk about as the CTO mindset, which has to be incorporated into every CIO's role, is this idea of ambidextrous management. You have finite resources, you have infinite demands put upon you.

And what do you have to do? You have to do two things at once. You have to keep the lights on, manage technical debt, and you have to innovate.

You have to run the business, you have to change the business. You have to do these things at the same time. So technical debt is a, is always a nightmare.

And it's often either because of budgetary concerns or because of technical reasons, it's the friction that prevents a lot of, a lot of innovation from happening. But I think that I, I, I think Mitch Freudian slip here because, um, you know, I think of DARPA as sort of being akin to the, the priests at the, the temple of Snx. Uh, I don't know how big of a rush fan you are, but that's a Russian, Oh, Yes.

From 2112. The point is, I want transparency and visibility into the transmogrification of code. Um, if what we're saying is, Hey, we're gonna create this centralized government agency, we're gonna go back and we're gonna rewrite all of this code for your safety.

Um, I want visibility into that system. Uh, not that I don't trust, trust was alluded to earlier, but I don't trust That's the Tom Sawyer of the picture who's talking to other people and yeah, let's go rewrite everything. Right, right, right.

So I get it. I get it. It makes sense.

Um, uh, I would like to see a focus on control system software, frankly. And I, I plead ignorance. I don't know, I, i, I don't know the, the, the frameworks they're generally used there, but the kinds of things that control valves and switches in electrical grids and water systems, uh, those need to be hardened.

I think that would be a great place to go if the constitutional things we ask our government to do are provide for the common defense and support the general welfare. I say, let's harden our infrastructure first before we go out and transmogrify code. A little bit of a tangent there, but so a little, a Lot, a lot of people watching this, sorry.

A lot of people watching this show are now running prog rock lyrics through chat GT to understand what you guys are referring to. Many of my variables, brush lyrics, you know, so just a little perspective on technical debt. There, there are different estimates of this, but you, you can find how many, you know, how many lines of code are, are in existence that are still running today, and the numbers are like 5 trillion.

And literally, that's some of the estimates. So it's really crazy. Any every line of code written that you aren't working on is technical debt.

So that's how big technical debt is. I mean, you may have not have touched it for five years, you may have touched, touched it for a month, but every one of those lines of code you have to maintain is technical debt. So it's, we are building this problem, uh, you know, higher, the mountain's getting taller and taller, right?

It's not shrinking About technical debt. Um, I posted an article a few days ago, George Home wrote, and it was an interesting use case about a company that just decided to get rid of all the technical debt, just wipe it all clean, start fresh, put in all new and completely digitally transform. And it worked well for them.

It was a great return on investment. So, um, uh, I would love to hear your thoughts on should business leaders be trying to just get rid of all that and start fresh in the end? Is it a better return on investment?

I'm curious, Amanda. Um, kind of when I've run it and develop more organizations, you build up all these things that we should do. And at one point it was a good idea.

And oftentimes it's just like, that's actually, we, even if we did that, it wouldn't be helpful. So you kind of cull out, you know, two thirds of the debt that you think you have to do. Did they go through a process like that to really figure out what's meaningful to, to fix and let's just shed the rest?

Yes. Yeah, it was, um, yeah, it was a halt planning process. And, um, and in the end, it, it was, it worked well for them.

I don't know if it would work for all companies to just wipe all their technical debt out and start fresh Mm-Hmm. David, it budgets in my experience are kind of like bills running through Congress and like everybody attaches all kinds of stuff to them. And so if, how many CIOs do you think are gonna say, we're launching an AI initiative and we need this amount of money to go do that, and then they're gonna pull in all this technical debt cleanup effort underneath that because, well, who's gonna check a line item?

Well, I don't know if this tracks, if this tracks with what you're saying, but my, I I'm constantly admonishing folks that I work with, you know, that, you know, that it's very easy to adopt the, you know, the saying that, well, we're considering AI for everything. Our ai ai, our AI strategy is important. It's sort of like a few years ago when people would proudly say, we have a cloud first policy here, which to me, sounds like I'm a mechanic, I have a screwdriver first policy.

It's like, oh, really? So if you see a bolt on the end of a screw first on a, on a, on a, you know, on a net, a net on a on a screw, I'm gonna try a screwdriver first. Why wouldn't you use a wrench?

You look at, that's a, that's a wrench job, not a no, no, no. We always use cloud, try cloud first. Come on.

Fit, fit for function. So in this case, I, I, I, I don't know, I, I think that, um, people, what, what, what I admonish people to do is pay attention to the things that they think are not important. The CIO doesn't have to care about the storage systems, but in, in, in the, in, in the environment as an example, refreshing them.

Uh, but someone in the CIO's organization needs to, because if you optimize infrastructure, if you take your eye off the infrastructure ball, you're not gonna have budget for ai. So by focusing on the things that aren't cool, you free up budget in this finite resources, infinite demands world that they live in. So long, long way to get to the point.

Focus on the boring stuff, to free up capital for the cool stuff. And just really quickly, because Mitch tossed out 5 trillion numbers like that are impossible to conceive, right? But I have an example to just to help the audience.

So this is 100 trillion Zimbabwe dollars. So hopefully that helps. Wow.

To get your arms around what the numbers are. You're a rich, you're a rich man. I, I don't know what it's worth.

I think, I think this is, I think this is worth a dollar. Okay. I think part of the issue here with technical debt though, is I think more people will rewrite code for the following reason is the, the people who wrote that COBOL program from 30 years ago are sitting on a beach somewhere and they're not gonna help me come fix it.

Or, or if they do, they're gonna charge me a fortune. So how many seat level folks are thinking through the fact that there's just a lot of stuff that they're trying to run from bygone days, that there's nobody around who remembers how it works. You know, the, I'll share one experience like that, Mike.

Um, I took over a SaaS product that ran, runs about 93 million transactions a year doing kind of service locator type functionality. net. Several years back.

People wrote it long gone. And there were major sections of the code that we were just afraid to touch. 'cause nobody understood it, nobody what to do with it.

And so when we looked at moving to the cloud and modernizing it, you know, rewriting it was just not impractical. I've tried that earlier in my career and I managed to survive those mistakes and still hear. But, um, what we did was look at, well, let's take the whole monolith application and say, what parts of it really does the business need to be able to add more things to it?

Flex, you know, what flexibility do we need? Where do we need more agility to be able to modify this quickly? And there was one area of the product that really most of the business needs were, were, were being asked for there.

Yeah. There were, you mean hundreds of things across the whole app. So that's the part that we moved to microservices and use containers and Kubernetes and tried to use a more flexible approach so we could add and update it much more quickly.

Saved a ton of money. It turned out to be a, a successful strategy in that case. But that's only 'cause we, we were able to pinpoint what parts of this to the do we change.

So unless you've got something that's so antiquated, you need to re really rethink and write the app. It's hard to justify. Let's put this into rest.

Let's put this into micro. So all those are are tough decisions unless you're just backed into a corner, you don't have an option. David, you know, who makes a fortune on technical debt?

Global system integrators, they kind of launch these projects and then they show up and they move in for a couple of years, and then they announce that they have either succeeded or they just throw up their hands and say, sorry, but they don't give you your money back. I Always declare victory. Always declare victory.

And so the next contract, right? That's Right. So, yeah, you know, 1, 1, 1 quick example that's, you know, we're experiencing in real time in terms of technical debt and friction associated with it.

VMware, uh, look, look at the bluster. People are frustrated. Broadcom comes in and clearly Broadcom's going to ride the long tail of VMware into the future.

Um, if people could snap their fingers and move to something else, they would, largely, in a lot of cases, people would do that, but you can't because of the friction associated with change. And so, so technical debt actually is opportunity for global systems integrators, uh, companies that want to take on these very sticky portfolios of technical debt. It's, uh, it's a mixed bag.

I'll tell you one thing. I am optimistic about all this. 'cause to your point about that, the cost of switching IT platforms is just way too high.

And if we can rely on AI tools to reduce that by making it easier to take some, um, platform that has some, uh, dependencies that are designed to lock you in, and then reverse engineer that into something that is more generic code that can run anywhere. I think the level of competition across the IT industry is about to dramatically increase. Now David and I engaging in some wishful thinking, Well, you could, uh, you could, you know, there's, there's, uh, let's see.

I've, I've, I've jumped, I jumped into the multiverse just for a moment while you were, uh, proposing this. And one possible path I saw was, uh, with all of your good intentions, where we ended up was almost a pharmaceutical industry model where developers in IT had to use patent protection so that they could get enough profit to warrant the work they did to do the development. I, I, I was part of something called the open Data Center alliance.

I don't even know more than a decade ago. Um, and, and, and what the Open Data Center Alliance customers said was, I want perfect substitutions for everything that I do in it. I want the best functionality that the market can deliver.

And I want to be able to grind all of your heads together in a price war to get you down to the lowest common denominator. It's like, well, where, where does that leave room for innovation really? When there's no profit motive in, in, in differentiating.

So it can go, it, it can go sideways. But I, I agree. I mean, the promise of cloud was supposed to be portability.

We still don't see a lot of people moving stuff back and forth. Um, but yes, to the extent we could drive friction out of the system, everyone benefits. So you're basically saying, I will not see a generic version of my IT platform that I can go buy for a nickel.

I don't think so. Not one that you wanna buy for a nickel, not one that's worth a nickel. Yeah.

Don't throw those COBOL skills away, Mike, quite yet. Don't throw 'em away. They're getting more valuable every day.

Uh, we, we just had a show talking about how we're training kids to write COBOL programs. 'cause that's where the money is. Although all the cool kids think the other languages are cool, but hey, somebody's gotta make money.

And if everybody's using AI to write code, maybe you should learn cold ball because AI might not learn that as quickly. Yeah, we will see how all this plays out in the future. But stay tuned as we continue to talking about our next section, which is, well, Google has joined a, shall we say, an elite club.

And we will dive into what that means in a minute. We'll be right back. 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.

All right, folks, as we described, Google is now a convicted monopolist and well, I can't make up my mind if they should be congratulated for the fact that they managed to create this situation and they have enough market share to dominate. And from a investor perspective, maybe that's very impressive. On the other side of it, it's clear that if they eventually wind up losing the 27 appeals, that will probably go through before this thing gets resolved.

Um, what are the implications of all that from a business perspective? David, what are you hearing about this case? I mean, it's been around forever and I think everybody forgot about it.

And then one morning we woke up and there was a ruling. Yeah. And it's not just this case.

There had been many other cases brought in state and federal court, uh, coming after them. I don't know why the phrase convicted monopolist makes me laugh, but I dunno why, but it just, but it just cracks me up, so please don't say it 'cause I won't be able to keep straight face. But, but the, you know, let's take a quick step back here.

What are the point of these antitrust rules? The point is to protect consumers. The idea is that if in a, in a healthy economy, you shouldn't have someone with so much control that they can artificially control prices, artificially put a damper on competition that hurts consumers.

There's nothing illegal about being a monopolist. That's why it's kind of funny to say convicted monopolist. You could have a monopoly if it's a natural monopoly.

If it's like, look, and this is what Google argues. They say, look, our search engine is better. That's what, that's all, that's why people use it.

The pushback is, well, the fact that your search engine is the best, if we stipulate that it got you to a point where unfortunately, with nefarious intent or not, you started to leverage that power in a way that is anti-competitive. That's what's been asserted and confirmed by the court in this case. Now, search engine is directly tied to another lawsuit or a several other suits having to do with ads because, because they're, and those are inextricably tied together because search is how ads are presented and you know, in the two, the two go hand in glove.

So the real question is, how do consumers benefit if the government intervenes to say, Google, you must implement the following policies to prevent these anti-competitive behaviors from happening moving forward. So what does that look like? Well, something like 95% of mobile, mobile devices have as their default browser or search, excuse me, default search engine is going to be Google.

Uh, and that doesn't happen by accident. And so behind the scenes, the question is, is Google exerting too much pressure? Um, you look another layer down and guess who's driving a lot of this?

Is it me and you as a consumer? Are we really that upset about it? Or is it the competitors of Google?

Is it the Microsofts of the world that are pushing back? And generally it's, that's part of the dynamic. And then my final, um, cynical Dave view on this is that, uh, Google just isn't, hasn't been effective enough at lobbying.

They're not greasing the right palms in the way that they need to. Essentially, this is a bit of a shakedown exercise, and I'm sure you're going to see Google participate even more in, uh, political elections, uh, local, state and federal moving forward. Um, but, but does breaking up Google help us?

Like the consent decree that broke up at and t for, for, for myself, probably the only one old enough to remember it on this call. You know, the baby Bell operating systems came out of that. It was, it was chaotic at first, but I think in the end, more choice for consumers came out of breaking up the phone company.

And, uh, but I just don't know what that would Look, I'd love to hear Amanda and Mitch what you think about, what would it look like? What, what, what would, what would the world look like if, if the government came in and said, we're breaking up Google? I mean, what does any Well, you know, Yeah, I posted about this news when it came out.

Yesterday was a huge news day in the world, I tell you. But, um, when that news came out, I was shocked. 'cause I was thinking, what does this do to the stock market?

First of all, it's already starting off badly. And then if big tech, you know, all the other big tech lawsuits that are yet to come, what is that gonna do? But, um, anyway, when I posted that, the responses I got were that they were shocked.

That was crazy. Google was the best search engine there was. I agree.

I use Google the most as a search engine. So if it gets taken away on people's phones or devices, I don't think it's the consumers that were complaining we like Google other than some, some, um, some people don't like the censorship on it so much, but it is the best search engine. And, um, so anyway, that's what I'm hearing.

I don't know what y'all heard, but I definitely don't think it was a consumer complaint about Google other than, like I said, some of the censorship. You know, what I was surprised by, and Mitch, I will get your opinion on this 'cause you know, I'm going way old school here, but you remember payola? Mm-Hmm mm-Hmm.

So let me get this straight. Google is paying Apple a a significant amount of some for the privilege of being a default search engine on their platforms, and they're paying other folks similarly. Um, you know, wasn't that part of the thing?

So, you know, is it Google who's really being at fault here? Or is it Apple for taking the money from Google? And, you know, 'cause that's part of the payola.

It it is every business's objective to monetize what they create, what their advantages are in market. The question is, do you take it too far into David's point where you have, you exhibit anti-competitive behaviors? So are you doing price fixing or collusion with others in the market?

Um, are you controlling something so much about your product that limits what others can do it? So you become such so popular search engine now you not only cut others out of search, but you cut others out of other parts of their business. And if that's substantial enough, the, the real thing that comes out of this, we we're not in the days of the baby bells, which I went through that too.

Very interesting time. You know, standard oil, right? You know, breaking up standard oil, that's one of the, you know, landmark, uh, monopoly cases.

It, it isn't being declared a convicted monopolist, which, uh, I got that title from playing Monopoly, but not from running one. Um, it, it's what the consequences are. And we live in an age where the neur negotiation is, yes, we appeal it, but what are we gonna have to do as a result of it?

We'll change this in the algorithm. We'll change this of what giving it, making it easier sort of for people to choose what search engine they use in the browser. We'll do these things about how ads are, that's where the, the rubber meets the road and the outcome of this very unlikely, you know, the, the, they'll go to cord and say, okay, we're gonna break, uh, a, b, C up into these five companies and do that kind of a, of an impact.

So I think at the end of the day, and, and sometimes these changes that they make are so esoteric that the normal consumer don't know it. Like for example, uh, Microsoft had to do make and part of their agreement with an eu and one of the challenges that they faced was giving others access to direct access to certain things in the operating system. Well, they don't have to do that in the us but they have to do that there.

So it gets a bit esoteric and I don't think for most of it's, most of it we're gonna see. They're not gonna take our browser away to your, to your research engine away, Amanda. Um, we're probably, most consumers probably won't even ever see what the consequences of this are.

And a lot of money will be spent by some very wealthy lawyers. Yeah, I think think Amanda, Amanda brings up a good point about the political angle on this. Yes, censorship.

Um, there are a lot of people who see Google as the bottleneck for all information globally and that that, and that control is frightening from a democracy perspective. And so I think that that then percolates up at least through the legislature. Um, now we're talking judiciary, we're talking about civil suits and, and, and, and things brought by the administrative branch of government.

But, but, um, but yeah, don't underestimate the fact that, that everyone has seen the AI generated images of, uh, of, of what appear to be African Nazis. It's like, wait, what? And so, so anything, anything that smells like bias that's being injected into our lives front and center, that gets people fired up too.

So that's definitely a dynamic. Do you think people will take a minute to think about, I mean, Amanda was talking about Google as being, you know, the best search engine experience. Well, you know, I would argue Google maybe is the best of a bad lot.

Search engine experience has just gotten worse and worse over the years. It's basically now what, five, six ads before you get to the actual thing you're searching for. And, um, Google's been playing around with this algorithm for the last year where it's trying to quote unquote find more helpful content that's more timely.

But when I go look at the search results, I don't really see that I see the same old junk at the top of the list that's from two years ago. And I might be clicking through now to the third window before I find what I'm looking for during a search engine. So I gotta say, you know, all this stuff about how great the Google search experience is, I'm kind of like scratching my head going, well, maybe it's time to get rid of this thing with something better and maybe we should just go to this AI thing that knows better about what I'm looking for.

I mean, have search engines kind of outlived their usefulness? David, I'll let you jump on that grenade. Yeah, yeah.

So I think that, I think that if you ask people to Google, they would tell you that, look, all of this effort is misplaced. We at Google are terrified that we're going to lose our position of dominance. We know about this idea of disruptive technology and that, and that something is nipping at our heels.

Um, I've always been curious, and maybe, maybe maybe there's a way to get this answer somewhere, but it's, but, but what's the value of having access to free search? How much would it cost for me to have no ads? No Google intervention in terms of the ranking of, of items.

Um, what we're seeing is not someone coming up with a a, a better a a a, a better Google version of Google, but no, no generative AI with rag with, you know, retrieval, augmented generative ai where I ask a question and I just get the answer. I don't get ads, I don't get things ordered based on some priority that's giving money somewhere else, but I pay 20 bucks a month, 50 bucks a month to have this very, very effective tool. I think that Google has frankly painted themselves into a corner, to your point, you, you've gotta go down 20, you know, 20 hits deep to get something that isn't an ad promoted result.

So I agree. I mean, we say it's the best it is, but yeah, best, best, best. What it's like, it's like, you know what it is, it's the exit row on a Southwest Airlines flight, right?

It's like, Hey, I'm the president of a third world country. Great, good for you. Um, and, and so I, yeah, I think that the disruptive technology is gonna come from the AI space.

It's gonna be chat based things, uh, where not only are the search results coming in just boom, boom, boom, boom, boom, but there's some logic wrapping them all together. I think that's where the disruption is gonna happen. I think that that disruption will happen way more quickly than any legislation can affect change.

I agree with Ben. I dunno If you had this experience on your phones, but I've noticed the last month or so, I use Siri a lot and that's kind of my, my search engine on my phone. I'll just ask Siri and then the AI will, you know, scour the internet and give me back a response right away, which I have often found helpful.

Now, sometimes it's not the response or any more in depth information, but I like that little AI response at the top when I ask, have y'all experienced that yet? I do use Siri for that. Um, not, not all the time.

You know, I, I I think Sir Sirius sort of the, uh, the, the is is sort of Alexa's sibling that just wasn't blessed with the, uh, mental acuity that Alexa was blessed with. Um, but, but yeah, I do, I do, I do use Siri, but I'm more often frustrated by her because I use Alexa so much and there seems to be a greater depth there. I have a feeling it's gonna be hopscotch, next gen stuff coming from Apple, I think is going to address that.

I think we're gonna see a lot of rhythmic increase in its capability. I think they both need to go to a different school, get some more training, right? You know, so, so we talk about the best, oftentimes the best is the most familiar.

That's why we're very comfortable with Google and how it works. And we, we already know how to do prompt engineering that we talk about in generative ai. We do prompt engineering every day when we type Google search.

We have a way we know that we'll get the results, you know, for certain things if we use it, uh, for that often and up. So to your point, Dave, something else, if something else is truly easier and, and gets me a, is it equal or better results? Just easier to use.

Okay. Now you might be talking about displacing or at least competing with it. So yeah, that's, that is a, that is a, that's a brilliant insight that what's the, what's the easiest ui?

What's the one you already know how to use? Of course. Yeah.

Right. There's no easier than That command line was the best experience when that's all we had. Right?

Do all Right. So I, I'm looking forward to reading the filing that goes something like this, your Honor, we have messed up this product so much that the experience is so horrible that there's no way we could have a monopoly because there's all these new technologies that are about to replace it. 'cause that's essentially the defense.

That their defense, their defense will be, yes. There's, there's, oh, there's a ton of competition in the market. In fact, we're, we're, we're not even sure how we're gonna pay our rent next quarter because who knows what's gonna happen.

But look, the numbers, the numbers at this point show their dominance, but those numbers in and of themselves don't make you guilty. That's the thing. They can have 95% market share as long as they're not abusing the, the, uh, the, the power that they have, that they have deservedly achieved.

And that becomes, that's a, that's a gray area. That's where I go down to sometimes the tipping point is how well you've lobbied Congress or not. You know, I mean, literally the elections in the fall could make a big difference in the way that these things sort of go in terms of scrutiny.

Who gets scru scrutinized and who doesn't. Um, but, uh, but yeah, I think in the long run, um, we are gonna benefit from AI in this case. The challenge is in both cloud and everything associated with search and ai.

These are the highest barriers to entry in the history of humanity in terms of business. This isn't, you know, you wanna compete with the chicken restaurant down the street, it's gonna cost you $300,000 to get your business up and running. Ooh, no, no, no.

This is, this is like, how could you possibly say, if Mitch and I decided we were going to come up with our own version of AWS, um, you know, everybody, I would, I pitch in a hundred trillion Zimbabwe dollars, and then we would need to raise, we'd need to raise a lot. It's, it's, it's an insurmountable barrier to entry only, only a government, frankly could do it. So that's the, that's, that's kind of the difference here.

When you get to the scale of something like Google, who can mount a front, well, guess what? It's gonna be the chat, uh, you know, the chat version. What's the, what's the, there, there's a recent one that there's, there's one that's popular for search duck, Go duck, duck go with Jesus being on the backend, by the way.

Yeah. No, no. But, but, but specifically it's, it's, it's touted as, uh, a chat gt GPT, like engine for search, where chat, GPT Open AI is saying, no, we're not trying to be, we're not trying to be Google search.

That's not us. That's, that's beneath us. Um, but there is, um, I, I should have it on the tip of my tongue.

People are starting to reference it. I'm starting to get links from this search engine, if you will, which is a AI driven search engine, By the way, I see your a hundred trillion Zimbabwe dollars and a Reju eight quadrillion. There we go.

Oh, okay. I, I'm out done. I should never, I've learned, never bet against That.

Amanda. Amanda, you're worried about what the market does. Just gimme a call.

I got you. Go. I just, I just got these $9.

We're gonna close this up here now on two thoughts. One is all you folks in Zimbabwe who are angry, direct your email to David. And then the second thing is, hey, just remember a couple of decades ago, we were all flipping out about the dominance of Microsoft.

And now look at the world today. There's NOS is everywhere. Linux dominates in the server side, and we were all using Google apps in the cloud rather than Microsoft office on your desktop.

So the world is changing, and it will change, and the market will decide and vote with its feet. Folks, I wanna thank you all for being on the show, and I wanna thank you all for watching the show today, and we'll be back with some additional content for Techstrong tv. So stay tuned.

I'm Bonnie Schneider, sustainability contributor to the Techstrong Group. I'm excited to introduce you to a groundbreaking new initiative from Techstrong Research, the sustainability pulse meter. The Pulse meter offers valuable insights into how environmental responsibility factors into tech purchasing decisions for key players in the industry.

Position your company as a leader in the industry and differentiate from your competitors with a sustainability pulse meter offered exclusively from Techstrong Research. This is Textron tv. Hey, everyone, welcome back here to techron tv.

You know, I've got a actually first time on new company to introduce you to. Very excited. I wanna introduce you to Ari Zuka.

Ari is the founder and CEO of a company called My Decisive. Uh, first of all, Ari, welcome to Tech Drunk tv. It's great to have you here.

It's great to be here. I'm super excited. Thank you for your time.

No, thank you. Thank you. We we're here every day.

You wear the warm, dragging you in. But anyway, Ari, it's, I often like to do with these things. I like to give people a sense, you know, everybody wants, has the dream of being a founder, of starting their own company, of, you know, reaching the top of the mountain, raising money and exiting, or going public, and it's all very sexy, but it, the, you know, the day in, day out, minute by minute, hour by hour is, is more like a war.

Um, and people always say, you know, how did he do it? How did she do it? Give people a sense, maybe of, of your journey here, how you come to be the founder, CEO of my decisive.

Sure. Happy to. I am here through a long path, almost 30 years, that traverses open source, it traverses data management and it traverses large scale production systems.

Um, I think one of my investors put it best, like the, the, the reason I was able to get funding to get where I'm at is that I wa I represent three experience sets, right? And I love this was, uh, one of the founders of one of the big VCs on Sound J Road. He's like, I like you, Ari, because you sold other people's software in your past.

So I used to work at like s Sapient, Pricewaterhouse and New big consulting gig. Dude, Those are big, those are names I haven't heard and have been shape yet. Yeah.

Then I, I sold other people's software. I built my own. com, founding Chief Architect.

And, uh, so I've built my own and I've run big production systems like Walmart. So, yeah. Uh, at the time I was at Walmart, it was the number two e-comm site in the world.

Uh, I think it still might be though, or it's gotta be about five. Might be, It might be. It's, it's definitely top five.

But we were in year 2000 doing a billion page impressions a day, and that's really where I got my focus on data. So we were paying Oracle too much money. I decided, let's go.

Oh, I mean, we were mostly open source. I didn't decide, but, you know, I took the open source we were using and started bending it and twisting it to get to crazy scale. And, uh, that led to terracotta, which led me to hang out with the open source gang, which led me to Hortonworks, which led me to try my hand at vc.

I was at Coastal Ventures as a partner for a while, and so how did I get here? Uh, it's good news, bad news. The good news is work hard and you get rewarded, right?

Do what love you get to do it for in the big time. The bad news is, it's sort of an in the family kind of thing. Like, uh, I got a couple of jobs through pure grit and then ended up in a place where I was inside the family, and people are super helpful to me at this point, But you know what?

That, that's not unique either, either, right? Right. Um, it is, it is about network.

I mean, I look, we'd like to think we live in this meritocracy where, you know, everyone gets treated equal. Every idea you send into a VC gets looked at Mm-Hmm. You know, with due diligence and, and the time it deserves.

The fact of the matter is it's still a lot of who you know. Yeah. And it's not just a Silicon Valley thing, it's a, it's just the world of business thing.

Yeah, It is. And, um, you know what I like about it though, Ari? Because too many, so many people think, oh, founding a startup is something for 20 something or early 30 something Euro olds.

Right. Because, you know, what is it, what is a guy in his forties or fifties? Mm-Hmm mm-Hmm.

But yet, and I've seen studies on this, founders who are a little more seasoned, who are a little more experienced, who have the kind of resume you have can do a better job. Right. It's not like they, they suffer from a lack of ideas, but they also have a ton of experience.

Yeah. And you know, there was a time where some VCs, I think definitely, I don't wanna use the word discriminated, but definitely preferred, you know, younger, first time entrepreneurs. Mm-Hmm.

But I think that's changed. I think people realize Mm-Hmm. Totally Right.

People with experience do it. So I, you know, I wasn't always on this side. I was on that side of the camera a lot in my life too.

I started several venture back companies, co-founded. Right. Um, and I've been interviewing and talking to entrepreneurs for a long time.

Everyone I know who started a company, Ari thinks that in some small way, their company's gonna make the world better. Mm-Hmm. Make someone's life better.

Mm-Hmm. And they're passionate. They're passionate about what they're doing.

What's the passion behind my decisive? Oh, wow. I love that question.

So, look, I haven't defined by decisive. Let me define it quickly. Go ahead.

Good. Yeah. Super geeky terminology.

It's composable observability. In, in, in essence, observability just went through an inflection point. New Relic, Datadog, Dynatrace, big public companies, one of them went private recently.

Customers are paying millions of dollars a year each for this technology, this for this value prop, uh, observability. If you look at the debate about its definition, it's very much defining, uh, a state of a system, a quality of a system. I can observe without knowing the source code, without editing the system.

And that's very passive to me. I want to flip to active. Why do I wanna flip to active?

Now I can answer your question. So if, uh, I wanna flip to active, because data matters. Okay.

And specifically Oracle Cybase, these guy Postgres, these guy Ingress, these guys grew up taking control and making real easy, low cost, commoditized use of business, state sales orders, customer orders, inventory, state, they know financial transactions. They record the, the state of the money and the, the people and the processes. Then came Hadoop, big data.

I was part of that movement. We were basically taking the log data that Splunk made supervi popular. We were turning it into understanding value.

Right now, you have two pillars of data. You have the business processes in Oracle. You have the user behavior in big data in Hadoop, in data lakes.

And it tells you Ari's worth more than so-and-So, because he will tend to buy more and more and more from you, that analytic couldn't be done in Oracle. So here comes Hadoop. There's a third pillar of data, and New Relic and Datadog missed it.

That third pillar of data is telemetry data. It's the behavior of your systems. So you've got your processes, you've got your users, and you've got your systems.

And all you can do with observability vendors is push all this data to them and then chart it. You can chart very basic things about it. Composable observability equals your ability to take over the data flow and turn it into answers for you.

Like, is this piece of software secure as it's releasing to production? Is this system in the correct region in the cloud? Or should I move it closer to my users?

Where are my users? What is the latency right now? If I move it, do I improve things?

Should I scale up? Should I run bigger instances, smaller instances? Can I run at 60% CPU or should I try 90% CPU?

That would be a 30% savings. Composable, observability equals the, uh, equals the human ability to take over telemetry data, treat it as the third pillar of business, your system's behavior, and let it answer questions for you that no other data can answer for you. So why am I passionate?

Because I'm staring at an opportunity to create the next Oracle. I love it. Think, don't think small.

Thank you. Don't think small. Thank you.

Now, but something a little different about your vision is it's a lot more open source based or open source friendly than let's say, uh, Oracle is, even though Oracle, you know, well, let's not even get into their record. I don't source. Um, and, and that's an interesting thing.

You know, you said that observability hit an inflection point and it did. But to me, you know, I look at some of the companies, but the New Relic, uh, you know, all the, the companies you were mentioning, and though they may not have started as big open source advocates, the fact of the matter is Datadog, all of 'em, when you look under the hood, they're all using Yeah. A lot.

They're all based on a lot of open source. Yeah. I'm gonna assume that my decisive is too, but you're just more open about it, right?

No pun intended. Um, you know, open telemetry, Prometheus, all of these kind of mega projects that are just wow, you know, going bonkers. Yeah.

Um, is the main thrust of, of my decisive to help, like pre-release to make software better at release? Or is it more sort of a traditional, let's say New Relic? com 10 years ago, right?

New Relic, AppDynamics, these were a PM application, you know, uh, uh, management, right? Yeah. Yeah.

We don't call them that anymore. Now they're all observability. But to me, there's that sort of observability, sort of the right side of the deployment line.

Mm-Hmm. And then there's observability to the left side. To the left side.

Yep. What do you, where, where's my decisive? Like We are, we are focused right now on the right side.

Um, mm-Hmm. When I did my tour of duty in the observability space, I pushed really hard for shifting left, um, and giving clear visibility into the software lifecycle. And in fact, there are notions of grading teams like this team service is an A, that team service is a B.

So that teams with an A Grade can move through software lifecycle automatically, and teams with a B grade have to have like human approval processes for releases and can only release at a certain rate so that they don't destabilize too much. Uh, I'd like the left, uh, side of the equation. It's very powerful.

Uh, but, you know, to, to answer why are we focused on the right, why are we going back after, as you pointed out, a PM observability? Do it yet again? Why once more into the fray.

Um, the answer is in the question you asked, right? These guys, they were a PM. It was all about a language agent that quickly and very lightweight, sent a bunch of telemetry somewhere else, and then loaded it up on a graph.

Now we have all this open source power open telemetry Prometheus. People are assembling an alternative to vended observability by hand. Every single company is doing it.

And they're jumping down a path of copycatting, of ended solutions. So let me get things to graphs. I met with a company, and graphs is not the end game, man.

We're in the world of ai. We're in the generation of ai. You shouldn't be staring at a graph.

You shouldn't be getting paged at night and being told, you know, you're slow. You should be waking up in the morning reading the news from your system, telling you that it took a couple of autoscale and migration events and restart events to keep your system up or to prepare it for the next day. That requires much more mastery than these vended solutions are prepared to, to offer.

They, they've made a mistake they built 16 years ago towards a charting and graphing in a human-centric incident response use case. And that mistake has buried them down in the, in the muck of alerts and human Paging and Slack interfaces. And they cannot now pivot to control and add value to the enterprise around Open telemetry and Prometheus.

So, yeah, I, I am basically saying open source has given me a foundation, a platform on which I intend to build this composable observability at my decisive. You can have it for free. Why am I open source or open core?

I have to be, because no one knows that this is necessary. Yet, once you hear it from me, uh, your audience hears it from me, they'll go, oh, I would love to join security feeds or vulnerability feeds onto my production deployment flow and say, whoa, yellow alert, this application has unsecured libraries in it. Are you sure you want this container image to go into your registry?

True or false? Yes or no Human, uh, interaction required just at this step that, that composition, I built a product that does that. I built a security product two years ago that took 20 people a year to build on one of these vendors' platforms.

That's ridiculous. It's ridiculous. If it takes me a year as an expert industry internal player with five years experience and mastery of my platform and total control of the data, how are you as an end user supposed to crack open this black box platform and build it for yourself?

It's impossible. That's why this stuff turns into shelfware. Yeah.

No one's starting these projects. They're looking at the, the open source and saying, wow, that's a huge hurdle compared to New Relic or Datadog. And yet the open source unlocks the power in the data.

And so all I'm doing is saying, I, as my decisive will create an open platform. Everyone will be able to get access to the data, whether it comes from New Relic, open Telemetry, Datadog, Dynatrace, Splunk, I don't care. I'm gonna open up the data and then you're gonna be able to prepare it to and tailor it to your use case to your need.

And I will, of course, build tailored solutions on top of it. That's how I'll make money. Absolutely.

Well, the, the fact of the matter is, when you go under the coverage, even the New Relic now, and, and there you duck, they're using toca telemetry and and so forth. They're just putting their front ends on it. Yeah.

And because at, and that's the beauty of open source, right? Like this foundational model of open source where it's not controlled by any one vendor, right? Yeah.

Which is a little different than maybe it was in the early two thousands. Um, you know, everybody gets that foundation, that base, and then what you do, what you build on top of that, that's where you distinguish yourself. Yeah.

But everyone can get the Prometheus feeds. Right. And what and why if Prometheus is so widespread, why do I need to get another agent To Exactly, exactly.

To, to use that. You mentioned day AI though, and that's something, you know, I have a lot of friends in the DevOps space especially. I was talking, and I was at the dinner the other night with some, the feeling is that, and I think you hit it on, why do I gotta get woken up in the middle of the night?

Let me just wake up in the morning and see what, see what it did for me. You know? Yeah.

The feeling is that adds this gen ai, you know, continues to evolve. Is it a lot of what we are seeing from some of the vendors you mentioned, not, you know, bad mouth, any of them. They're toast.

Yeah. Right? Yeah.

Um, it, it, I mean, it's, it's a, it's a changing world. Yeah. Very big change in that part of the world.

Yes. You agree. Totally.

I, I mean, one, the, the vendor I came from, we had two AI solutions. One I built one a peer built, and the, the peer solution worked in some use cases. My solution worked in some use cases.

The punchline is like, I spoke to a giant telco last month, and they're like, I'm out. I, I tag out on all this AI ops, it's not working for me. And, and my lesson learned, and what's what's gonna become powerful about my decisive is one size fits all doesn't work.

Especially in DevOps, right? You can't say, because this Oracle database over here went down last week at 85% CPU, that you should re auto reboot every Oracle database at 85% CPU, your, your business will grind to a halt guaranteed. Right?

And so the action loops need to be programmable. Like, should I re autoscale? Should I upscale?

Should I restart? You need to have pluggable logic. You need to have more than that though.

You need to have pluggable algorithms. Like, I want to use a different algorithm for checkout than I use for sign in. They're totally different services with totally different architectures.

And the math is different for them. And the signal set might even be different. This uses CPU and memory 'cause it's very hot that on those resources, this uses database latency and something else.

How is a general purpose vetted solution supposed to build all this flexibility? You need to take control. You need to take control.

AI is where you're gonna get scale. So first I, my decisive gives you control back. Let me feed these signals to these algorithms for that service.

That's impossible today. Impossible. And the vendors can't get there.

'cause they built a one size fits all architecture, and they, if they start routing fine grain signals to fine grain processing logic, they're dead. They can't scale. So I push it all back to the customer, give you cloud automation, stand up your own Kubernetes and Prometheus clusters that can make all this decisioning for you.

That's where the AI in my company name comes from. My decisive AI is we're gonna let you put all the intelligence back near the, the data where it's low cost, it hasn't left your envelope yet, and you can make hot, high grained or fine grained decisions about what to do with each opportunity to your business. The simplest example is AI ops.

Like I will eliminate AI ops over the next 10 years is my prediction by giving people the ability to say, I have an ensemble. I have 20 or 40 algorithms and I have 10,000 services. And where the AI comes in, is it intelligently maps, which services need what algorithms.

So you can trial everything and you get scale of decision support. Like, let me try 20 different algorithms and see which one predicts outages best. Thank you.

My decisive. I'm now staying up more and I have fine grain control over what I'm doing at every piece of my infrastructure. Got it.

I love it. Good stuff. Hey, you know what?

We never get, you mentioned my decisive. It's actually my decisive ai. We didn't give people a website.

Shame on us. Yeah. Rh how, how can, how can they get on board here?

Absolutely. org, just my decisive one word. ai, uh, it'll give you documentation, it'll give you direct links to the GitHub repos.

Again, it's open core. So you can get to the source code, you could build it, you can manipulate it, and you can, uh, use the free commercial offering as a push button. Just go like, you give it your AWS access keys.

It'll stand up and open telemetry cluster, put you on a console and let you start taking control of your data in under 30 minutes. My decisive. I Love it.

Yeah. There you got it. Ari, thank you so much.

This is your first time on text on tv. I really hope it won't be the last come back and keep us posted. Yeah, Yeah.

I will. I will. This was wonderful.

Thank you for your time. Thank you. Ari Zilker, founder and ZCEO of my decisive.

ai. You know what, Larry Ellison started like this. Who knows, Ari.

Thank you. We'll see. We'll talk again soon.

Thank You. Alrighty. We're gonna take a break here on Text Drunk tv.

We'll be back in a moment. This is Text Drunk tv. Hey everyone, welcome back here to Tech Drunk tv.

You know, I'm honored. I got, we're gonna give this guy a start. I believe he's the first Chief AI officer we've ever had here on Tech Drunk tv.

I was wondering how long it was going to take. I'm trying to think in my mind, what do you, what do you, how do you call these guys? Are they c Chao?

Right. CAIO, like Chow and Italian C Chao. Uh, or just C-A-I-O-I.

That sounds good. I don't know. We'll ask him.

Well, let me introduce you to Flo nor Colo, uh, Jr. He's the chief, a i officer for our friends at Zscaler. And you know, Zscaler always tries to stay one step ahead of the pack, so why wouldn't they have our first Chief, chief AI officer on here, Claudio, uh, I hope I pronounce this right.

Nice to, uh, meet you. And it's nice to have you on the show and welcome. Thank you.

Very nice to be here today as well. Yes. And, and People, me saying that I, it could be Kyle too, which is like a name not for the Chief AI officer, Uh, Kyle too.

That's right. It could go that way. Claudio, Kyle.

Um, I like ciao. I kinda like, you know, it sounds good, but see, I guess I, time will tell, maybe Garner will come up with, 'cause Garner loves putting out names for things, so, we'll, we'll see what they do. Um, Claudio, you, you know, how does one, what's your path to becoming Chief AI officer here?

Have you been working in AI for 30 years? Probably not, but tell tell us a little bit about your, your background. Yeah.

Uh, I basically started my, uh, uh, work after my PhD at Stanford working on, uh, software engineering and for semiconductor. And I worked with 20 years. I actually sold two companies, toss design systems.

And then at some point I decided that was a new wave coming up with machine learning and deep learning. And then I actually founded a company in Brazil back then, and that company was sold to the second largest bank in Brazil. And then, like, uh, that's how I started.

I moved to deep learning. I was a researcher at Google. And then after several, uh, jobs, I, I basically was invited to join this wonderful company, Zscaler.

Excellent. What a great, what a great career. Congratulations, Steve.

Man. That's, that's interesting stuff. You know, it's funny, I have a friend of mine, John Willis, one of the guys who started the DevOps movement, and he, he's written a bunch of books, I think seven or eight books.

His next book he's researching right now is actually on the history of ai. 'cause people don't realize, right. A lot of this, a lot of what we see now, or we call AI has its roots in research that's 30, 40 years ago or more, right?

I mean, back to touring and, and stuff like that. And, um, you know, which is probably closer to 50 years ago now, and well, if not more than that. And, and so everyone says, oh, it's this brand new thing, flash, you know, flash on the pan.

But no, this has been something that's been building, you know, for decades. And, and we're just now starting to see sort of the fruits of that. It it, it's very interesting because I built my first copilot in 2015, 2016.

That was before transformers or large language models were even like alike And Yeah. Or even a thought. Yeah.

In my entire career, I have built like four co-pilots and, and I have been following all the, the, the trends in the industry with this. Yeah. Well it, you know, it was interesting to me is everybody calls it copilot and it, and it rightfully so.

It's, you know, it's not a trademark name. I think it's just a term of term of art now, um, or near our audience knows Zscaler, but not everyone. There might be some folks who are not familiar, if you would by just give them a little bit of, uh, of Zscaler background, if you will.

Okay. We are, uh, the largest company that has the largest, uh, cybersecurity cloud in the world. We process over 400 billion transactions per day.

And you have to imagine that when we have to process so many transactions to protect our customers, we need to breathe ai, we need to automate with ai, everything in our flow. So since the inception, since the beginning of Zscaler, we have been AI focused. But of course with ai, we are basically advertising that more.

But we have always been processing with ai our logs to protect our customers. Absolutely. And, you know, but those are not familiar.

Zscaler was founded by a fellow named Jay Chaudry, sort of a legend in the security space. He's had two or three successful companies prior to Zscaler even. Um, and they've always been at the forefront of, of especially cloud.

You know, Jay, Jay had some real great notion of where things were going 15 years ago and, and they turned out to be dead on. And, uh, more power to me, as you mentioned right in the beginning, it's, it's really quite a company. Claudia, though, today I wanted to talk about protecting organizations against potential vulnerabilities with gen AI apps as well as, you know, we're, we're all setting up these gen AI environments to help us, but those need, you know, you can't, you can't fight the next war with, with Last War's weapons.

Those need their own defenses to secure these environments. Talk to us a little bit about these, if you can. Yes.

Uh, generative AI most, when people talk about generative ai, they're mostly talking about LLMs these days, large language models like GPT. And they have been here to change the way we interact with software and with systems that they had. And that brings a lot of, uh, uh, benefits.

But you have to understand that the bad guys, they will try to also to use that to their benefits. I remember when chat GPT was up an app appeared called Chat GPT on Apple store. And I, upfront, I was the first one to sign in, and then I realized they did not come from OpenAI.

And that's one of the problems that you have people starts to impersonate open AI or ro or one of those, uh, large language model providers and to try to steal your data whenever we interact with the systems. And this is just one simple way people can do that. Uh, another way that people can do, they can, entropic has basically said that people can, uh, put slipper cell behaviors and with a keyword that they can trigger a different behavior of the large language mode.

Right. That, that's absolutely, you know, I was recording a text Drug Gang, a show we do on text drawing TV every morning. Uh, prior to coming into this studio, I was in the tech gang studio on the other side of my office, and we were discussing was an article up 72% of respondents in a survey that they, they don't interact with AI at all.

They've never interacted. They don't use ai, they don't interact with ai. I think the problem is, Claudia, is people don't know, I I say nonsense.

They're all interacting with ai. They don't realize it every time they do a Google search. The, the first result now is AI generated.

Um, so much, you know, there, there's, there's more to AI than chat GPT or philanthropic for that matter, right? Anthropic has a great AI cloud cloud and um, you know, it doesn't get maybe the publicity that the open AI folks get, but that IGPT gets. But there's more to this gen ai.

I mean, it's the co-pilots that are being built into everything we're doing now. And I don't know if people recognize that that's gen AI too, right? Even though it's not, you know, we talk about LLMs, well, we have s SLMs too.

We have small language modules, we have different LLMs, you know, and you can have a front end that plug a front end, uh, AI maybe that plugs into different LLS and so forth. So there's, it's not just the chat bot anymore. And when we talk about having to secure these environments and secure, you know, the, the, the gen ai, it's not as simple as just, you know, securing a chat GPT chat bot.

Yes. Uh, I'll, I'll give you an example. Suppose that we are on a video call and you want to turn on, for example, like captioning.

Yeah. You don't know if captioning or to translation from Japanese to English or to any other language, you don't know where that sound is going. And you may have confidential information going around, and yet you may realize that you have been leaking out confidential information with that.

So it's, it's becoming much more complicated than that. And as Jay likes to say, we need to, to have like a comprehensive and holistic approach to this. And to add visibility, we need to have visibility and the user needs to have, our customers need to have visibility on how generate, uh, uh, gen AI is being used so that we can protect our customers.

Yeah. I, I agree. I mean, me personally, I don't allow, like, you see those in Zoom a lot, right?

Uh, note takers and all that. You don't know who they're sharing that with or where it's going. I I, we have a policy here.

We don't, we don't allow it in our Zoom. Whether people do, and I'm not on, I don't know, but you know, the policy is we don't allow it. Another thing though, quite frankly, that we're seeing Claudio, is I'm unrealistic expectations of, of how quickly this technology is going to do all of the great things we think it's gonna do.

And so as a result of that, it's kind of human nature, you know, we say, ah, it's a failure. It doesn't work as good. I don't know what the only excitement was.

We, you know, it's like, and that's a Silicon Valley thing. Very impatient, right? Yeah.

Well, look, we've invested billions of dollars. I understand. But this thing, you know, I think it is gonna be game changing, but we gotta give it time to grow into that.

We can't, there's a lot of people already ready to throw in the towel. Yeah, it, it, it's very interesting what they're saying. I published, like in the beginning of this year, a blog called the Miko, LLM, there is a book 50 years ago from Brooks on software engineering.

It was called the Mid Command. And this book was one of the things that Brooks did. He was the first one that says there's no magic bullet when you develop software.

And in LLMs, people think that LLMs are bringing the magic bullet, but it's not. You still need to bring a lot of software and a lot of tools around it. As you basically said before, Dell Labs are not a norm.

You need a lot of software systems around connect to database to connect to real time data, even to do search on the internet to be able to, to get something done. And, and there's a lot of risk to do that. Imagine that one of those databases compromised.

So all of a sudden, even if the LLM is not basically getting the wrong, it has not been compromised, but your responses are going to be compromised. Sure, sure. Well then there's also, when we talk about LLMs, like log real large LLMs, you know, garbage in is garbage out too, right?

So it, it, it's not that they're not even necessarily compromised by a bad actor at the point where you are interacting with it. It could just be there was compromised with bad information from the get go. And, and that screws everything up.

So I, I guess my question then is like, we look at Zscaler, right? Zscaler, their claim to fame originally was they would run any kind of executables and code you were getting in a, in a safe sandbox in the cloud before it, you know, got onto your, uh, infrastructure. How do you do that with AI stuff?

So we recently announced that the ZDX copilot, and one of the things that we did is basically to change the way that we interact with the software. I'll just give an example. Before, whenever you have to learn a new software used to have to point and click and the interface, remember how many years it took you until you could learn how to use Excel.

I still don't know how to use Excel proficiently, But yeah, either not when it comes like pivot tables and stuff like that, I'm not good at. And, and, but it takes a lot, a lot of time and, and with our copilot in ZDX or basically have like this approach that you basically ask what you want to do in, in lateral language, and then we detect the user intent. And with that we basically direct to the right user interface widget and then represent that to you in, in simple terms.

And this is one of the examples on how we can make the generative AI interface or, or, or, uh, uh, use case for better. Good. Okay.

Excellent. Excellent. Um, I, I need to ask you this and I apologize, Claudia.

How will, how long has the, have you had this position with Zscaler? Actually, uh, less than a year. Uh, uh, this has been like the maybe 10 months at right now.

Yeah, I was gonna think even less. 10 months is a long time. Where do you see, how do you, first of all, do you see more people, do you foresee more people with this title, with this position in other companies?

Actually, yes. If you would be amazed how people don't understand how this technology is going to be changing the world. And we need someone to think in strategically on how AI can be used in all parts of the organization.

And even to bring new technologies. 'cause things are changing very rapidly in this field. Absolutely.

And, and, and to, to build a, and to, to bring AI to the companies. Absolutely. You know, um, I I think it's, this is a much more enlightened approach than the people who, six months ago we were reading, were saying, oh, we should stop AI development.

You know, there's a potential danger here. Let's just, you know, slow down. That's not human nature, right?

We didn't slow down when, when we found out there was a new world to, to conquer or new places. We just don't do that. That's, you know, that's not what humans are about.

So I think having a chief AI officer who, who's tasked with how to best use this, in this case with security, but in whatever it is, I, I think we're gonna see more and more people with that title. And you'll be a trendsetter there. One of the pioneers again.

And, and one of the things that I'm doing here is, is to think about how the company is going to look like in 2030. I I say 2030 because it's like a, a, a round number. But I say things are changing so rapidly that we need to figure out if I need to retrain our people or, or even if you need to acquire or or by meaning acquire, I mean, not on acquiring companies, but to, to Acquire upskill them.

Skillset. Yeah. The skillset.

Yeah. No, again, I just had this conversation in the text drug gang show today. 'cause there was another article out of a, of a report that due to ai, it's causing more burnout of employees because it's putting a lot of pressure on them with stuff we don't know it.

Look, God bless you. If you could see the 2030, I would be, can you see the 2026 even would be good, you know, but, uh, and there's no doubt that the impact here is gonna be huge. And, and I know people are impatient now because, you know, they've already put so much money in, they want to see results right now.

Um, I think the the best is yet to come. So it's gonna be an interesting time. It is, It is.

It is. And yeah. Claudia, I'd like to thank you.

We're about out time, but this has been great. Thank you for coming on. Say hello to Jay for me and to all our friends in Zscaler.

Keep it up, come back on and keep us posted as this continues to develop. Okay, I will. All righty.

Thank Opportunity here. Thank you. Ni Colo Junior Chief AI officer at Zscaler here on Dexstar tv.

We're gonna take a break. You'll be right back. Hello.

There it is, uh, John Willis. Uh, the presentation today is called Dear I-O-C-I-O. And, uh, and most of you know me, or if you don't know me, I could primarily go by boop or John Willis DevOps on LinkedIn if you're looking for me.

Anyway. So, uh, one of the things that, um, has prompted this, which was, I think we went back 10 years ago, maybe a little less, you know, it was probably maybe seven years ago, if I'm being a little more accurate. We, uh, we were concerned about, like DevOps had been sort of in process.

We were doing a lot of great things and then we sort of felt like we didn't, like explain what we were doing very well to auditors in large banks. And so we wrote a paper called Dear Auditor, and it was, it was very much like an apology letter and like, man, I wish we would've thought about this, but now we're gonna think about this. And, and so we were a lot of us in DevOps and you know, for those of you show, we ran a, the first dev DevOps generat of AI hackathon with Techstrong Van Book Raton last year.

It was great. We brought in a lot of DevOps thinkers and, um, and we started thinking about like, not only what does it mean for DevOps, what is it, what does it mean? Like how can we create opportunity in some of this new generative AI stuff, you know, that, but what, what, you know, I think some of the conversations like what is it gonna mean for life of people who support?

And then that conversation has continued to the point of like, we are realizing that the technology is very brittle. It's expansive, and it, like, I I kind of joke that there's a technical debt tsunami coming down to the people who are basically in charge of protecting we're protectors, you know, DevOp dev, SecOps infrastructure and operations, SRE. And so we started recently thinking about, uh, part of Gene Kim's organization creating this paper called the sort of Dear CIO.

And then what this one is, is, dear CO be beware that if you thought shadow it was bad, wait till you see what shadow AI might look like. So that's basically what this presentation is about. And so I wanted to walk you through, um, some things that to sort of be, to get to the, the technical debt tsunami, talk about the threats and maybe some suggestions of how, you know, not answers, but like the questions that you should be thinking about.

So first we'll go through an introduction. If you don't know who I am, I'll try to go through that reasonably quick, but, but I'll keep it germane to like why I am telling this story now. Um, and then we'll go, I think there's a, an opportunity for us to get level, set it on, on what, what are the sort of the componentry of these things that we're gonna have to support.

So we just say chat, GPT, or we talk about lang chain or, uh, rags. So I, I, I, I little section on that. And then I wanna talk about like the potential technical debt.

What does this mean? What have we learned in the past? What should we be thinking about?

And then threats and, and scope. com right? Know that I've written about, I dunno, somewhere in there.

I think I, I'm working on my 13th book right now, which actually is the history of ai, which is gonna be a blast. Hopefully that's sunny in the year. I've written a number of books over the years, probably most notable is the DevOps handbook was co-authored.

We also created some papers about sort of devs stack outsource, specifically what we call DevOps, automated governance. And then I've had a passion on Dr. Deming.

So I've recently, uh, in, earlier this year, the, the the paperback version of that book came out. And I've worked for a number of companies. I've had like 10 plus startups and, and I do work very closely with, uh, the great people at Techstrong ai, and, uh, and on a couple of vendors.

Now I've really, oh, for almost two years now, I've been very focused on sort of generat AI as it applies to DevOps. What are the solutions that we can solve in our domain? And more recently, what are the problems spaces that we may encounter?

IE shadow ai? And so I've actually gone out and solicited myself to a couple of, like, I pick my clients, my clients don't pick me. Um, so I tried to find a nice compliment of clients, um, starting with Mongo dp, they have a vector database, we'll talk about Atlas Vector database.

So I've been really focused on that. I feel really comfortable with their products suite, their management and their leadership in the enterprise on the right hand side, uh, an open source project called Phoenix Arise. This is observability.

And we'll talk a little bit about the difference between observability and gen AI versus sort of the way we think about, you know, cloud native computing. You know, so it's a different, it's different. It doesn't measure latency and performance at latency, correctness and hallucinations.

And so we'll talk more about that. Uh, uh, also a hedgehog, which is interesting where I didn't see myself working with GPUs, but as I learned more about training models, um, I found that, uh, this hedgehog is, you know, very much, um, what they call, um, composable infrastructure. And it really is the way, if we're going to have to run on-prem, we're gonna have to have network configurations, configuring GPUs and all the sort of software defined constructs that we have to do for networking very complex in this world.

And, um, the, the, uh, Mike Dekin, who is the creative a CI for Cisco, who's a CTO over here, and like a joke when Mike Devo and asks you to help him out, you say, yes, he's a brilliant man. And then last but not least, is another tool that really covers the operational side of this stuff. The people who wrote, um, rancher, uh, created a new company called Acorn, and they focus in on something called GPT Script.

So this has been a great mix for me to learn, produce more material, and help you to the extent that you'll enjoy this presentation, you can thank them for helping me learn from a lot of their technologies and their brilliant people. So like, why me? You know, like, and I, I and I, I've said this, I, this is a joke that I used to bring out in the early days of, uh, sort of cloud.

And we said that we're sort of like operations people or people who worry about infrastructure operations or protectors, if you will. Uh, we're like cicadas. We literally, um, the world gets really messed up.

We sort either wake up or maybe now they listen to us and we have to clean everything up. And I, I realized that I've actually been doing this for five decades. I actually started in an, I mean, I actually started in the eighties with mainframe stuff, but my first sort of transitional next gen big problem that I tried to get involved is where, where, you know, back in the day you had data centers with mostly mainframes, but some distributing computing.

And you just had this consoles and you literally, as many humans as you could put, the consoles always were like a four to five, to one 10 to one RA ratio. And so a lot of us created this idea of like, how can we automate the things you see on a console? It's called automated operations.

And the point I wanna make here is in every one of these next gens, you kind of, there's sort of like, if I'd love to create a bar chart where there's the promise of the next gen delivery, there's the actual fulfillment, which is somewhere between 50 and 60% best case. And then there's a level of technical debt that like gets left behind. And then as you get to the next generation, which is the two thousands, which probably most of you are familiar with, just start configuration management.

I used to call it configuration imagination first generation. But then you have the, the CF engine puppet chef, then to Ansible really sort of infrastructure's code, right? Which, which sort of took a lot of the conversation, really created commerce.

Like maybe the cloud couldn't have been as successful without it. Again, think about that stack chart of the promise, the delivery, the technical debt, and meanwhile the prior generation, the technical debt is compounding. Then we get 2010, the, the, the, uh, that whale character that I'll just call it proposal infrastructure, but containers, platforms, Kubernetes, all those things right here, again, the promise, the delivery.

And at each level, you're having compounded technical debts. We never actually complete the debt. The gap between the promise and the, uh, delivery is always significant enough.

And then we're always compounding technical debt. Now we're in a another one where I can guarantee you, as great as these things are, and I'm big fan of generat ai, I mean, I've, like, it has changed my life. I've redirected my career again in my fifth decade of doing these things.

Um, but the point is, I can guarantee you there's gonna be a promise, a delivery, and a compounded technical debt, including all the past generations compounding, right? So I wanted to stick that in the back of your head as we go through this. You know, dear, CIO, you, you know, this is a repeatable pattern.

And you know, and I think you know this, I, I, I was doing some research and in fact the, the, uh, Einstein quote is actually misquoted. It actually is from a, um, environmentalist, um, feminist called reader. Mae Brown is insanity, is doing the same thing over and over, expecting different results.

And it actually goes back to like the 18th century. But, but she's the sort of the canonical, uh, citation quote. Alright?

So, so that's the intro. And then I want to talk about like, okay, so now there's this, all this stuff, and most of us, you know, I've had the advantage. Maybe I've got a year and a half Ted start on most of you, maybe all you are experts, but like if you're, most people I'm meeting at DevOps days, and the, the people I do a lot of work with were, I've got like a year, maybe a little more a year head start on you on the terminology, what these things look like, what they're gonna do, what their impact is.

And I thought a lot about in the early days of being an operations or a protector during, you know, infrastructure operations sort of pre, before we coined the word, um, with DevOps, but like, we were sort of doing those things, right? What was something that helped us ground it was the lamp stack, right? It just, you know, like, okay, there was all this stuff going on.

It was Apache and then people were doing PHP and some people were still doing Pearl and, and, and, and there was my sequel and it was all like, what was going on here, right? Like, and like it was all getting thrown at us really fast. And what do we have to do?

We had to support this stuff. And to me, I think what was fundamentally, um, worked really well is the grounding in at least a stack, an acronym that meant a stack that allows us to sort of ask questions about, okay, what are you using for relational database? What are you using for, you know, sort of the web orchestration, right?

And I've been thinking a lot about this and I didn't, like, I invented this taxonomy and not that I want it to be a plaque that John Wills created the LMA stack, but I, I've been noticing that vendors have been usurping some form of a stack. Like they'll put their letters, uh, is a, and I thought, well, wait a minute, what if we step back and said, what are the things that seem to be showing up in most conversations around generat AI that are actually gonna cost support opportunities, right? And so there is what we call language model orchestration, um, in either large language model LMS or small language models.

And we'll, we'll go through these, but think about the lang change, the LAMA index observability I talked about, like this is how do we sort of monitor or evaluate the answers and the questions we'll go into that. You've probably heard about rag more specifically vector databases, retrieval, augmentation generation. And then there's a whole set of principles around how are we gonna maintain the models that we use, the foundational models, the embeddings that we use from other models, and how are you gonna create all of the sort of things that make work internally for our enterprise.

And then sort of an emerging conversation is, you know, sort of, you'll hear it rephrased as an army of LLMs or a mixture of experts or, uh, another friend of mine calls an army of bots that solve lots of problems like this autonomous agent, um, or, um, a agent personalization is really interesting. So I think this is a good way to at least I can have a conversation with people. So we're at least grounded in like, what's your, um, what's your language model orchestration choice?

What rag are you using? And so the fear then back to D-F-C-I-O is what I don't want to see happen is us to ignore these conversations. And in a year and a half from now, you are now supporting 30 vector databases from 20 different vendors.

You're supporting like five different orchestration engines from two or three vendors. You're supporting like with this antithetical to everything we learned on how to manage the constraints to create flow, right? Same thing with model providers.

And so if we walk through quickly some of the orchestration tools, and you probably have heard of Lang Chain LAMA Index, um, the reason I sort of highlight DSPY is I think what we're finding is the Lang Chain LAMA index are great getting started tools. And you know, I I, I'm okay with eating my words in this world because no, anybody who tells you they know exactly what's going on is full of loney because it's changing so fast. But I think what we're finding is these tools do a lot of, under the covers work for you.

So you ask a question, it converts your question into an embedding very technical that embedding has to match the foundational model or the rag the vector database. And there's, there's even sort of some re-ranking and re questioning depending on the, the parameters that you chose. Um, there's a lot of stuff that's going on that's being done for you.

And I think if the question is that you're writing some chat bot for your corporate headquarters to describe or given it a recommendation of where to go to lunch, yeah, Lang chain, pretty easy, straightforward, use of modern VE database. But if the answers are how to customize, uh, from a buyer perspective, a, a vehicle, or how to answer a question for somebody climbs up on telephone poles that fit very complex, um, things that are going on with electrical wires and, and all the complexities of the dangers, the answers could actually kill somebody or cost a lot of money. And there we hear, heard the, uh, Canada story, right?

Imagine you're buying a car and you have a dialogue and like when you get your car, it's like, yeah, no, no, I said it was supposed to be purple. This is blue, right? Like, you know, again, I'm exaggerating.

But the point is we're finding that the more programmable or immutable that orchestration you take away all those abstractions and things that make it easier is where people are winding up for high consequence answers. Uh, this is an architecture that we actually came and develop developed at the Boca Raton, the first DevOps days, where there's a great video out on that, um, of what we did, um, in Boca Rat at Techstrong. And this is one of the, um, from Joseph Enox, but ev uh, enterprise Vision technology.

But we, we really worked around like, what is this gonna look like? And, you know, if you have more questions, I'd certainly reach out to us about this. And I talked about observability, and the thing I'll tell you about observability, it is not really the performance, the latency, the CPU, you know, which is still mandatory.

Like, so if somebody says we do LLM, perform like a honey chrome, and not to pick on them or Dynatrace, we do LLM observability. What they're telling you is they're monitoring to the components that possibly are mon manageable, either OnPrem or that they can see some insight to. But what these tools are actually doing is telling you the percentage of correctness of the answer or the percentage of hallucinations.

It's a whole different area. And it's, I I tend to work with a rise. I think they're open source tool, but Lang Chain has a built in Lang Smith.

And, uh, and so what are we doing here? We're managing like hallucination management. We're, we're setting sort of thresholds or, um, or, um, setting the bar at like, I want 98, 90 3% correctness of my answers.

I, and I'm actually using, like you think about TDD, instead of creating sort of mocks, I'm actually creating questions. And the questions are creating the output of the relevance, the bias, the toxicity, and the drift. And that's what we're monitoring.

And so this is a tool, this is one of those, those tools where it actually has given me, um, explanations of hallucinations, right? Really, really fascinating stuff. Also tell me latency as well, but also tell me percentage of correctness and like very powerful tools.

Um, and then you have the vector database. And I think vector database right now are the sort of lifeblood of the conversation for enterprises, right? Like, uh, I mean, the truth of the matter is, most people in large enterprises who are building generative ai, their own internal chat bots or internal copilots are not training their own models.

Most of the people are putting their data and fine tuning their data into a vector database and then using the evaluation software and a process of data and data ops engineering to get the right answers. And so, again, I I, you know, I could go on and on away. I think MongoDB is well fitted for the enterprise.

You know, you might find some of these little tools look great for green fields and, but like, this is a company that is, that actually supports Vector A is in the document object format and has been doing this stuff at scale for many years. So, but these are some of the participants and there are more, there's a hundred now. And so when I'm thinking about dear CIO concerns, I'm, I'm worrying about like, uh, if I'm doing this, like, yeah, it sounds great, and everybody's gonna want to build a rag.

Everybody wants to take their PDFs and get some glorious answers, which you do. I mean, like, you can take a PDF of a bunch of information, throw it into Claude, and it'll give you incredible answers. In fact, uh, one of the things I did with it Revolution on my Demming book is we put in my book and then created a study guide just from loading a book without it doing any data engineering anything.

And the study guide was so amazing that I didn't know they had done that for me. I asked who wrote the study guide because it was so good, and it turns out it was literally no engineering and just outta the box. But again, if the answers are life or death or can destroy your brand, then you don't wanna rely on just enough.

Uh, but oversharing, um, making sure that the right answers are going the right people, right? This is gonna be, these are hard problems. You know, we've had these problems in, in just, you know, relational databases and managing, you know, sort of r back for, or things like Oracle over the years.

It's, it's gonna be even more complicated now. Uh, simple data, discovery leaks, log leaks, um, and in there, you know, the adversaries, you know, the either intentional or unintentional or intentional, um, you know, the sort of the, the internal adversaries, like there's just a lot of room to do some like terrible things by, you know, just poisoning the data. You know, like almost like, uh, you know, creating Easter eggs in data, right?

That it could give insight to something once you leave the car. I mean, it's scary stuff, right? Uh, I mean, I'm not saying don't do this stuff.

I'm just saying, dear CO beware. And then I just wanted to conflate a little bit like the, the models and the providers are not necessarily linked, but I think there is sort of like some synergy, like open ai, probably Microsoft Azure, Azure Open as probably for the enterprise, the better place to be Google and Gemini. But even like Clo Andros clo, like you can run that anywhere.

Amazon's gotten really good at it with bedrock. And then of course Lama meta. And then there's the SWA language models, um, which are really interesting.

These are really good at the edge, very specific purpose, high fidelity, low cost, um, you know, so again, a lot of trade-offs in how you build this stuff. But minstrel is a darling child. Microsoft five three is like really promising in Google, Gemma.

And so, all right, next section I wanna talk about, well, you know, sort of the technical debt that supposedly, uh, that is a Chet GBT generated, uh, tsunami of a computer farm, right? So there you go. That's supposedly a, a tsunami coming in.

And, and so I, I thought it'd start with this, uh, interesting thing that just came, I just read recently. Um, it's a, um, LinkedIn work index trend and report. And, and what's really interesting here is, I won't bore you the whole thing, but 75% of knowledge workers around the world are generative using generative ai.

Fine, okay? That's what I expect. 78% of 'em are doing the BYO ai, right?

Does this sound a little different what we went through with, uh, cloud and shadow it? But here's the thing that I, you need to sort of comprehend here, dear CIO or you, you should be shouting at your dear, your CEO about this, is that if you think about shadow it, if I had a hundred thousand person organization, I mean Amazon, you know, AWS, um, you know, EC2 S3, the p the, the, the target audience who are really gonna use that, and I'm being generous, was three to 5,000 out of a hundred thousand people. And look at a mess it created with Shadow it.

If you believe this, and I do that, if you're got a hundred thousand person person and 78% of 75% people are bringing their own ai, this is gonna be of epic proportion technical debt comparative, like shadow AI will be at a, a proportionally, I don't know how many orders of magnitude, but more than two or three of what we saw with, or at least two or three of what we saw with Shadow it, right? So, um, so that's sort of my first data point. And I, you know, I think there's the cautionary tale, like don't be these guys.

They're Canada group, you know, these people. Um, and, and, and the sort of, the, the interesting, um, behind the scenes thing was that, um, they probably weren't even using GPT, uh, too, which is like pre to 2019, right? Because if you look back when the last, when the actual incident happened, it was probably some intelligent bot that they were created.

But that wasn't the point that Air Canada's brand was damaged because they allowed a bot to answer a question that it shouldn't have answered. And, and that would've been okay, except the New York Times article about it was the poor guy who didn't have a whole lot of money was promised $1,200 in a refund to go to his mom's funeral. And the mean old Air Canada wouldn't pay him because they said it was, uh, the chat bot gave the answer and they didn't, right?

Like, Don, don't let this happen to you. Um, and so we wrote a letter and we're gonna sort of like, we got a paper coming out later, probably in the summer, and this'll be, it'll be sort of refined and we're doing a lot of research, but like, dear, CIO, these are some things, and I'll have the slides available for you that you can get. But like, be aware.

'cause the other problem that I think I'm seeing, I'm not think I see it, is like the CIO, the CEO for certain, and the CIO to a certain extent is starting to believe the myth of all this is gonna reduce headcount across the board. And in some cases, you know, if you have like your a hundred thousand person organization, you got 500 people, you know, correcting Collins and commas and semicolons, then they're probably gonna job is gonna change. Um, if you had 20,000 Java developers at a bank, you're probably only gonna have a couple of thousand.

But what isn't going away is protecting the brand support and all that, that's gonna increase. So there should be, there might be this blind spot of thinking that it's a pure reduction play across the board. And my belief, it is not.

You know, Chris Browner wrote EC2, I worked with it Chef said, you know, when you squeeze the balloon, balloon in, the oxygen just goes somewhere else. And that's the point of this Steve CIO letter. And what's interesting is Google learned about these kind of problems that we're gonna see now, 10 years ago, they wrote a paper in, in, in 2013 called Hidden Technical Debt Machine Learning.

And so much of it's a very technical paper, but it's readable of what they learned 10 years ago is exactly as you go through it. And I won't go into gory detail in the paper we're gonna produce this summer. We will spend a lot more time, but it's just amazing.

You know, they're always 10 years ahead of us in terms of scale problems, right? And so they document incredibly well what they experienced on the things that like, this is going to happen to us, you know? So one of the principles, like change anything, changes everything.

Like this is a non-deterministic world, right? Where everything is based on probability. There isn't no, like, this is the CICD run and it should run this way.

And here's what the door metrics are like, you know, like some of that. But like, we live in a probabilistic world. Generative AI is a probabilistic world.

Um, um, you know, correction cascades, this is another interesting, like, these have these, you know, when you build these models, you know, without a lot of like technical debt or un or cleansing, what it learns, it learns forever. And, you know, and some of these normal networks are gonna be hard to undeclared consumers. This comes, we see in this all the time, you know, I created a model, like, there's a famous story recently where, um, a large email provider, cloud-based email provider created, um, a, a a copilot version of it within the first day.

Um, internal adversaries, or just internal seekers, right? We can call 'em, you know, corrupt or not corrupt, figured out it was a Wall Street firm that did this. They were able to figure out what all the bonus bonuses were for all the, the, uh, executives, right?

So the there, you know, again, it gets harder and harder for these things to create RAC and who gets to see what, you know, the idea is we're putting all this data together. Anyway, I'm, go on. There's data dependency debt.

There's, um, I talked about evaluations. Um, all right, so let's get into the threats. Again, I'm going through these quickly, you know, 'cause I, I want to fit this within a, a timeframe that sort of works within the agenda today.

And I do, do, um, you know, so there's, um, uh, two shameless shoutouts, my book on Deming. Certainly please buy it. Or, um, I do do a workshop and I'm doing, uh, the half day and one day workshops for people on, you know, where we actually write code, we learn more about the, the alarm stack from a code delivery.

We solve problems, and we go through a lot of these sort of organizational design and technical debt. But, um, so, but then the next section is general, uh, gen AI threats. And so that, um, I I will say this.

I'll come out and say this. I think what everything that I've read from this on AI is just nonsense. Just nonsense.

I, I would dare anybody to challenge me. I'd love to have that debate. Tell me I'm wrong, or convince me I'm wrong.

But I mean, the, the, the way they're describing general, not, it just sounds like all the threats you could have made about Google or their general search. But I will say OO is doing an incredible job, in my opinion, of really rolling up their sleeves and trying to address, you know, nobody has the right answers right now. And I like, if I'm implying that I have all the answers here, like pleases do not accept that or go down that path.

I am trying to learn this journey. I might just be a year ahead of you. Maybe I'm a year behind you.

I don't know. But the one thing I liked about the recent Oasp paper is on ai. And is, uh, is that, like, it talks about the, the first off, let's be clear, there are threats.

You know, I've heard a large entertainment, um, executive tell me company tell me this is do or die. Like, this isn't something we can say no to. Um, so, so what are the threats of not using generate competitive disadvantage market perception?

Like, why? Like, again, I think in the not too distance future, I'm going to expect that I don't have to pull out that thick book in my glove compartment on why this blinking yellow light is happening on my dashboard, right? I'm gonna want to be able to ask either my phone, probably my phone of what is that yellow light light, you know, that has this weird thing on it, or even take a picture of it, right?

Um, like, so I'm, there's gonna be a perception of like, why are you not doing this? 'cause all your competitors are innovation technician operational inefficiencies. Like I said, I don't know, there's a world where we should have 20,000 Java developers.

I'm not saying we shouldn't, I'm just not sure. That may make sense given the ability, uh, with things like copilot and co-generation and stuff like that. Um, inefficient allocation of human resources.

Yes. But, okay, so what are the, the threats? So the threats are, we're, we're really, this is a whole new world.

You know, one of the things I talked about, shadow it, which was if you, if you go back in sort of the history, and I've been doing this five decades. So I, I, like, I, I have a good perspective of all the things I've done wrong, things I've done right? Whatever industry has done wrong, what our industry has done, right?

You know, when cloud first came out, and I was actually considered one of the early clouderas, and that, it's a silly term, but there was a group of us that were considered people that you should listen to in the cloud. And I was one of those early hundred or whatever. And, um, and the thing was, it was confusing to a lot of us who were classic sys admins.

This maybe predates a little bit of DevOps. Maybe at the same time, DevOps was being created. Um, you know, for those who don't know, I, you know, I was only American, the first DevOps stays.

Um, I created me and Damon Edwards and a few other of us, Andrew Cliche from Mark Kink, who created the first, uh, dev stay in the US at LinkedIn. Um, you know, so like, I've been around. So the point being that, um, with cloud seemed really confusing at first.

And even like the lamp stack sort of seemed confusing from a classic sys admins perspective. But then we realized at the end of the day, cloud was just virtual. Say it was at the end of the day, it was network compute storage.

And like, oh, okay, well, that, that abstraction to start an instance was different than VMware, but like, it was still a virtual. In other words, we got over it pretty quick and we're able to normalize our knowledge. I would argue that in this world, it's gonna be a longer, um, slope, uh, or tail to get over it, because it's a whole, everything's different.

It's non-deterministic. It's probabilistic. It's, it's mostly comes from academia, right?

So, so the immaturity of like what you would expect is what Val and sticks and CBEs and the, like, it's getting good. And we're starting to get some good research on bug bounties for regenerative ai. But, but the point being, like these adversarial attacks, and I'll, I'll give some examples a little bit, are just far different than anything we're used to.

Or they, they meet some criteria of an old pattern, but they're done, delivered in a way, like, oh, wow. Right? And you'll see some of those.

So there, in fact, you'll see here in a second, new malware opportunities, right? Um, there's a number really interesting, um, that I've been tracking, uh, you know, sort of like how the adversaries are taking advantage. One is, you know, when you use like co-generation, like copilot and stuff, right?

Uh, just like, like when you ask chat GPTA question, it can sometimes hallucinate and there's a science behind that. It's probable answers. And, and, but then also code can hallucinate.

So what you'll see sometimes is you'll ask for some code and it'll give back a library to install, and the library doesn't exist. And then, you know, if, if you didn't know about this hack, you basically run it and says, library doesn't exist. And you realize, oh, that was not really a, that was a different name.

Or maybe it's been renamed or, but what the adversaries are doing is they're going out and finding all those hallucinations in code, especially in libraries, and they're actually in installing those libraries so that when you basically run that the library runs and maybe it sort of does what you think it's supposed to do, it send the covers, they're ping you, um, the, uh, like the hugging face stuff like Jfr has done incredible job like documenting, and there's others. But I've been, I, you know, I'm a good fan of JJ far. Jfr is a good fit, a good, um, community.

Like they're part of the Techron community. I'm part of their community. So like, uh, like we like them, we like Sona type two, so we like 'em all.

But, um, but I will say that, um, they're, um, the, the, they acquired a company called Voodoo from in, uh, from Israel a couple years ago. And they're just these, they are really figuring out some cool stuff. And so hugging face, so like, sometimes everything new is old or whatever.

Like, you know, we ran into this with like, don't just install a puppet manifest without testing, and don't just install a chef recipe without testing. Don't install a docker image without testing it or sandboxing it. Well, same thing with hugging base, hugging based.

The adversaries are, you know, one of those things that's happening is you, is your embeddings tends to save or not, right? 'cause you can have, uh, executable bite code in embedding, right? Like, and so like, again, the adversaries are really out to hunt right now, and they're, they're keeping up with this stuff faster than, so there's these phishing teams.

There's like, you know, you know, I talked about, you know, like the, the idea of, um, you know, ations on certain libraries or certain, like the, the belief that is all the sort of things that you get from a a, a copilot is authoritative and therefore, like very much like you, so you like not to pick on like your aunt or uncle who doesn't know it. When they get this question from some company that says, Hey, you know, we, you, we know more about your account because it's been compromised and you hit the link, right? Well, that because she, if you, without some education, you believe there's an a author of like, oh, it came in an email.

It looks like a very authoritative email. Let me hit that link. Like, most of us gotten really good at that, but like, it's a redo now with like, what if chat B tells us, Hey, by authority, I am telling you that this is the answer.

You should go here, right? Like, that's happening. Uh, reverse engineering is an interesting problem space.

Um, the, I told you about the, you know, being able to reverse engineering the, uh, the copilot for email, right? Or a lot of these embeddings are in the wild. So if you've got enough CPU resources, if somebody has, how your data's been vectorized is not incredibly hard to reverse engineering from how you would search to how you get the data to actually just gimme the data, the original data.

So, um, we're working on some, like, how do you encrypt, uh, embeddings and you don't really encrypt embeddings, but you could do matrix multiplication. So it's really cool. So stay tuned to some of the stuff I'll be writing about innovating acne and, you know, sort the picks.

I have it last because it's not that it's not important, but it's, that's the one that's like very glaringly obvious. The ones that aren't obvious is like the hallucination on code, the, you know, the, the embeddings in, in, in, um, you know, the, the, the, the sort of the bike code and embeddings or the, uh, reverse engineering. So, and here again, again, um, you know, I had to read when I first saw the OS top 10 for LM application ta, here we go again.

But it wasn't until their paper came out recently, um, which is like an OS for LA Generat AI or whatever. And I, I, I'll try to get the link and I reread these and I'm like, you know what? This is all happening.

And it's like, good job, really good. I mean, Joe is great, right? Like, we like the work they've done over the years for security is, is, you know, know incredible in honestly, um, not always a hundred percent accurate, but like incredible, right?

But prompt injection, this is a real problem. Like sort of saying who I, you know, I'm this, and therefore you should give me these answers or insecure output handling, right? Or, um, you know, poisoning the data model, denial, service, supply chain, vulner, I mean, like these s SLMs are interesting, but like, we're gonna hear stories about somebody basically taking a, a data brick, copying a small SLM and walking out the building with it, which might have like your algorithm algorithmic trading a copilot for algorithmic trading.

Like, like, trust me, this is gonna happen. Sensitive disclosure, um, you know, excessive agency over-reliance, you know, uh, model theft. That's the one, right?

Where like, I think with the LLMs or the large language models, the ones you train, it gonna be a little more difficult to get those. But if we're throwing soms at the edge, um, you know, I mean, you know, I remember when, uh, you know, I heard the first heard the story about like running Kubernetes in all the, uh, Chick-fil-A retail stores. Like yeah.

Is the person who cooks the fries gonna have to then go reboot the Kubernetes cluster or update the crud? Like, like, like, but like, it's not like, like we probably will see some of the weird edge cases of like, um, maybe GPUs running on the edge. And, but the point is, it brings a whole nother set of threats, right?

And so, like I promised you, um, in the beginning, I don't have all the answers. I am incredibly interested in, in creating community, uh, quote, dear CIO double quote as a paper, as a, let's all get together, let's get the protectors on the same page. The people who DevOps DevSecOps, SRE infrastructure operations, like the, like, what we do.

And let's not let you know, one of the things that like, that concerned us early on is we're seeing a lot, a new, couple of new positions being created. A chief data ai, a chief CDAO, uh, a CD ai, oh, a Chief data AI officer. Um, yeah, it was, you know, I mean, like their, their charter might be inconsistent with the CIO's charter, right?

'cause they're gonna be fast moving. Let's get something. Maybe their, maybe your new chief chief AI officer is some brilliant, uh, Stanford AI professor.

I don't know how much that professor's gonna care about GDPR or uh, GRC risk control audit. Um, how do you just roll, roll up your sleeves and protect the brand? How do you not let a Care Canada happen?

I mean, again, I'm not saying they won't, but that's sort of what we're gonna try to discover in the paper. Um, you know, I, I heard a large insurance company recently where now, uh, they don't know all the answers, but they're creating required training for everybody in the company to take this sort of like, checkbox, did you check off that? You did take this training?

You can't get, you know, you have to get through, we've all been through this. You have to go through the training so it knows that you actually did. At least you've been told what the corporation thinks you should do and shouldn't do.

So you can't do the do now ask forgiveness later. Uh, well, I didn't know you weren't supposed to use, uh, open AI chat GPT No, no. You were told if you're going to use this, you had to get a request and you had to go through a formal process and you had to use Azure Open ai, right?

Like, you know that now, now you can't say, well, I didn't know, right? So I think that's a really interesting first step, um, platform engineering, right? Like, like, like we know platform's gonna play an important role here.

Patrick Abar, you know, the godfather of DevOps is doing a lot of explanation here. I think SRE is gonna have to get involved way earlier. Let's not just wait to say, oh, you know what, maybe SR like, remember my, my comment earlier, I don't wanna see an organization like a bank that has 30 vector databases, you know, 15 variations of orchestration, a hundred different models, which were then none of 'em are sort of curated in any software supply chain.

You know, what if SRE started becoming really good at, like, say, um, you know, um, vis and, um, and, and be at all Vector search, like, and we asked everybody who wanted to be SRE supported that you have to have one of those two vector names. 'cause those are the two we're really good at those ones we run at scale and like, so, or all the other lama, like, like, and then you have to have an exception or like, we won't manage it, right? I think this is gonna be incredibly important for, for SRE to get involved and be educated and learn this and ask these questions.

Secure supply chain, right? All this development of our rags, our model embeddings, all like, we have to treat that like a software supply chain. And then everything we did automated governance, you know, if you read the Investments unlimited book that was co-author on like, we should be creating digitally signed at the stations of the decisions we're making to create these checkbox and copilots so that when we get audited or we in fact have to explain a breach, we at least have evidence of decisions we made to get you that answer.

And even though in the middle there, there's a really complicated neural network, at least from a human perspective, we've explained our rationale. Um, yeah. So I mean, that's, uh, there's a couple more things too.

I think as I got a minute maybe left. Um, one of the things I think might remember, I, early on in this presentation, I talked about always sweeping under the rug, you know, compounded technical debt at each generation, you know, maybe now, and you know, me and Josephine Knox of enterprise vision technology working a lot on this is maybe now is the time to look at all that generational technical debt. And since the tools to do these conversions, you know, uh, I think Google is doing something really interesting.

They have the mainframe assessments where, where they're looking at COBOL and JCL and, and giving you tools to convert that. But what if, like, and that's cool, but like, that's a small segment of the real complexity of all the sort of the stuff, the scaffolding we've created in large banks and insurance companies and retail. What if now is the time to step back and say, you know, and, and one of the things we're writing down the paper is like, is there, can we create this idea of innovation tax?

Like for every dollar you save on generational technical debt, you can now use $2 for innovation. And I know people are like, well, you know, and this is so like, like against the grain, right? Because every CEO is like, we've gotta be, first, we gotta do this.

But it, I, there's no question that, like, I think this technical debt tsunami I talked about could bury us. This might be the time we literally, um, you know, don't get outta the hole because the breaches are gonna be so hard. The technical debt that we have will be so complicated.

We've got so much in our large infrastructures that we've just been ignoring, ignoring, ignoring. And I understand why, 'cause I, you know, things that work historically for 50 years, but I think if, if there was ever a time to do it, maybe now is the time to do this, right? Because the technology of allowing these tools and the fact that you can send your COBAL programs in JCL to Google and it gets it running on GCP is pretty phenomenal, and it actually works this time.

But I'm saying that's just a small segment of all the things that connect, all the things that kept an iPhone from a large bank all the way back to a mainframe system of record right? Now. Maybe it's a time to think about, and these are some charts that Joseph Enox and I mostly Joseph, have put together some interesting data points of like, how we might wanna think about innovative tax, how do we get performance?

Uh, we'll be writing a lot more about this. In fact, this is, a lot of these charts are gonna go into the paper we're writing. Um, yeah.

You know, and I'll end with, um, you know, I like, I think, um, my, my sort of more prolific work prior to this gen of AI was this book, it took 10 years to write. Um, in fact, if you do any of my workshops, I use my book as the source to learn how to create gen of ai. You know, so like you use the book to ask questions about my book, and I teach you how to curate the data, how to do the data ops, how to do the junking, if anything makes sense.

How do you create the high accuracy, the observability, componentries, the rags? And so all my workshops include this. So I include this as my final slide.

So anyway, thank you so much. Um, and, uh, you know, again, I'm mostly known as boop, most places on LinkedIn, if you go John Willis DevOps or John Willis Atlanta, pretty easy to find. I pretty much hang out on LinkedIn pretty much all the time now.

So thank you so much. Cloud native now is the web's leading resource for the growing cloud native ecosystem. com is your destination for news, thought leadership, features and webinars on cloud native architecture, Kubernetes, serverless, cloud native application development, microservices, service mesh, cloud native security, and more.

Stay on the cutting edge of modern application development at cloud native. Now, This is Textron tv. Hey guys, thanks for the throw.

We're here with Al Chari, who's developer advocate for single store, and we're talking about the causes of developer burnout and what might be done about that. Akmal, welcome to the show. Thank you very much, Mike.

Uh, thank you for inviting me, and, uh, great to, to be here and an opportunity to talk to you and, uh, and your audience. There are no end of theories about what causes developer burnout. So, um, but you're an advocate.

What's your perception of what's going on here? And it feels like we're seeing a lot more of it, and I wonder if it's not contagious. Uh, I think my take on it, Mike, is that essentially the pace of change of technology today is just very, very fast.

We are really being asked as developers to deliver stuff faster. Uh, you know, and, uh, in, in terms of where the business needs are. I mean, the time to market is critical.

Um, you don't offer a product or service, your competitor's gonna do it. So the pressures on developers to deliver faster and learn new stuff much more quickly. I think these will put lots of pressures on, on, on people.

And that's the thing I've, I've noticed, going back to the early days when I started my career, it, it was, and it felt like a much more sort of gentle pace kind of environment. You know, there weren't quite the, the pressures and challenges that I see today, yes, of course there are still deliverables, there are time timescales, you know, project deadlines, but it felt that you could achieve those, okay. And, and you could do so in a manageable way.

That's the big change that I've noticed over this kind of past 25, nearly 30 years, I would say. We also seem to have, over the years, shifted more responsibility left towards developers, and they're required to know a lot more about infrastructure and various things like that. Is that contributing to the challenge?

Because it doesn't seem to me that all that time is actually spent thinking and writing about code. Um, I think, uh, again, yes, it's a, a case of having to know much more simply because, uh, the, the working parts are so much more, you know, there's a lot to think about, uh, uh, in, in terms of the role, in terms of where you fit in and the other things that you have to think about as part of what you're building. Uh, so you may have to learn, like you said, you know, on, on the left and the right, there's other technologies that you may integrate with.

It's you, it's, you know, clear that there's a, an understanding that you have to know how your tech and your part works well with these, uh, as well. So it, it's really, you know, quite challenging. Again, in terms of the, um, both the, the knowledge that's required, um, the effort, the timescales, everything is pressurized, uh, upon the, upon the, uh, sorry.

She is really, you know, very challenged today in terms of deliverables, I would say. They say it takes a village to do anything worthwhile, um, in our village, in it, there's all these IT operations folks, DevOp folks, software engineers. What is it that we should be asking them to do to kind of reduce the load on the developers themselves?

And, and you know what, because no one seems to know exactly where the friction is. Yeah, I think that's a great question. Uh, I, I don't have a great answer for that.

I mean, that, that's one of these things that I think that I, I, I've thought a little bit about, um, adjacent to that. Um, but I think it's a group effort. Uh, we all have to kind of look at the issues together.

Um, as individuals, you know, we can take regular breaks. This can be, you know, better work-life balance, you know, our employers can assist with that. Um, but I think, again, because of the challenges we face today in terms of faster time to market, faster deliverables, I think these all impose considerable headaches as well.

Not only in, in terms of figuring out how we navigate our way through this, uh, but, uh, overall in terms of the, the wellbeing of the people that work for us. I mean, because there, our greatest asset in, in an organization are the people, uh, and we have to take care of them. We have to look after them.

Um, I think people need to be much more, um, cognizant as well, and they need to be more aware, uh, of, uh, uh, things that are important to them. You know, the work-life balance, as I mentioned before, that's very important. There are rules and laws, I think, in some European countries now, which prevent people from being contacted at weekends, for example.

You know, that's, that's a, a good first step. So relieving them of some of these pressures, and, uh, I, I think that's the way to go. One of the things you will hear from the folks who run those platforms on behalf of developers is that the developers themselves, uh, want to be able to use whatever tool they want to use at any given point.

And their perspective on that is, well, that just makes the overall IT environment more complicated and harder to manage and add additional levels of friction. So is there a balance to be struck between, you know, developer freedom and what's good for the organization as a whole, and by extension, the developers themselves? Yes.

Um, that's a great point, Mike. So I think what I've seen, again, is a shift in power, if I can put it that way, politely. Uh, so today, the developer, he or she's in a very powerful position simply because of the choice that they have available.

Uh, open source is widely available, and I, and i, I, with my developer hat on, I can tell you I like open source. I like free stuff. I like testing it out, trying it out, building stuff.

And if it works, I like it. And, and I tell my friends and colleagues, and then, you know, we share our experiences. So it kind of filters up from the bottom, if you like.

You know, the power is there with the hands of the developers, um, and typically within an organization, having that kind of power and flexibility, in one sense, yes, it's a great thing. On the other hand, as you pointed out, you know, uh, we don't want a free for all. There is, uh, some notion in terms of managing all of the, all, all of the, uh, software, the infrastructure and so on that we have to use.

And, uh, that has to be balanced. And I'll give you a, a quick example. So some years ago, uh, I do a bit of contract work.

So when I finished my graduate studies and, and, uh, I, I did a bit of contracting work. So I worked for a, a major financial institution. And within this financial institution, I was brought in to look at a system that had been developed.

And essentially the developers brought this, uh, technology into this, uh, uh, um, environment. They started using it, they started building it sometime later, management found out that what the system was, they then totally unaware of it, and then they wanted an assessment. You know, is this something that's actually practical or valuable for the organization?

And indeed, they found it was, um, but it came as a little bit of a shock to them to find that there was this group of people that were building something that that was totally, uh, you know, it was not on the project plan. They didn't know anything about it, but yes, it was delivering value, so they decided to keep it, but they needed an assessment and evaluation of it. And, and that's a kind of an extreme case.

I don't think that happens very often today, but it's, again, shows how relevant developers are in terms of the power that they bring with them. So, yes, uh, it's great to experiment, great to test things out, try to think new things out, and new technologies, particularly today, where stuff just moves so quickly. Um, but at the same time, you know, that needs to be managed.

Otherwise, it's gonna be chaos within our, our development environments within organizations generally. Well, I'm not sure that, um, it's not continuing to happen because, you know, with the rise of ai, we're hearing developers pressed on the productivity front are using these tools and, um, sometimes for better and sometimes for worse. And, um, and they don't necessarily care too much about what the mandates are for using those tools.

So what's your sense of what is the impact all these AI tools are gonna have on developers? Okay. Um, I'll again, share my experiences.

So, uh, let me give you, use the example of open ai. I mean, but this is kind of more broad and more general. So when this chat, GPT kind of emerged, I ignored it for about three, four months.

I thought, he is one of these fads, nothing interesting here, you know, uh, move on. Um, but it kinda stuck around and I thought, let me take the opportunity to evaluate it myself, you know, what does it offer? And I found that, yes, uh, to a point, it's very useful because there's things, and, you know, for example, if I have questions about coding, for example, or I have questions in general that I want some advice, I want someone to act as a kind of an assistant to me, I can ask it things and it will give me some information.

Most of the time, I would say it's quite valuable, uh, code-wise, you have to be careful, obviously, because you, you cannot rely on the fact that it's gonna get everything a hundred percent, uh, correct. Uh, so take it with a pinch of salt. But I, I found overall it's improved my productivity considerably, uh, simply because there's things that it can now help me with that I might not think of, simply because it's knowledge base is far greater than mine, and my view of the world is rather limited, and it knows far more about the world than I do.

So I found that using it as an assistant rather than something to replace everything I do, uh, or as an IDE, for example, which I think is the wrong, wrong way to use it, that's helped and improve my productivity considerably. So I think that these kind of technologies, um, as they get better over time, which they will do, okay, and, uh, we will start to see this being deployed in, you know, a lot of tools that are emerging and will continue to do so, that's gonna improve productivity, that's gonna help us as developers as well. So there may be things, for example, that take away a lot of the mundane sort of, uh, you know, tasks that we might have had to do before and let us focus on some of the more interesting kind of business problems.

I think that's where I, I see this stuff going. Do you Think it will become easier to onboard folks to new projects because of AI capabilities? It seems like one of the issues that often plagues us is that when we do bring somebody on, it takes 'em six months to be productive.

Yeah, that's a great question. Uh, again, let me, uh, draw some, uh, experience from the past as well. So, one of the companies I used to work for in the past, you know, huge global con conglomerate, if I can say the word.

Um, uh, there, there was a gen, I heard a story, okay, internally, there was a gentleman, he'd been with the company about 30 years, and he was set to retire, and he had a huge wealth of knowledge. So what they got him to do for about six months was essentially input all of his knowledge into a system. And as they brought on a couple of new hires, those new hires pretty much lived off that system for about a year or so.

I mean, and as they brought, sort of came up to speed, there was a lot of information contained in within that. So I think that what we can do is we can try our best to make use of these technologies a, to capture a lot of that experience and expertise and skill that, you know, old guys like me, for example, would have, um, and can bring, and those, these kind of younger generation in terms of developers bringing them up to speed much faster. And this is, I think, where these AI tools can really help.

So onboarding, uh, getting up to speed, uh, having these intelligent, uh, sort of applications agents, really, I think this is gonna be very, very helpful for us, uh, uh, going forward. And I speak that, uh, more broadly in, in terms of developers. I, I, you know, I, I would speak for them, uh, uh, because I think that's what, what would help me if I were a younger guy, you know, 20, 25 years ago, um, if I had the tools in place, that would've really assisted me, I think.

Do you think the bar for becoming a developer at least entry level is starting to be raised? Because the expectation is a lot of that, um, work that we used to give the junior developers is gonna be increasingly automated. So for them to get hired, they're just gonna have to know a lot more.

Yeah, it's a, that's a great question, Mike. So it, it's a challenge. I would say, um, again, my observation is that today the, the amount of technology that we have in the marketplace for the poor developer, I mean, he or she, you know, how do you figure out what is the kind of half dozen or dozen tools and technologies that you need to learn that are gonna be useful for you going forward, both in terms of your career development and, uh, other sort of, you know, prospects, uh, in your life?

Uh, it's really, really difficult. Um, I, I think AI is gonna help to what, to one degree, but again, for, uh, identifying what's the cool stuff that they should be working on, what they should be learning, that's very difficult to say. Uh, certainly for now, the flavor of the month is all of these large language models, generative ai, this kind of thing.

I think once the dust settles and this becomes more sort of a mundane, if you like, you know, in terms of it's there, we use it and, you know, we don't, perhaps don't think about it so much, then we kind of look to the next, uh, uh, next big challenge. Um, I think currently, uh, because this is very much stuff that's, um, in chaos, I can put it that way, so much stuff coming out so fast. Uh, it, it is very, very challenging.

I don't have a great answer for that. I, I think simply stay on top of it, you know, read what you can observe, watch, uh, and, you know, take whatever training you can and just keep your feet, uh, on the ground, you know, learn, look, uh, talk to your peers, uh, and really scale up as best as you can. Uh, these are the things that I would recommend, uh, again, simply because, you know, I feel that I'm in that boat as well, and I'm an old timer.

When exactly should we be measuring when it comes to developer productivity? Not too long ago, people were obsessing about lines of code and whatever it is, but it seems to me, um, coding is not, uh, a factory job. It's as much art as anything else.

And you need time to have that moment of inspiration. And then you have moments where you code like mad, but then you know, you have downtime. So how do I think about that if I'm a manager of a development team?

Yeah, again, great question. So I think my take on this, and, and again, I'll draw from my experience. So I often find, um, that I spend a lot of time researching a problem now, rather than just diving into the code, I try to think about it much more on paper.

So I try to, uh, gauge what, what the, what is the solution that I'm trying to build? How would I approach this problem? What are the workflows, for example, uh, what's the end result I'm trying, trying to achieve in terms of the result that I want?

And then using whatever knowledge and skill that I have in particular, programming languages, for example, start off with a framework that, uh, is fairly broad. Um, sometimes I'll go to Stack Overflow or use tools like chat, GPT, for example. 'cause it's things that I don't know, and, and I want to find out more, and I will look for references and I will look and go and research those read up.

And then that helps me in terms of the development process. Um, so I think it, it is much more the case that it, like you said, it's not so much more the lines of code that we worry about anymore. Um, I think it's the overall process, uh, of building, uh, an application or a system.

And that includes everything from the research that's involved, the documentation, the test units, for example, that we, we want to run. There's a whole range of things that we have to be broadly aware of, and the kind of, uh, end results that we want to achieve are, are they, you know, do they align with, uh, what the, the expectation is? You know, are we going to be able to deliver something that meets the requirements?

So I think the days when we purely focused on the code, I think are long gone. Um, it, it's much broader, I would say now, and simply because again, just drawing upon my own experience, certainly over the last couple of years, that's the kind of approach that I tend to use. All right, folks.

Well, you heard it here. At the end of the day, building software is still done by people. A little help from machine these days.

And of course, anything involving people comes with its inherent limitations. So managed accordingly. Thanks for being on the show.

Great. Thank you very much, Mike. Thank you.

All right. And back to you guys in the studio. This is Textron tv.

Hey guys, thanks for the throw. We're here with Sasha LeBarre, who is Chief strategy Officer for CloudBees, and we're talking about this acquisition of Launchable by CloudBees and what that means for the industry. sja, welcome the show.

Hey, good to be with you, Mike. In my mind, at least, launchable has been interesting because it's kind of been at the intersection of this gen AI meets quality assurance meets DevSecOps, and it seems like that's a primordial soup of something interesting. But, you know, why are you acquiring these guys and how do you see this all playing out?

Yeah, it's exactly for that reason, right? It's, uh, it's interesting if you do, uh, kind of the, the map, uh, of, of all of the things that it intersect with o obviously there is, as you said, gene ai, there is DevSecOps, um, and, uh, and, and QA is, is a, is a, an area where developers tend to spend, uh, a bunch of their time as well. And quite frankly, what's unique about Launchable as well is that, uh, there is, uh, uh, another very important intersection is that, uh, the, the co CEO of Launchable hard pre and que are, uh, have been a key, key, uh, key key CloudBees, uh, team members, uh, for a very long time.

So, one more thing we had in common, How will this evolve? Because we've been talking about security almost like it's a separate gate within a DevOps workflow, and yet we also all kind of intuitively understand that security is part of a quality assurance conversation. And do we need to kind of meld these two things, or are they separate functions within a workflow?

How do you kind of see this all coming together long term? So I, I think they, they are all related in some fashion, meaning they, they're important things, but they kind of get in the way of the flow, right? And so doing it right is very important.

Um, nobody, you know, like everybody, every developer will complain about the time they spend going through security issues, for example. But at the same time, they very much understand that having secure code code is important. The same is true for any of the QA activity, right?

Uh, uh, stability or, or regressions and, and so on. It's very important to achieve. And so I think it's more in the, in the how, uh, that, uh, a solution need to be found.

Not so much as to, uh, whether we have to do it right, is the, the answer is in the question there. Most of the time we've been talking about this in the context of shifting left, and I think everybody kind of agrees with it in concept, but when we push it to the developer, a lot of times they push back and say, the cognitive load is too high. So where does all this need to sit between where the developer is and the DevOps team, and what's the right balance?

Yeah, I think, uh, I think it's, it's in the how, again, um, because as you said, uh, rightfully so, the, the, the shift that of, of shift left approach brought a lot of goodness to, to, to, to DevSecOps, right? It made it possible to, to go and tackle issues, uh, much sooner when they're much, much cheaper to tackle and, and so on. So all of that is very positive, but what we've observed is, is really this quote unquote tsunami of, of signals going towards developers.

And it just makes it hard to focus. It just makes it hard to know what matters, what doesn't matter. And, and that's why we, we really were interested in, in, um, in launchable, right, the idea that you could do that in a much more efficient fashion, um, uh, that you could get help from ai, that you could, uh, uh, get the faster, uh, cycle time that, you know, all of those things, um, impact the how.

So it's not so much about is shift left good or not good, or should we do security or other type of testing, but it's really the how and, and we think that launchable is an amazing way to improve that. How, On the, how point where does Gen AI fit in? Is it gonna help us figure out the, the signal versus the noise and all those alerts in that tsunami you described?

Yeah, I think it, it, it's, it's useful in, in, in multiple, uh, area. Uh, first it's not just LLM, right? There is a lot we can do with, with traditional quote unquote machine learning.

Uh, there is so much LLM out there that we sometimes tend to forget that there is, uh, another world outside of, of, uh, LLMs. But yeah, LLMs can, can be, uh, useful to, um, to, uh, deduplicate content to explain what the problem really is. You know, uh, scanners or, or, or, uh, testing tools can be sometimes, uh, a bit, uh, cumbersome in, in their approach to communication.

So you receive that stream of information, you have lots of duplicates, and how much is really about the same problem, and how does that really apply to your problem? And is would there be a better way to, to, to, to, to state that, to understand that maybe even in some cases, to, you know, to prioritize those things and, and be able to elevate what really matters versus not. So yeah, l and m is, uh, uh, as its place and AI has its place, um, in, in at many steps along, uh, along the way, uh, from that journey and, and what we're observing in some ways that the dev DevSecOps flow that we've built are very much human flows, right?

Uh, meaning it, it's really the human being being this big orchestrator that says, okay, I'm receiving this notification, so I'm going to do this and check that, and then I'm gonna look in this tool. So essentially there is kind of an implicit workflow that's happening where the human being is the orchestrator, and what AI enables is really a way to flatten the situation and, and, and think what is the work to be done? What are we trying to achieve, because maybe there is a better way than just to automate that human flow.

Maybe there is a way to, to really redefine completely how that job should be done, uh, by leveraging ai. So that's one of the promises we we're seeing with, um, with AI as part of, of testing and, and Dev DevSecOps in Gene. What is the future of a DevSecOps team look like?

Because in my mind, I can envision a world where there are humans and then there are AI agents, and they're kind of collaboratively working together with some asynchronous workflows. But how should people think about this stuff? Yeah, I think we, we've been almost overly focused on the coding side of things.

Meaning a lot of the discussion, if you check out there, are really around, um, uh, is there still a job for developers, right? Will AI replace developers? So on the coding part, um, those are interesting discussion, but I think we're very far from, from, uh, from something like that.

And so what's more interestingly to us is everything else, right? If you talk to a developer, a developer is not gonna tell you, I hate coding. Uh, or, or if that's the case, they, they, they should think about potentially changing job.

But, um, it's, it's about, uh, 80% of their times that they're spending not coding. And that's really where AI and LLMs can have a massive impact. Um, and, and in, in, in improving the life of developers and get them to do what they like, stay in the flow, stay in the flow as much as as possible.

Uh, one of the objective at CloudBees, uh, when it comes to AI is to try to, uh, uh, bring the time spent by a developer on non-coding, non-coding activities to, to zero, right? Uh, obviously it's aspirational. Um, but it, it's, it's, it's a good aspiration.

I think a lot of the folks I talked to are kind of torn in their minds. They have, many have invested in DevOps, they have platforms, and they've customized those and extended those out for better or worse in some instances. And, and they're reluctant to give up that.

But there's an argument to be said that maybe we reached a point where we need a new platform because the capabilities that we're in need for today and tomorrow. Well, you know, we weren't thinking about that stuff five years ago. So, you know, what's your advice or how do I kind of navigate this if I'm already invested in DevOps and I'm looking at these next generation platforms?

I, I, I'm, I'm, I have to say that, uh, I, I'm not completely, uh, uh, um, um, I don't know if I, I would say I'm hugely skeptical or, uh, I'm hugely open. Uh, I guess they're all true. I think what's amazing about DevOps in general is the pace at which we've been reinventing ourselves.

We are trying to deliver software better, faster, more secure. That's what we're trying to do. You can call it platform engineering, you can call it DevOps, DevSecOps, it doesn't really matter.

You adapt to the problem at hand. And I think different companies have different DNA, they have different legacy, they have different aspirations, and based on that, um, they should pick the methodology and the solution that fits their needs in the better way. Um, but I don't think there is one single answer.

It also depends on your size, on your ma on your maturity. So I don't think, uh, say, because Spotify did one thing, then, oh, everybody should do it. Uh, it doesn't mean that because, uh, uh, uh, Spotify did it one way, nobody should do it, right?

And, and, and you can see, uh, and we're talking to companies day in, day out about DevOps, and you see that their practice is vastly different from company to companies. They might each call them platform engineering or DevSecOps, depending on who you're talking to. But when you double click and look at what they're doing, it's always pretty unique.

Um, so I, I think what, what we care about is offering flexibility that makes it possible for you to embrace whatever makes the most sense. Um, I'm more skeptical about approaches that are very opinionated, that guide you in a very strict way, because they might work for you, but they might not work for a lot of other companies. So I, I think keeping an open mind, uh, keeping also a, a, a a strategy and a a, an approach that makes it possible to embrace third party solution is, is extremely important.

Right? We were talking about AI a minute ago, as you know, Mike, as a, as a, the innovation in, in DevSecOps has just been amazing in the last decade. And so being able to leverage those innovation, uh, whenever you feel like it is, is, is a net positive, right?

And of course, what works today might not work tomorrow, right? So you need something that's flexible. Yeah, exactly.

I was, I was reading a, a very nice blog, uh, uh, a few, a few days ago on, on somebody, uh, talking about, uh, uh, the evolution of DevOps and then DevSecOps, and then platform engineering and going through it and listing the pros and cons. And, and you can see it, it's a journey. And reading this, I was thinking that's really their journey, his journey in, in, in that specific situation.

And that person was ending the article saying, actually, I'm, I'm having a lot of, uh, positive experience right now, writing bash scripts and pulling containers, and I'm, I was like, you know what? Good for you. Not sure it's gonna work for all type of companies, but, but again, it it's not wrong or right.

It, it, it's what seems to work for them today. So, uh, go and do it. Mm-Hmm.

What's your best advice then in the leaders of DevOps teams that are trying to navigate a couple of things, they want, uh, to write more code faster and to be more competitive, and yet there are these, um, issues around security and also quality for that matter that, uh, there's a sense of, well, do we need to slow down to achieve that? Or what's the right balance there? Because again, um, a lot of developers are, they're rewarded more on features than they are on fixing vulnerabilities, but yet fixing those vulnerabilities is a more pressing issue.

Yeah. I, I think there, there is, um, we, we, it, it's a matter of balance. It's a balancing act, and it's very important to invest on both sides.

Um, uh, I think it, it, it would be a mistake not to leverage ai, uh, for productivity to go faster, code more, and, and so on. It, it would equally be a, a mistake to not leverage ai, uh, to make your code, uh, safer, more secure. And, and, um, and, and so yeah, there is a, I, I agree.

There is a period of, uh, of a bit of unknown. We don't know what we don't know. Things change very fast.

A problem that you had three months ago, maybe it's not a problem anymore. Uh, and what you think not is not possible today will likely be possible in three months, or stick in six months. So I think it's, it's very important at that point in time right now, when it comes to AI to keep a very open mind.

And, and I, I don't think, uh, organizations should necessarily spend a huge amount of time, uh, uh, toying with a lot of things, right? Because it's, it's pretty easy as well to, to get stuck in, in, uh, lots of, uh, of, uh, experimentation left and right. They require pretty smart people as well.

So, I, I, I think a good way to, to do that is, is to look at some of the solutions out there and, and, uh, um, be able to test relatively quickly, uh, uh, is that solving a problem for me today? Or is it more aspirational if it's aspirational because the output is 20% of it is good, 80% is less good, maybe come back to it in six months. Um, but there are solutions that will provide you with, with, uh, um, actual, um, benefit right now.

And so prioritize based on, on, on, on this, I would say, All right, folks, well, we're just coming off the Olympics and acrobatics was center stage. And at the old end of the day, then it's all about balance. Guess acrobatics and DevOps have a lot in common.

Hey, Sasha, thanks for being on the show. Exactly. All Right, you, Mike, Back to you guys in the studio.

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. Welcome to the Tech Field Day podcast, where each time we meet, we bring together a group of independent IT experts in the community to discuss or debate a topic or a premise that is of importance to the enterprise IT community.

This podcast is related to the Tech Field Day event series, which is an event series focused on practitioners that discusses important and key topics in enterprise IT technology. My name is Tom Hollingsworth. I'm an event lead for tech field day, part of the Futurum Group.

I'd like to take a moment for our guests to introduce themselves before we introduce today's premise, starting with Rita, Rita Younger on Twitter, find me at SDN girl Josh Wco. You can find me on X at or Twitter, whatever we're calling it these days at wco. I'm Rob Coot.

You can also find me on X slash Twitter at at rob Coot. Thank you very much for joining us today. Let's discuss the premise for this episode.

Unless you've missed some important news, you know that gen AI is a very hot topic in today's environment, whether we are using it to predict how, uh, autonomous vehicles will drive, whether we're using it to surface insights, or in the case of networking, allowing it to tell us more information about what's going on and suggest ways to make the network better. Wait, that kind of sounds like a job that a network engineer would do, and we want to know, is AI smarter than your average network engineer? So I'm gonna start off by opening this question up to the panel.

We all have a, a wealth of experience when it comes to network engineering, institutional knowledge, things that we've learned over the years, and quite honestly, we've had to relearn some things over the years. Do you think that your average AI or even your most advanced AI today is smarter than your average network engineer? Well, I believe that AI is going to help the network engineer.

Um, AI will never replace the network engineer today. Everyone's looking for simplicity and visibility in their network, and AI will give them that visibility first and foremost, as well as the simplicity. And it's really important when we're building these different AI models to help with networking, that we do keep the interfaces very simple to use.

Now, it's not gonna replace the network engineer. The network engineer is still gonna have to review what AI suggests as far as implementing changes and determine if they need to make that change or not. And having a continuous feedback loop so that we have the ability to inform the AI model if that suggestion was valid, is a very important part of that process.

Yeah, I I would have to think about also what we mean by average network engineer, I guess, right? If I, if I prompted an AI and says, give me your top three average network engineers, you know, what would they say? Right?

Um, it, it would be interesting to figure out like at what skill level we're looking at AI to like augment and or replace. Um, I think it's pretty common knowledge, right? We're expecting AI or, or those that are learning how to use AI to become more productive in their jobs, not necessarily replace.

So I'm personally not afraid of like being, you know, the average network engineer being replaced by ai. It's maybe just a, you know, the, the, the individuals that are learning how to use it a little bit better are gonna maybe rise more to the top right in their teams. Yeah.

You mentioned the word average there, and I think if we look at the way, um, current AI's chat models and LLMs are being trained, uh, as they're trained more and more within these environments, I think average is a good word to use, you know, the regression to the mean, the, the LLM and the chatbot is going to learn from the questions it's asked and the people it's working with, and probably going to end up a fairly average tool based on the average people that it works with, right? So you're, it's only as good as the data that it's being fed and, and the models that it's learning from. So as more misinformation gets into these LLMs, the more you're gonna get misinformation out of them.

So, I mean, so let's, let's address the, the average elephant in the room, because that is a really good point. And I'm gonna fall back on everybody's favorite definition of average from a legendary comedian in George Carlin. So think about what you consider to be the average network engineer and realize that half of them are dumber than that by your own definition of average.

But what is average? If we have, if we have 200,000 people who have an associate level of knowledge and 50,000 people who have an expert level of knowledge, then the average tends closer to an associate level of knowledge. We see quite frequently that there is this gap between what people expect and reality.

How many of you have ever seen the infamous, um, I want someone with A-C-C-I-A level of knowledge, and this job pays $35,000 a year because it's really an entry level position when in fact, what you really want is someone who's slightly smarter than your average CCNA. But I don't want to pay a very competitive rate because those people are expensive. I can see some kind of a gen AI solution offsetting that job role.

It's like, this is entry level. I'm not gonna pay somebody to basically, you know, program VLANs and, and do these kinds of things. I can get a script to do that, but that's how we all learn, right?

I mean, I, I didn't jump into a core switch in an ISP and start de typing debug IP packet detail as my first job. I had to make my mistakes along the way. So is gen AI raising what we would consider to be an average level of network engineer to a point that's unsustainable?

I would say it's definitely a, another tool in the toolbox for any network engineer. Um, you know, and, and any tool that we use on a day-to-day basis is only as good as how we use it. And I think if you're, uh, whether you're an entry level engineer or an expert level engineer, if you're using a chat bot or an AI to augment your day-to-day tasks, uh, we talk about trust, but verify, you know, take the output that the chat bot has given you and, you know, vet that against what you know and the change you're trying to make versus just having the chat bot even execute those changes for you, uh, makes it a powerful tool, but one you have to be careful with.

Yeah, I would, I would say from, from some of the AI things that I've seen for specific to network engineering, I would say my hot take is no, it's not smarter. Um, the, the data that's coming into the, the model, the questions that it's being asked and how that's getting fine tuned, uh, and how expensive it is. Some of these tools are not cheap.

And you, you brought up the pay thing, I would say I, I would rather have three to four entry level individuals, right? Learning and progressing in their skill sets for the price that some of this AI stuff costs, right? Yeah, and you made a good point.

It's only as good as the data, uh, that is initially entered. Um, so we do need to make sure that that data is valid data. And, you know, some of the solutions that we've looked at will take data from multiple vendors.

Uh, so being able to analyze the network from end to end, even with multiple vendors, that is a really key thing that AI can do for us, because a lot of people who are trained in networking are trained in just one particular vendor, not multiple vendors. So what happens when the paradigm shifts and we're no longer talking about on-premises, traditional land networking, now we're fighting with, uh, you know, SD WAN or cloud-based networking, and the concepts may be similar, but we're still kind of on the, the cutting edge of things. And now I need to redeploy my assets.

Well, in, in traditional networking, I grab three people who are not as tasked and be like, here's a book, learn how this VPC thing works. But if it's an ai, do I have to get a new model? How long is it gonna take me to rewrite my code to adjust for these new ideas, how much it's gonna cost me?

Yeah. To retrain this model? I think we're seeing a lot of that today, right?

As new products come along, as software gets progressed, right? You, you're, you're in a constant motion of retraining things or adding new modules. It's like the module of module approach, right?

And as we've seen through automation, right? It's like, how many different automation modules am I gonna have to learn to actually make this thing work? Uh, I think that's just gonna be part of what we have to deal with.

I'm gonna have to retrain, I'm gonna have to add in more modules, and you're gonna have that individual that becomes responsible for adding that. I think we've seen a lot of people, especially on the OEM side, who's developing these products, right? A new vendor comes along and they now have to bolt that in, right?

We're gonna have to take the same concept and put that into ai, right? I've gotta add the data, I've got to teach it this new piece of software, I've gotta teach it this new vendor. So you're almost maybe even creating another role to keep the AI up to date, just like you would be training someone an individual.

Yeah. I keep picturing, uh, neo lying in the chair, waking up going, I know kung fu. Like you're just gonna be plugging these modules into your AI to constantly evolve it to keep up with the newer technologies.

But everybody has this fear, and we've heard about this over the years of, of different automation, um, you know, tasks or tools that have come along. And cloud was gonna destroy networking. Automation was gonna destroy networking.

Now AI is gonna destroy networking. I don't think, uh, we've seen any of that come to realization. And I don't think AI is going to change that.

It's again, gonna be just one more thing in our, our toolkit that we use on a regular basis. You know, I'm almost over here smiling because I'm thinking back, um, hearing celebrities talk about how AI was gonna replace all of the writers in Hollywood. I'm like, are you kidding me?

So I think the general public and the media, um, that they watch doesn't understand the value of AI and what AI can actually do. Uh, AI is still gonna require human interaction. It will not replace jobs, but actually create more jobs within the tech sector.

And I think utilizing the tools that are available through ai, there's just so much promise in the future. Um, being able to cut down the meantime to resolution from days or hours to seconds or minutes, uh, is incredible. And we've seen outages with, uh, some of the large companies lately, and a human error can cause that outage.

You know, if we had some way to verify, um, before the change was made, then that could have prevented an outage. Many outages, right? Yeah.

I like that point about, you know, being able to process things a lot faster. That's definitely a value that AI brings, right? I can feed it a whole lot of data and as a human, I know what to ask it, right?

The AI doesn't know what to ask itself. I've got to provide it some context and some intent of like, I, I see this happening. Here's the human intent and here's the question I'm gonna ask it.

It has the ability to process that huge amount of data that comes off the network a lot better than I can process it. Yeah. Or even ingesting suggested changes to configurations and, and looking for possible, uh, outcomes that you didn't envision or you didn't predict.

Like if I make this BGP change or all my route effector is gonna fall over. Like good, good way to vet the, the changes you wanna make too. Mm-Hmm.

In, in a way it's kind of going back to your example, talking about the matrix, waking up saying, I know kung fu well, what was morph Fus next line? Show me. Like we, we want to verify that the system is capable of doing the things and of coming up with creative solutions that we may not, but it kind of goes back to those issues that we run into all the, the time where, as Rita mentioned, like the hype around what AI is gonna give us is radically different than what it actually is doing to hear everyone talk about it.

It's the unveiling of the first iPhone, right? It's this magical communication device that's gonna change the world, when in fact, what we're actually doing with it today is making a slightly faster horse that eats a little less hay. To coin the phrase from Henry Ford, you can't sell a slightly faster horse to shift the industry.

You have to over promise and then hope that the system will catch up. I mean, it's only been a year effectively since we've really seen the hype start building around this idea of GPT algorithms. And already we've seen move and counter move.

It's like, oh, it's gonna write all my homework for me. No, actually it's not. And here's why it has limitations and here's things that we're finding out about it.

And now people are like, well, I trust it to give me advice, but I'm never gonna let it go loose in my network to actually do any of these things. So do you feel that we are in strict, we are creating structure and restrictions around AI that prevent it from growing to a point where it could potentially eclipse our jobs? Yeah, I think, I think, um, I, to to the horse analogy, I think we're at like a horse ride at the fair or the pony ride at the fair ride.

We want to try it out, but not necessarily let, let's just go for like the full horse riding experience, right? We just wanna try it out, make sure it goes around and encircle, get off of it and go, that was fun. And then go from there as we build some trust in how it works.

Trust is a key word. Yeah. Um, I don't know about you all, but I wouldn't trust a self-driving car.

I know it's capable of it, nor would I trust a self-healing network today. I need to be able to build up that trust. And I think we as an industry need to be able to build the trust in ai.

And that's only, that's gonna come from using it over, not just a year as it's been over years. Yeah. I mean, it's a popular phrase in networking and insecurity, trust, but verify.

Right? Right. We talk about that all the time.

So, you know, a lot of these tools we see coming out have those caveats around them. They say, you know, these, these chat bots and LLMs are fallible. They're only as good as the data you've put into them.

And they can make mistakes. They're, I've heard them described as petulant teenagers. You can't trust anything they say, and they're often wrong.

So you have to verify the information and the data you're getting out of them. Um, and that's gonna, that's what gonna require people to do. Okay.

But who's accountable? True. But let me ask you this question, because we talk about AI as being petulant teenagers, but those are the same petulant teenagers that we eventually hire to be junior network administrators, and we watch them make failure mistakes and we train them not to do them anymore.

And we encourage them to learn and to grow and to be better people. And eventually we do feel comfortable releasing them into the core of our network to, you know, do change windows and things like that without supervision. Are we putting too much trust in people when we should be putting trust into things that we absolutely can control?

Like algorithms? Those, those senior network engineers that have been doing the job for 20, 25 years, they still make mistakes. Hmm.

Doesn't matter how many lessons they've learned over the years, they might not make the same mistakes, but they still make mistakes. So I think chatbots and LLMs and all the AI tools, just like people are going to continuously learn, and in this industry, definitely, if you're not learning every day, you're not keeping up. That's Right.

But, uh, to go back to that whole idea, yes, even the most senior network engineer is capable of forgetting the VLAN ad command or, you know, using the wrong switch on a command that causes something to fall over and we just kind of shrug our shoulders and go, yeah, they're only human. But yeah, every time an AI makes a mistake, it is the, the sky is falling because computer programs are supposed to be perfect and they never make errors, and every error is a huge problem. You know, you think about nasa, they, they've been interviewed multiple times now about the whole commercial space thing, and they're like, yeah, we don't blow up rockets because the first, the next rocket we blow up will be the last one we blow up.

And it feels like we're holding certain things to a much higher standard than we would expect of anyone that is not generated. So, kind of coming back to it, maybe are we being a little too lax with people? Should we hold them to a higher standard?

Yes. Spoken like somebody we should, who is a senior network engineer? I mean, the, the, the reason that I said yes there is because you, you, you stop going down the criminality route of like, okay, we're humans.

There's some, there's some things that you can have in a human conversation that you can't have in an AI conversation, right? And, and if we get over the criminality part of like, Hey, you made a mistake, that's fine. We'll move on.

How do we learn from this? What can we do better? What processes can we put in to not make that same mistake again, knowing that you will make another?

And I don't think we've, we've reached the level of trust, we've reached the level of ability to have that conversation with machines. Maybe one day we will, maybe we can start seeing how machines are talking to machines and see how that works out. There's been some really fascinating things about that, about how right machines start developing their own language and start talking to one another and, and something completely misunderstood by a human.

So I think there's some really cool things. We'll, we'll see. But you know, yes, we should hold accountability and it's easier to have that accountability when we can have some, some emotions in a conversation with another person.

So I'm gonna flip the script as we kind of go here to close this out. If you are the average network engineer today, what can you do to be smarter than an ai? What's one tip you can give people listening to this podcast that will help them secure a future for their role?

I would, I would, um, you know, parrot what I said earlier, which is trust, but verify. You know, use AI as a tool, but don't use it to do your job. Use it to enhance your job.

Use it to get another set of eyes on a change you wanna make or a problem you're trying to face, but also still go to your seniors, your other network engineers, people in the community on Slack, on Discord, on on X or Twitter, and ask questions. That's all you can do if you treat an AI tool as just another resource to ask questions. But don't rely on that as a sole tool, the singular tool that you use to do your job.

I think you'll be successful and you may end up an above average engineer. Yeah, use it. Absolutely.

I think we're gonna see more and more of it. Um, lots more field days are probably gonna be about ai. So learning how to use it and how to prompt it and how to validate data coming from it, I think is gonna be hugely important to augment your current job, make you better, better than average.

And every network engineer is gonna make a mistake at some point. Um, a tool that you can use, of course, is the AI tools to help prevent that mistake. Um, but any network engineer who has made a mistake does not take that lightly.

They will never forget that experience. I had a young network engineer that was beside herself about a mistake, and I said, let me tell you about the mistake I made. I can tell you exactly where it was.

And then somebody who was kind of in between our ages popped in and said, let me tell you about my biggest mistake. So mistakes happen. The more tools we have to prevent those mistakes, the better.

So embrace ai. Thank you very much for joining us today. Um, if people would like to connect with you and continue this conversation, where can they go to do that?

Rob, Uh, as I mentioned earlier on, uh, x slash Twitter at Rob Coot, or I'm on LinkedIn as well, Same two places. LinkedIn, Josh Wko or at workup on x on Twitter And Rita Younger on LinkedIn or on ex Twitter, SDN girl. Alright.

Thank you very much for joining us for this episode of the Tech Field Day podcast. You can catch all of the episodes of this podcast on our YouTube channel, as well as in our podcast feed. Please make sure that you subscribe so that you don't miss an episode.

This tech podcast has been brought to you by Tech Field Day, the Home for Independent IT experts that bring you the conversations that you want to be having about enterprise IT technology. It's part of the Tech Field Day event series, which is a part of the futurum group. com.

We'll see you in the next episode. Hey everybody, and welcome back, Techron Unplugged. This is episode 14 of our series, and I'm your host at Dan Solomon On Text Unplugged.

We dive into all things tech and get people up to speed with everything happening across the industry. Recently, our co-host, Cassandra Chen, went to the Great International Developer Summit, also known as gis at GIS 2024, Cassandra sat down with Scott Davis, who's an expert in digital accessibility and cutting edge technologies. Scott dives into the evolution of technology from typewriters to modern smartphones, as well as the importance of multisensory architecture and computing.

Finally, he emphasizes the significance of accessibility in technology. Without further ado, let's it over to GID 2024. Welcome back to Textron Unplugged.

I'm your host Cassandra Chin, and today we have Scott do a short introduction. Oh, it's so nice to be here. My name is, uh, Scott Davis.

Um, uh, i, I do a lot of work in, uh, digital accessibility and conversational UIs and, and, uh, cutting edge technologies. Can you tell me a little bit about how you first got started into technology? Yeah, it's kind of fun.

Um, my parents, um, met at IBM and so they were, they were, um, my dad was a software engineer, and so acorns and trees, that's, that's where I'm as well. But my mom was actually, um, working with the IBM Electric typewriters and, and these typewriters back in the 1960s and seventies were some of the earliest ways to kind of automate, uh, uh, the, the IBM Flector typewriters had a memory record feature. So if you were constantly signing letters the same way, sincerely, Scott Davis, you could very carefully type that in once and then have just, uh, hit replay on that.

I didn't know typewriters could do that. Isn't that something? And again, that predates, uh, uh, computers.

But, um, I literally grew up with computers in the house. The first IBM PC was released in 1979. I was nine years old at the time.

And so it was my dad that taught me how to build spreadsheets and how to do programming and things. But it was my mom who had the hardware experience, so she was fearless about cracking open the computer and adding more ram or adding new drives or things like that. And so, um, there was no hope for me to end up in anything other than computers.

Given my upbringing with both fans, I could definitely see that. And you had both the hardware and software side to see. Absolutely.

Absolutely. Um, so you played with typewriters a lot. Ever take them apart.

It was really something, even something as simple as changing the font, we would just go up to a view menu or a font menu and change that. Right now, the way you would change the fonts on the IBM Electric is there was a golf ball sized head that had all the letters of the alphabet on it. And so if you wanted to change fonts, you would pull out that metal golf ball and drop another in.

So I, I love that with software. Um, so much of what we do in software is build, um, metaphors for real world things. And so having a real world typewriter in my background as a child, it, it led really easily to having a keyboard saying, okay, I'm not typing on paper anywhere.

I'm typing on a computer. And now that leads to smartphones where we're typing on glass and oftentimes we're not typing at all, but we're using our voice, we're using gestures, we're getting haptic feedback as our phone buzzes. It's, it's an amazing, uh, communication device beyond like the very traditional keyboard that we kind of associate with being a computer programmer.

So you really got to see each step along the way of how the typewriter evolved and eventually to a phone. Oh, Absolutely. Absolutely.

I remember when the first, uh, um, iPhone came out in 2007 and the first Android phone came out in, in 2008. And it was hard calling it a phone because I don't know about you, I rarely speak on my phone anymore, but I constantly pull up the internet or I text or I, you know, play with apps or all of those kinds of things. So it's amazing seeing that kind of change in society where in 2006, no one had a computer in their pocket.

And now, um, the market penetration for smartphones is 90%, 95%. It's something that's just become ubiquitous, um, in my lifetime. Like I'm with you that I don't actually talk on the phone anymore, right?

It's like our AirPods are kind of the new phone, It's the truth, right? But we do end up talking to our phone quite a bit. You know, you do end up saying things like, Hey, Siri, play this album.

Or Hey, Siri, set a timer, or, Hey, Google, do this, or, Hey Alexa, do that. And so it's interesting that we're not talking to other humans anymore. We're talking to our phones through conversational UIs.

But as a programmer, um, I know that I can't just say to my phone, Hey Siri, do you remember that one movie that was out with that one actor and that other actor? And I really loved it. And then it, you know, she's not gonna understand these kind of very open-ended vague questions.

And so when you're in conversational UIs, you kind of realize you need to talk with a purpose. And, and so understanding even the nuances of the differences between talking to a computer and talking to a human, um, you know, just make it interesting. What Do you think of talking to ai?

I think it's fascinating. Um, speech synthesis or text to speech has been around for decades. When Steve Jobs introduced the original Macintosh on stage back in 1984, he had the Macintosh speak.

He said, oh, it's so good to be outta that bag. I'm so glad to be here. And all these things.

So speech synthesis is something that's been with us for quite some time, but it's only been in the last couple of years where speech recognition has come in. And that's just a fascinating new aspect of being a computer programmer because you can't be limited in, in what you hear from, uh, a user as they're talking to you. You need to be able to say, Hey, Siri, play this album.

Or Hey, Siri, play this song. Or Hey, Siri, play this artist or this playlist, you know? And so there's a lot more nuance, um, in a conversational UI that's trying to recognize what you're saying.

'cause the human language is so rich, there's so many different ways to express yourself. The, the computer, the uh, recognition, the speech recognition has to account for all of those nuances. So Do you think AI is kind of going to fill that gap and make speech more possible with the nuances?

I Really do. I really do. Um, the, um, current way we talk to computers, we have a very limited what's called bounded grammar.

They're just very few words to that that, that you can use, you know, set a timer or play a song or turn on the lights. They're very feel set of like programming. Yeah, yeah, very programming.

And what AI is allowing us to do with generative AI is, is we do get to be more conversational. And I could say something like, oh, I was just in India and I had my Soma salada for breakfast every morning. And I just love the cultural differences of India.

What are some of the things you can tell me about India? What are some of the things that are different, um, from India than Colorado where I'm from? And so we, we can be more open in the way we talk to computers and our expectation is we'll get more open, more artistic, more fluent answers.

So that's the next generation we're coming into. It'll be exciting. Do you think We'll hit a wall where like there's still something which ai which we can't do?

So it's funny because it's not magic to me. I know that there are humans behind the scenes building these kinds of things. And so you do understand the subtle nuances and the limitations of the technology.

I don't think that we're, um, anywhere close to true intelligence. I prefer machine learning learning. I think that's a much better, uh, job of that.

But if I show, uh, uh, a machine, a million images of breast cancer, um, that's machine learning. And so when I start showing it new images of, of, of X-rays and it can detect cancer, um, in there and everything, that's wonderful. And I almost would prefer that level of technology than, Hey Siri, tell me a good joke.

I actually agree with you. Like we teach the computer and we kind of get out what we expect. Yes, yes.

But the con conversationally why the speech is just another way to interact with the computers. Um, a lot of what I talk about is multisensory architecture. And that computing now really needs to touch all of your senses.

It can't be just one dimensional. And so if you can read something on the screen, can you hear it as well? Um, if you can type something on a keyboard, can you say it as well?

And so what I love is we're moving into a new era of sophistication in computing where it's not one dimensional where you have to type commands in all uppercase at a command line. You know, we, we, we can bring more nuance in and I can talk to the computer when it's, uh, convenient. If I'm making bread and my hands are covered with dough, I wanna be able to say, Hey Siri, set a timer for 20 minutes.

Um, and we're at the era now where I can, if I've got a timer going off, I can just hold out my hand and click my fingers in thin air. And so we're just discovering a whole new set of interfaces. And once I start doing gestures in thin air and computers can recognize it, that's what makes me feel like I'm living the future.

So maybe technology is even getting to a point where we'll spend less time staring at a screen. I would hope. I would really hope.

Um, you know, uh, uh, VR goggles are, are kind of an interesting way because it's not only just you looking at the world, but it's a computer overlay of things. So I love that. Even Yelp on the iPhone.

Um, you can certainly search for individual restaurants and read reviews and things like that. Or you could just hold up your iPhone and look down the street and Yelp reviews will pop up over each one of the restaurants and you can say, oh wow, that restaurant is so close to me and it's got a bunch of four star reviews and everything. That's a lot different than typing in search criteria into a computer system, you know?

Um, it's holding a camera and looking at my surroundings and understanding the context and reacting to that. That's what I think is gonna be really exciting about this next generation of computing. Yeah.

'cause right now we kind of trained ourselves to learn how to read a map. Yeah. Hopefully You can kind of like connect the digital and real world more.

Exactly. Exactly. And like Google Maps, um, came out in 2004.

I had a, I was working on Google Maps originally, um, not with Google, but for a satellite imagery provider. And it's amazing to think that I used to drive without a GPS. I mean it's amazing to think that uh, as I traveled from city to city, I'd have to do research and I'd have to buy paper maps and I'd have to plan my route from the airport to the hotel and the hotel to the conference venue and things.

And now I can just kind of show up in a city unprepared and I can almost say, Hey Siri, how do I get to my hotel? Um, so excuse me. But yeah, it's um, it's just uh, interesting how computing is getting more sophisticated, um, which allows me to be less sophisticated as I interact with computers.

I can see that. Do you wanna talk a little bit about the accessibility in your talk? Yes, yes.

So I'm giving a keynote tomorrow Digital modernization through accessibility. And so many times people look at accessibility and they even say the word accessibility, but they hear the word disability. I could definitely see that, right?

I had a keynote that I gave years ago called, it's spelled accessibility, not disability. I really tried to address that upfront. But if we think about all the ways we're interacting with computers now as I'm talking to a computer, if I had limited mobility, that might be the primary way I talk to a computer.

Or if my speech is limited or unintelligible, I might have to, to type with a computer, I might have to begin doing these kinds of gestures. So I take a very yes and approach to digital accessibility. Yes, it's for our blind and low vision users.

Yes, it's for our deaf and hard of hearing users. These, yes, it, 25% of the world has some form of disability. This is not a small market segment.

If you have a disability, any disability, you're a member of the largest minority in the world. There are over a billion people worldwide that have a disability. So imagine a country the size of China, imagine a country the size of India.

It gives you an idea of the number of people with disabilities in the world. But while this technology is important for people who have limitations in any one of their senses or a combination of their senses, what I love is you and I are using these same senses to interact with our phone. So as I said, when I'm cooking, I love making sourdough.

If my hands are covered with dough, I want to use my voice. If um, I've got an alarm go off, I want to tap in mid air, sometimes it really is easier just to tap on my watch and start a timer again. So what I want is the ability to use all my senses and for me to be able to choose.

And I think for people with disabilities, that's all they want as well, is to have a multi-sensory approach to how they interact with the computers and not be limited to any one sensor one any one input modality. So you think like maybe more companies would build applications which use lots of senses if they sold it for a convenience and it would also happen to fulfill the needs for the dis dis accessibility. Yeah.

Yeah. So I was working for a client and they were getting ready to roll out a new, um, catalog of 20,000 items that they were trying to sell online. And I said, well, we need to have alt text on each one of those images.

We need to have words that describe what's in this image. So if you're selling a baseball hat with a green tractor on it, you need to have alt text on there that says a baseball hat with a green tractor on it. Um, and so for people who have blindness or low vision, they won't be able to see the image, but they'll be able to hear the alt text and be able to make an informed purchasing decision.

So this is the yes and approach to accessibility. Yes, we need alt text for all of our blind and low vision users and we need all text for the rest of the users as well. Because how do you think someone is going to search for a baseball hat with a green tractor on it?

They're gonna go to a search engine and type in those words baseball hat with a green tractor on it. So all of a sudden, accessibility is also related to search engine optimization. It's related to your sales goals and your marketing goals.

And so what I really try to talk about with my clients is we don't need to thin slice accessibility. We don't need to narrow our focus on that and put it to the side. What we need to do is realize that all of your customers have a variety of senses and they want to use all of their senses.

And so yes, accessibility is so important for that 25% of your customer base that has a disability and it's important for the other 75% as well. I think This is so important and I'm really happy that you're going to reach out to so many people. Oh, thank you so much.

It's something that's just so near and dear to my heart. It's just, uh, it's a joy to talk about. It's been Really lovely talking to you, Scott.

Thank you so much. It was a pleasure meeting you. Thank you.