Techstrong Gang – March 28, 2024
Mike, Mitch, Sharon and guest Tracy Ragan dive into the potential repercussions of the lawsuit filed by the U.S. Department of Justice (DOJ) against Apple. In addition, the gang looks at the current state of programming, the latest iteration of Java and the apparent lack of visibility most IT teams have into their application environments.
Transcript
Hey everybody. Welcome to the latest edition of the Textron Gang. We're gonna be talking about this DOJ lawsuit against Apple 'cause.
Well, there's a lot to take apart there, and it took us a few days to figure out exactly what was going on in this case. And then we're gonna move on to trying to understand what's going on in the world of programming, because, well, we all talk about all these great new languages, but it seems to me everybody's still using Java. And there's the latest version of Java 22 is out.
So we're gonna try to sort out exactly what's going on in that space. And finally, we're gonna look into observability because, well, we've been talking about that too for several years now, and a recent survey kind of suggested, maybe only one outta 10 folks are actually doing it. So let's get into the whys and where fours, this is Textron Gang.
I'm Mike Ardin. We'll be back in a minute. All right, folks, we're back with Mitch Ashleys visiting with us again from Colorado, and we have Sharon Florentine from Lovely Philadelphia.
And finally we got Tracy Reagan, who's one of our special guests and rotates through the show. So welcome everybody. Tracy, good to see you.
Oh, thank you. Happy to be here. Alright, well, let's jump into this whole lawsuit between the DOJ and Apple, which frankly kind of caught me a little bit by surprise.
I wasn't aware that they were even doing the investigation, but looking into it, Tracy, I'd love to get your thoughts. It seems to me this isn't a, a case about distribution more than anything else. I have so many thoughts on this case, but let me tell you right now, full disclosure, I do not use Apple phones.
I have never liked Apple phones because, you know, I run small companies. And the bottom line is, the one thing you can control in small companies is cost. And the cost of an Apple phone has always been so ridiculous in my mind.
I'm one of those people who, when we need nude phones, I have Steve go out and hunt something down on the, that's refurbished and we pay 200 bucks for it, and we do just fine. And the pictures are awesome, and I can read my Kindle, the Apple phone, um, and the whole app store conversation sort of is annoying to people like myself who have startups and who have small companies, because I really don't wanna pay Apple 30% of everything I write, they are forcing a reseller model, basically through their app store. Um, so I, you know, I think that the solution to the Apple problem is smarter consumers, honestly.
Come on, let's get smart about what we buy. Let's look at the cost of things. If you have an Apple phone every time you run a transaction, if you do a tap, you're gonna get charged by Apple for tapping your phone to use your credit card.
It is over the top to be, to be quite honest, in my opinion. Because again, I look at the bottom line, and if I'm a large company and I'm looking at, uh, supporting a, a, a ton of Apple phones, I I, I would be thinking another way. I'd be thinking, how could we cut cost here and getting rid of the Apple phones would be one way.
So smarter consumers are important. We need to stop thinking about the style of things. I used to get such a harassment from some of my younger software developers and people who know me with my old Motorola or my Android phone, they're like, go buy an Apple phone.
I'm like, no, I'm not going to. It's not a fashion accessory. I don't care.
I don't care if I'm not doing the most, you know, what's the cool thing? What I care about is the bottom line. And I think Apple's pushed it a little too far at this point.
I think that the, the, um, the whole conversation around the app store is needed. I was always frustrated with it When we looked at adding things to the, to the app store, we never did. All right, well, in my house, it's a split along gender lines, and I'm not sure if that's the case everywhere else, but the three boys are all wrapped up on Google and Android, and the ladies like the Apple and never the two can meet and nobody will move one way or the other.
But, um, Sharon, I know you have kids. What's going on in your house as you look at this whole thing? I tend to fall midway between, uh, Tracy's position and the, we are an Apple ecosystem.
In my, in the Florentine family, uh, I get around some of the cost considerations by upgrading as infrequently as possible. I believe I'm still on the, uh, iPhone 11 or 12, and it works just fine. I will not upgrade until it no longer accepts, uh, software updates because the hardware won't function.
So I, I get a lot of slack and, uh, pushback about that, you know, oh, well, you could upgrade every year. I, it works, it still works. It does everything that I need it to do.
Uh, now I am not by any stretch of the imagination an app developer. So, you know, that kind of conversation is a little, a little over my head. I think, um, I do think only really having two options.
You know, you go Apple or you go Android, I think that does spark a little suspicion in my mind about antitrust. You know, if, if there's only two options, that's not really a free market, is it? And, and that's kind of what the core of this is about.
You are eliminating all other options when you only have two. So, All right, Sharon's calling for not one lawsuit, but two, let's launching simultaneous, Mitch. I think there should be three.
It should always be anything you deliver should always be backward compatible. Come on. You know, that's just being kind to your end users.
But the cost associated to the app store is really, is the, is the issue here. Um, you know, every, if you buy something, you're gonna get charged an extra 30%. And if you're selling something, you're gonna get charged 30%.
Their reseller, their reseller app store is an issue. It really, it, it, it really is. I don't know.
It know they have this, this methodology to try to lock users into using the, the, the, the, the iPhone. I don't know how that does that, right? Yeah.
Like I say, me as somebody who's looking at every penny I spend and being careful with it, that's why I object to it. That's why I have a strong feeling about it. And, you know, if we were, if we were sitting here talking about a Mac versus a, a pc, which is kind of what this conversation is about, and you were charged for everything that you downloaded, even if it was supposed to be a PA free piece of software, but you're gonna get charged for using it, uh, you would, you would object.
And that's what's happening to the, um, you know, to, to consumers. Uh, and they're, they, I don't even think they realize it. And that this is part of the problem is, uh, an educated consumer.
We need consumers to be more educated about the, the products are getting involved in how they're being treated by that company. It's, to me, it's, it's, it's just wrong. And I'm glad the DOJ has picked it up and I'm glad it's a conversation because we need, we need interoperability.
We need, I should be able to use text extra wherever I want to use it, right? I shouldn't be restricted because my, my app, my, my operating system says, no, we don't want that competition. That is, that is a monopoly.
That is the definition of a monopoly. I think the, I think the, the pricing in the, the kind of gouging at 30% is definitely something that sticks in in users' crime for all of us, um, whether you're an Apple user or not. And that's, that's certainly one part of it.
I think the other, i, I dunno if it's bigger or not, but it's the anti-competitive practices. It's having one wallet that you can use the Apple Wallet on the iPhone system ecosystem. It's also, um, apple deciding who gets to play and who doesn't play.
You know, it's the WeChat dilemma, it's TikTok, it's all those kind of things where Apple is sort of the, the first and only arbiter of, you know, if we don't like you, you don't, we don't like you. If you don't like, like your practices of how you can sell things outside of our ecosystem, once you download your app off of our Apple store, um, then we're gonna do things to, to force you to change that so we can make money. So there, there are anti-competitive practices versus, which are always true in close systems, which is what Apple is.
And that's been sort of the debate of do you get the benefits of benefits of a closed system where things work better together more easily in theory, uh, versus something where you have to kind of help put it together, uh, with more open systems and open software. So I, I think, I think the, the cost of it is a factor, but I think the things that the DOJ can really hang their hat on is if they can really identify anti-competitive practices, and that's what they could do. Now, what's the remedy?
You know, are they gonna break up Apple? Like at and t? Uh, who knows?
I don't know what the remedies might be, but it, it's an interesting, uh, interesting threat to Apple for sure. All right, my cynicism, radar is off the charts here. So here we go.
Let's hear it. So let's just get into this for a minute, because there's a world of difference between what is illegal and what is immoral, and what Apple is doing is arguably immoral. But I don't see any of the legalese anywhere that supports this case as much as you would like.
And I'm old enough to remember the, uh, farce that happened around the DOJ and Microsoft back in the day when they, you know, sued them for allegedly having, uh, too much influence over the browser. And there was, there were all these supposed hidden hooks between the operating system and their applications. And that went on for years.
And as a journalist, I thoroughly enjoyed it. Every time there was an update to that case, we, you know, rushed down the courthouse. It was pre-internet, so you had to actually wait and get the actual transcript of what happened, and then you would sift through it, looking for story angles and all that other stuff.
But at the end of the day, it was a waste. Nothing fundamentally changed. There was a consent decree and Microsoft basically said, we agree that we didn't do anything wrong, and we will allegedly maybe behave better from here on out.
And their fundamental argument was, you know, operating systems, we add new features, it's called innovation, and we have a right to innovate. So there was, they basically said, we will continue to do that. And then the DOJ basically said, well, we're glad we brought this case again, but we declared victory.
But nothing fundamentally changed. And all the people that were whispering in the do j's ears for years about Microsoft all went home and said, what was the point of this exercise? Because nothing fundamentally changed.
I got a feeling this is gonna be more of the same, because we never defined what is legal or not legal in terms of what a provider of an operating system or a platform can do. So where's the case? Who's harmed?
And, and, and under what actual law, is there a remedy here, but just me saying, I'm looking forward to this, but I gotta say it's gonna be the same output as what I'm gonna say. So you're saying the lawyers make all the money and the writers get all the work. Is that what you're saying?
Uh, and I'm grateful for that. Thank you. Actually think that would be the outcome too.
If I had to predict I'd, I think it'll be a big nothing. 'cause it's extremely hard to prove anti-competitive. You have to get into price fixing and things like that between, you know, between companies and things.
So it's, it, we'll, we'll see where this goes, but it seems to be in vogue with the EU Commission suing 'em now, the us. So we'll see what Happens. And I think Tracy has it right, though.
It's up to the customers to go remedy this issue. But just like, which happened, you know, apple became a viable choice post DOJ, they gained more market share. And arguably, you know, Microsoft has more competitors than ever.
Lennox came along, gained traction, and probably is the, you could argue that Microsoft created demand for a reliable 32 bid operating system. It just didn't turn out to be the one that they thought it was gonna be. So, um, you know, Tracy, I'll give you the final word here, but you know, from what I'm seeing, thanks for the entertainment.
Well, I think, again, it's about, you know, a free capital market. Um, consumers are going, going to buy what they wanna buy. Another thing that Apple did well, and we haven't talked about this, um, and it was a term I learned in one of the tech strong women, um, recordings, and this idea of a mind map, part of what Apple has done really well, and I don't think this has nothing to do with the lawsuit, but it does have, uh, to do with having a sticky product, is they have taught so many consumers, people who are not technical, that there is a particular way you interact with your phone.
And when they go to touch another kind of phone like a Android, they don't have no idea what they're doing, because those operating systems are not similar in, in, in so many ways. I look at 'em, I, I've looked at an Apple, an iPhone of a, what is that? So there's that part that keeps the consumer, uh, coming back to an apple, uh, to an iPhone.
And for that reason, I believe that the, the DOJs, um, lawsuit is valid because there has to be a broader discussion about protecting consumers, uh, in this type of a market. Even though I'm, I believe in, you know, I, I believe in free markets. I still believe that there is something about that.
There's something about the way Apple has taught us to interact with our phones, and it's hard to, to move off of it. It's hard to move be, you know, it's hard to move between being a Apple person and a Mac person and a and a PC person. It's hard to be different, be either an Android and a, and an Apple.
So they've locked in the consumer just through this mind map of understanding how to use their phone, and they don't wanna learn something else. So that allows them to even go farther in, in exploiting the, the consumer. All right, this is actually an interesting, this touches on an interesting issue that I've seen crop up on Twitter in, or I'm sorry, x uh, in developer spaces lately around have we made end user experience even down to like the developer level, too easy, so that a lot of entry-level developers even do not understand how the basic foundational levels of technology work, the networks, the servers, the ISPs, all of that basic thing that makes up the layers on which an app is built.
So like, it, uh, support folks complaining that, you know, I had a, a senior developer come to me not understanding why something wasn't working, and it was, you know, a a network layer problem. And I'm looking at them going, how do you not understand how this works? So I think that's a little bit of a tangent, but it, it sparked that in my brain that, you know, maybe that's, that's part of it.
We've put so many layers of abstraction there that now it's hard to, to un unpeel them and go back to the underlying technology. All right, We're gonna, we're gonna, we're gonna move on to our next topic here. But I would just point out there's lots of addictions out there that are illegal, including gambling, smoking, and so getting people and taking advantage of them in software is not necessarily a crime just yet, but we'll see what happens.
All right, folks, we'll be back in a minute. 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, Hey, welcome back. We're gonna shift gears a little bit and start talking about what's going on with all these programming languages.
And I'm gonna start with Tracy because you're closer to this, but we've seen now the latest edition of Oracle's Java 22 is coming out next month, and they're touting that there's gonna be more innovation in Java. And I would argue that a lot of what they're doing is borrowing from other programming languages and kind of adding it more quickly into Java. And that's probably a good thing.
But we've seen the rise of JavaScript and Python and now Rust. What's your sense of, are people really adopting all these different languages? 'cause every time I look at a survey, especially in the enterprise, it's like we're using Java and then maybe some other stuff on occasion.
Well, are they, uh, adopting it or are they learning multiple languages? Because each language has its own feature? Right.
So, um, you know, in our open source committee and the Arterius open source community, one of the reasons why we went to a, a Kubernetes cluster with microservices was to allow developers to write in any language they chose to, which is super important because if you force a particular language, you restrict the number of contributors to the project. But Java in particular, um, is a little bit behind the eight ball, I guess you'd say, because they have lost some market share to some of these other languages that are simpler. Um, now the interesting part about the, the, the Java 22 is the, uh, the, is it's, uh, foreign function.
I think it's called a foreign function. Um, API, which allows you to, to do communicate past the, the Java, um, the j and i, uh, and that has to, we have to get rid of that, needed to go for some time. So, and all of this has to happen if you're gonna write, use Java to write AI code.
So while they're great new features, I think that Oracle's just being smart and protecting their assets by delivering what developers need for the future and cleaning up some of the, um, some of the aspects of Java that weren't, uh, completely, um, that we didn't love. Let's just put it that way. This gotta be faster, you know, uh, Java can, can is somewhat translated, I guess you'd call it, so it can be a little slower.
So they need to clean up the, this stuff, and I think that they're working towards that. And the foreign functions is, uh, one of the projects that's gonna deliver that. So I'm looking, uh, it'll be interesting to see if people start using, uh, Java more in AI development, because while we talk about ai, we talk about chat, GBT, we have gotten to a place where we're applying AI as a, not as a feature, but as a tool to develop software.
And, and Oracle can't miss that boat. And I believe Java, uh, the Java 22 releases more about that than it is about anything else. Mitch, what's your Thing?
Yeah, you know, it's, when we were in, uh, Kon, one of the things I noticed is how many people that I interacted with where the conversation kind of went back to all of us did job at some point in our career. I mean, almost everybody that I interacted with, maybe except somebody who was a more recent into the industry, I think you have to look at, when Java came on the scene, when Java really took off, it was a much easier programming language. It, it abstracted a lot of the environment out of, out away from, away from what you were doing in c plus plus and C and and c and other programming languages that were more complex to use.
Um, and it was very widely adopted. And I think part of the reason why Java isn't going away is it's just so much embedded code out there that it's Java code, it's massive. Um, but people also moved on, I think, you know, Oracle acquiring Java and that whole kind of took the bloom off the, the rose there for many people because Java was free and open and now it's not.
It's controlled by Oracle and people have whatever feelings they do about Oracle, good or bad. But I think part of that also, we moved into the era of new programming languages and starting with Ruby and then of course Python and, and go and everything else, right? You know, Jay note, et cetera.
And I think it is just, it let less people experiment and work in new languages that they're more comfortable in. Java is not the easiest thing to debug. It's damn hard to de to debug Java, um, if you don't do a good job of how you elicit the, the trap exceptions and things like that.
So it, it's not, you know, the perfect language by anything but the fact of the matter. It's the widely used Oracle has to keep it up to, to maintain that base and keep improving it. And I agree with the Tracy said, I think that there's a lot of catch up happening with these features that they're adding.
And our community prepares Python. Mm-Hmm. Most of the people who come to us to contribute wanna do so in Python.
Python, Yes. So I think that, uh, like you say, there's, I think it's, you know, every, every language has its day. How many people code and see anymore.
Um, you know, we, we do, we still have components of our c If we want something to be really efficient, small and fast, we're gonna go to sea. We don't go all the way to a similar, which is a possibility, right? But we do go to sea because it, it, it is ultimately, uh, a smaller binary at the end of the day and faster.
Um, but we don't, we don't hear a lot of people saying, we want code and Java anymore. We hear people say, we wanna code in Python. Alright, Sharon, I know you go slumming with some developers in Philadelphia from time to time.
Um, you know, what's their, uh, how inclined are they to run a to learn a new language? It, uh, from, from what I can suss out right now, and, and most of the folks that I know are mid to senior career, so if they're looking to switch jobs, they're gonna look first and foremost. You know, is it a Java shop?
Um, if they get in there and there's other, say, ancillary languages like, oh, and I need to learn Python or, and I need, you know, to pick up some Ruby or something like that, then they will will do it. Uh, JavaScript is kind of a natural add-on. I would say most of the folks that I know that are Java developers also pick up JavaScript.
And, uh, but it's, uh, you know, you first and foremost tend to stick with the language that you're most familiar with, that you've been doing the longest. I will say that when I told a couple of folks, you know, Hey, it looks like, uh, Java 22 is gonna come out here shortly. And they're like, oh God, we're still on 11, or we're still fighting through the upgrade to 17, or that kind of thing.
So I think the, the upgrading to the next iteration is really tough. And definitely the support because you know, now you have the support in place for eight 11, even 17, but then you gotta go back and make sure that those things are in place while you're doing the next iteration. And I think that's the toughest transition.
Tracy, is this a generational thing then? And we've got senior to mid-level developers that learn one language and maybe all the kids are going, Hey, boomer, I'm moving on to a different programming language To some extent. Um, I think that the, the developers who have been around the longest, uh, are just better at adopting new languages.
You know, the more you code, the easier it is to learn another language. Uh, and young developers, they get confident in a particular language and they kind of stick to that for a time. Um, and then they begin to, uh, gain confidence and say, okay, I'm gonna try, you know, I'm gonna start playing on Python or go.
Um, but I think that there is a, uh, simplifying that Sharon, um, had talked about in our previous segment. Uh, we do need better education around how software works, how the arch, what the architecture looks like, even how a computer works, you know? Mm-Hmm.
Ask, ask a, a college student about a bus and they're probably gonna say, which one I take this one. They're not gonna understand basic things about computer architecture. And that does have an impact on how you code, understanding what you're building, what operating system you're building for, what these tools should, what, what are the best tools for the, the, you know, for the application that you're creating.
Uh, and developers need to broaden their ability to pick up new languages because if you're building an application and you do need to do something that's more efficient, you should be able to pick up C. So the ability to learn more, uh, multiple languages, not get stuck in one, I think is essential. And I think the university system may be failing us a bit on that.
Uh, depending on what school you go to, uh, oftentimes schools stick with, you know, maybe visual studio and they learn a particular way of coding and they get through it. But being able to, to code in multiple language is a skill that everybody should have. Uh, and we should be looking at these languages for what's the best language for this particular problem set.
And that's why it's great to have something like microservices where you could build, you could use a language for every, for different functions, because that should be part of the discussion of how you're building that particular function. What's the best language for it? So what we need to have more, um, languages in our tool belt.
Yeah. And learned multiple times that, at least my opinion, the best developers I've worked with write their least amount of code. 'cause they wanna find efficient way to do things, and they don't wanna maintain stuff they don't need to maintain, which includes the right language to do it in the, the second attribute is they're systems thinkers.
They think vertically and horizontally of the software and the network and the environment that they're running in. Because so often it's not your code that's the issue, it's the other things you interact with or that support what your applications are doing. And those are the people who are really skilled where they can come in and tune something, make it much more efficient, or debug a really, you know, something is challenging that isn't necessarily in your code directly.
So I always advise developers to branch out and learn multiple things. You can specialize in an area if you'd like to, that's totally fine, but don't limit yourself to that 'cause you're operating in an environment. So whether you, you know, I taught my kids how to build computers when they were young, right?
So they would know how these things work. And you know, the, I think that helps with people understanding what this all environment looks like. So I very much support what you're saying, Tracy.
I agree in the sense that we should all learn multiple languages, including French, Italian, and Spanish, but we don't because people are lazy. Developers are people, therefore they are also lazy. And it's just the way nature, the way we are.
And hey, I'm hoping this 'cause everybody speaks English. That's why Mike, because we're lazy. Oh yes.
I'm, I'm, I'm hoping this AI thing maybe works out and helps us convert all these different languages into something we can all understand. And maybe I can have a conversation not only with somebody who is speaking, I don't know, Farsi, and then somebody in the programming world should be able to automatically convert from Java to Python to something else, or whatever's relevant or, but I think we're on the cusp of something there. I don't think we have the Yeah, we'll help you with that, by the way.
Yeah. I don't think we have a universal translator just yet, but cross your fingers. Well, it'll be there.
And just one other, you know, for anybody who's out there watching this and listening, um, if you really do wanna be become, you know, learn more than one language, you're, you're, you're in the industry. You've been coding for a couple of years, you wanna learn another language. A really good way to do that is to join an open source project.
There's so much coding to be done and the open source world, every project that I know of every project is looking for people to contribute. And it's a really good way to expand your coding experience beyond what you might be doing at work. I know it seems like a extra effort, but it is a great way to expand your horizons.
Let's just put it that way. 'cause you can learn so much and you can, a lot of projects like the Orillia project, we're saying, Hey, code and what you want. Um, but at the same time, code and what you want, but choose something new.
I would say final thoughts here. If you haven't learned anything new in the last six months, you're doing it wrong. We'll be back in a minute.
com is the number one online destination for DevOps education and community building. com covers all aspects of DevOps, including DevOps, best practices and tools, DevOps culture, DevSecOps, business impact, continuous testing, continuous delivery and more. com has the largest collection of original DevOps content featuring breaking news, blog posts, podcasts, and more.
com to learn more. com where the world meets DevOps. All right folks, welcome back.
We're gonna have a little chat about this thing called observability, which is a term that gets tossed around a lot. And I'm gonna try to level set this a little bit because I think on the one hand a lot of people think they are doing observability. It's been a core tenant of DevOps for as long as I can remember.
And the issue is though, we're looking at what I would call a set of predefined metrics that show up in a monitoring tool versus observability, at least as I understand it is supposed to be the ability to query the system to go find the root cause of an issue and see what's actually going on with your logs and metrics and traces. But Tracy, let's start with you. There's a survey that just came out that said maybe one in 10 organizations are actually doing true observability.
Where are we? What are the challenges? Well, you know, I've never played with an observability tool all these years in DevOps, and I have never actually played with an observability tool, but I have watched the market and I've watched, uh, and I've often spoken to people to ask, you know, how they're using these tools, um, and meantime to repair is probably the primary reason why they're using them.
And if observability isn't improving that, is there a reason to continue with using observability tools or, or at least making it a priority? Uh, I think that, you know, watching transactions and watching the data flow and data pipeline pipeline analytics is probably gonna be where observability, uh, observability tooling is going to help us more. And I don't know if the market really pushes that, uh, those functions and features, but it seems to me with the kinds of applications that we're building now, this explosion of dependencies and APIs running across and transactions occurring in so many ways that it's the, the, it's the pipeline analytics that is, that becomes more important as opposed to just trying to find root cause analysis.
Because it, you, if you're looking at, in a, in a microservices, in a highly decoupled environment, observability can be extremely complicated. So is it, is it useful? How useful is it to find what the root cause is?
And then you might find the root cause and it may take you an hour to find the root cause and you find an a, a microservice or a function that's an API that you don't even know who wrote. So there's other parts of the problem that, that observability needs to be able to solve. But I do think that the, the pipeline analytics and the data flow is really, really critical.
And it's particularly critical when it comes to security and understanding where your data's going. So I, I would hope that we see that that market evolve and really start pushing the, the pipeline analytics, the data pipeline analytics. I must wonder if people don't know if they're using an observability tool, in part because some of the observability products on the market were something else.
First they were monitoring tool, their log aggregation tool. There were a security tool. Um, and, and so observability has been an evolution of, of things and it's, you can say it's, you know, alerts, traces, and logs, but it's more than that too, right?
It's not a fixed definition of what it is. So I I, you know, you may be using a tool that may not be marketing yourself as, as an observability tool. And then there's also, of course, things that start out as kind of native observability.
So I was, I was curious that one in 10, uh, are, are know whether they're using it or not. Now, if you're in development, would you know that you're using observability tool? There's a lot of talk about using observability in development, but I don't think most people are doing that yet.
So there's a maybe a narrow slice of people who would really even know is what I suspect why that's such a low one in 10 number. But, you know, I don't have data to back of that up. That's just my opinion.
I Would, I think, Mitch, you're right, it falls more on the ops side than it does the dev or DevOps side. And we never really saw observability tooling going back, let's say, and updating those metrics in Jenkins, right? Mm-Hmm mm-Hmm.
So where developers live, they don't, they don't necessarily see that, uh, and that information may be useful to them, but they have never gotten in the habit of using it. Uh, so I, I don't think developers think about observability whatsoever. I think that they're worried about learning a new language and getting their code done, but Not fixing that Java code.
Yeah, exactly. I i, so, but it's an interesting market and the, the, the log aggregation within these fragmented, uh, environments are really critical to operations folks. So it's an, it's an important market.
I just feel like they have some pivoting to do. I had a couple of chats with folks about this issue, and after explaining to them what all the capabilities of observability are, they all looked at me and said, well, that's awesome. You know, we, that could really help us.
And then they would pause for about four seconds and they would go, I have no idea what questions to ask. And so they have this powerful platform, but they don't really have the understanding of the architecture to go poke around it in the first place to figure out what it is that they're gonna go looking for. So a lot of times it seems like they use the platform to remediate the, the immediate issue to see if they can just kind of get the system back up and running.
But they never go deeper than that. 'cause from an architectural perspective, coming full back to what Sharon was talking about earlier, if you don't know what the architecture is, you don't know what question to ask. So Sharon, is this, you know, going back to your early comment from the previous section, is this where we're at?
It's just like, I can observe something, but if I don't know how it works, it doesn't much matter. Yeah. I, I come full circle.
Um, I, I think that may be one of the big issues here. And, uh, I, I don't know how to solve that. It's, that's gonna take a, a long arc of time, right?
Because if you go back and you revamp the educational system to address some of these things, then that has to take time for those folks to get into the workforce and then share their knowledge and then figure it out. I, yeah. All right.
All right. Well, well, I'm gonna rant for two seconds about this because I do think that there is an answer. Go for, the answer's gonna be, we're gonna start throwing machine learning algorithms at all this data, and that is gonna surface, hopefully, you know, the issue of the day and tell me, yep, if you don't go fix these three things, they're most likely to get you fired any day now.
But, um, the issue then goes from there is to say, alright, if I do that, and I rely on the ai, I know even less about the systems and the architecture because it's all like solid state television. Nobody knows how the thing works at all, except maybe a handful of people who built the thing. So yeah, Tracy, is, is AI gonna make us dumber?
Uh, I, I think we're gonna, we're gonna get some really smart programmers out of ai, um, because we're new into this area and we're gonna, we're, it's gonna force us to really learn and understand, um, the architecture of the software we're delivering initially. Um, we're all gonna have to dig back in and figure out what's the best way to write the software. But when we, we go back to the observability and the, and the data flow, there's gonna be a massive amount of data.
There's gonna be transactions that are with tons of data that are, you know, that are going through our systems and they're gonna congest things. And we are, there's gonna be some serious work to do. Um, and that's, that's why I keep saying, and the observability world, what I would like to see them do more of is that the tracking of every transaction, the amount of data going through it, um, you know, where the congestion is, where the problems are gonna be.
Because when we, when we're talking about a ton of AI agents sitting out there in a, in a, in a, in a cluster, um, and they're, they're processing these transactions, we're, we're gonna need to know, do we need to increase the number of AI agents that we have? Where is the data coming from? Where, where are our problems?
So in order to really build some of these large language models and start really looking at the, the, the processing and the speed, we're gonna have to have observability and we're gonna have to have a better understanding of data flow and data pipeline analytics. All right. Thank you, Mitch, for being on the show, but I also want to thank Sharon for being on the text drawing gang because, well, this is her last episode.
You're gonna probably find her soon on another network. We always appreciate working with her though, and we expect to do so again one day soon in the future. Sharon, best of luck.
Thanks, Mike. All right, and Tracy, thank you again for sharing your thoughts and insights and for all you folks watching this, it's been our pleasure for bringing this episode. And stay tuned for the next one.
Bye.