2025 Will Be the Year of the Fragile App – Predict 2025

Hi everyone. I'm Guy er, I'm an analyst at the Futurum Group. I'm also CTO of Visible Impact, which is one of the divisions at RUM Group.

And I'm so pleased to be here with you for this live session at Predict 2025 from techstrong. 2025 will be the year of the fragile app. I think the 2025 will be the year of the fragile app.

And joining me to talk about this are two terrific and dynamic experts having to do with app construction and delivery and platforms and so forth. Starting with Hope Lynch Hope, say hi and introduce yourself. Hi.

Hello everyone. Happy to be here to have this discussion today and my bias, as you will see as the conversation evolves as to our platforms. Uh, many years in, uh, technology industry, platform engineering, systems engineering, just another name sometimes for platforms.

Um, CICD, just technology currently. Um, a lot of technology consulting and enjoying it and looking forward to this conversation. Uh, I'll pitch it to you, Amanda.

Thank you so much. And I see we both decided to wear green today coordinating. I know.

Yeah. Neither of you told me. So is gonna be two long one today.

You're Coordinated. So, hi everyone, I'm Amanda Ani, and I'm the managing editor for Textron Group and a podcast host, and I'm excited to be here. I, uh, see a lot of articles around this topic, and I've got a, a lot pulled up to reference today to back, back up some things that we say.

So I'm excited to get going. Mm-hmm. Great.

Uh, so fragile app, I thought when I thought of this, um, when I was thinking about 2025, I thought I had invented it, but Amanda helpfully found someone else who's been talking about that app fragility as well. Anyway, it's a, it's a common concept, but why would 2025 be the year of app fragility? There's two possibilities.

The apps are gonna be, uh, no more or less fragile than they, than they have been, at least for the past several years. But it will become more noticed and more discussed. The other possibility is that apps are becoming increasingly fragile, and that will reach a point in 2025 where it will start to get noticed and discussed.

In other words, either things haven't changed, but it's gonna become a meme and a thing, or things are changing, and that's why it'll become a meme and a thing. And I definitely am in the latter camp, I think 20, 24 alone already. Um, could have been, uh, seen as, you know, uh, a year where the fragile app was talked about and became a thing.

The CrowdStrike example is probably the biggest example that everyone has talked about because of how global and pervasive it it is. And CrowdStrike was already a well-known brand, um, and vendor, you know, even outside of the, even outside of the business community. Um, but, uh, I don't think that the fra, I think the fragile app has emerged as a topic more amongst, uh, those of us who are studying and looking at the market.

I think it will become widely known as more and more people start to have poor experiences using or releasing apps and trying to figure out why. Mm-hmm. I, I agree.

And in in line with what you're saying, I think it's, it's, um, you know, two lines that have now hit, hit a hit an inflection point. Um, if you go to certain stores now, it'll say, you know, no checks, no cash, right? Credit card only people are gonna pay by phone.

The more people who pay by phone, the more people who are gonna notice, Hmm, this app isn't working properly. It's not starting something, you know, something is going wrong. Um, the more devices, the more different systems that those apps encounter, uh, the more, the more problems they, they just, I think, are going to have, and, and this is probably yes, a good year for some of those problems to start showing up.

Yeah, absolutely. I mean, we're seeing a lot of those problems. Uh, just today I published an article by Mike Ard, um, so you can find it on text drawing, ITSM.

Uh, so our IT service management teams are really struggling here, but, um, it says survey surfaces a raft of patch management challenges. Um, a survey of 252 security and IT professionals published today finds more than 77% require more than a week to apply a patch to software running in IT environments. And those patches are becoming more and more so you're having some IT burnout, um, just trying to keep up with all these problems.

Yeah. So there's an incident and there's a huge lag. I mean, a week, uh, one of our correspondence, uh, um, Tracy Reagan, who's been really helpful in helping me recognize this acceptable or should be unacceptable in, uh, you know, in, in today's environment.

I think though, is it gonna reach the point, like I think where it becomes like, like I put it earlier, a meme, a theme, you know, uh, we've witnessed all these themes over the, over the years. Um, and I think that when things become a meme or a theme, that's when honestly, vendors start jumping in. I mean, obviously the biggest meme right now is ai.

This would be a different meme. That's where vendors start to jump in and market themselves to this problem. And I think that's really what I'm talking about when I'm talking about 2025 being the year of the fragile app.

Everybody already has to deal with fragile apps if they mm-hmm. Are building and producing them, that has not changed. Mm-hmm.

Um, there are tools out there to help, um, strategies and vendors to turn to and consultants and so forth. Um, but whether it gets the attention sort of at the corporate level or the budget holding level, that's the difference. And I think that will start to mount just this year.

A lot of other articles I'm seeing are showing, um, part of the problem is of course, as we are incorporating ai, we're, we're hitting even more struggles as we're integrating ai. It's both a solution and a problem if you, you know, read various articles. Yeah.

Let's turn, actually, let's start to talk about like, you know, what, what mm-hmm. Sources are there, um, that's causing fragile apps, particularly. Let's try to pay some attention to ones that are getting worse, seem to be getting worse rather than better.

I mean, I hope I, I'm an app dev person at heart. Yeah. I live in the app layer, so naturally I play, I blame the platform manager.

So I'm gonna turn to you And I won't, I won't, uh, completely disagree with you. Right. Um, because having been hands-on there, um, there can be moments where, you know, some problems just sh sit on the shelf for too long because no one is screaming, uh, about resolving them.

That does not mean that the pain of the end user is necessarily any less. Right. But in some defense, let's say, of the platform teams, part of what is maddening right now, if you are on a true platform engineering team, is just the absolute, uh, complexity of what you have to deal with.

It has, uh, reached a point with modern application architecture that platform teams sometimes are even trying to divide into, uh, specialized groups within their team just so they can focus because, uh, let's see, we've adopted microservices, cloud native development, uh, 12 factor methodology, but you know, here we are in 2025 and applications still seem, uh, as fragile as they ever have. There are so many applications that they have to manage. Uh, it, it is a challenge.

I'm glad you mentioned 12 Factor since I'm a big 12 factor fan. Mm-hmm. Because it reminds me a little of cloud native maybe in some ways, which is 12 factor is for the app dev, it's for the app side, it's for the, the, uh, dev side.

I mean, it's, it's for the coder. Mm-hmm. It's a way to, um, code such that, uh, the fragility of the platform, so to speak, doesn't matter.

Mm-hmm. Cloud native. I kind of felt the same way about Cloud Native originated not as a platform engineering prior to platform engineering, but not as a platform engineering paradigm, but as a coding paradigm, how do you code to fragile infrastructure mm-hmm.

Um, mm-hmm. But is that turning on its head? Has that turned on its head?

Uh, that, that, you know, the many, many sources of this complexity need to be addressed in the platform, not just in App Dev. Much as we app developers wish that we can solve everything and not have to, we rely on you poor people, And, you know, and just to drive, you know, our overall point home even more, right? If you think about a simple user transaction, somebody wants to, uh, check out on, on a website, right?

Modern Architecture one action, right? It can touch 20 services. You've got inventory, pricing, authentication, processing, the payments, fraud detection, shipping, everything else.

And any one of those, any one of those, uh, goes wrong. You know, failure point and the connections between them is also, uh, a potential failure point. So again, platform engineering can help, but there, there are just so many things that can go sideways.

One of the, um, interesting articles recently posted that I read, uh, had me thinking, um, and this is another, another article from Mike, but, um, and this talks about, uh, when I say AI being both a problem and a solution. Mm-hmm. So coder AI emerges to enable anyone to build apps using AI agents.

You don't have to be a coder. Now, you can use AI agents, which of course we're hearing a lot about AI agents. Mm-hmm.

Um, but it made me think, you know, as more people who don't have this background, they don't have this knowledge and experience, they don't understand code. Mm-hmm. And they use these agents to, to put out these apps, are we gonna see more problems?

Because they don't really have that experience and background. So it, it's great in one aspect, oh, we're lowering barriers, but without that knowledge, are we gonna see more problems in the future? Well, yeah.

It, that harness study that came out recently from the vendor harness mm-hmm. Um, according to this, you know, research study that they did, uh, AI coding has created deployment errors at least 30% of the time. Mm-hmm.

So, I mean, that is, isn't that the classic issue with a so-called fragile app, is the update creates the problem, which takes the app down. Mm-hmm. Mm-hmm.

But it's, um, It's not just about, so, so CrowdStrike had got got, sorry, sorry. Hope CrowdStrike got all this attention. Right?

Yeah. Um, but security incidents get all this, and CrowdStrike is seen also as a security company, right? So the, you know, one of the seminal incidents, even though it's happened only rather recently, was SolarWinds.

Mm-hmm. Okay. So, so, you know, um, these are where people are managing bad actors, making attacks and all that sort of thing, but the sources of difficulty with apps delivering like they're expected or they're supposed to mm-hmm.

Are Legion, and you described how these sort of dependencies up and down, mostly up, right? Mm-hmm. Dependent services.

There's so many pieces and parts to this, and they're not just in the platform layer, I fully admit, um, the, the, uh, uh, Venafi study from just last month, um, said that, uh, uh, 86% of organizations had some sort of security incident with a cloud native application, cloud native. Mm-hmm. All right.

Cloud native, so much attention, so much development around cloud native to, to ensure resiliency of applications. And yet about half of that 85% caused an outage or disruption in app delivery. And I don't see this getting better.

I don't see this getting better yet. There there was, there was a, um, uh, SNY did a, did a, a study or a report where they described something that I feel like I've, I'm, I've been sensing lately in the market, which is people are getting exhausted of trying to keep up with the messaging and the storyline and the tools and everything around application, resiliency and protection. I mean, Amanda, you, you, you're one of the editors you like, are you seeing this As well?

But here's the thing, and, and I was gonna point out, you had mentioned CrowdStrike. So, you know, the articles, um, from that fallout, uh, since then have basically shown, um, that they did take a hit, but they bounced right back. And, um, and, uh, there was a recent article, uh, what it service The brand, bounce right back the brand and Yeah, yeah.

Chaos. And, um, uh, it says further down this article, I found this interesting, uh, this was from my writer John Schwartz on Textron, ITSM. Um, as he interviewed people that dealt with the fall out of this CrowdStrike, basically they said, outages are not a problem we're gonna completely solve.

Um, they're just gonna expect that there's gonna be, um, problems with the app, there's gonna be outages. Mm-hmm. And, uh, you know, companies don't even, they anticipate there's gonna be problems.

They don't expect to solve them all. Um, so it's how to deal with, um, uh, the aftermath, um, how to handle communications and, um, and get back up quickly working again. Um, so, and I see a lot of articles about that, that really they have no solutions on, um, reducing the fragility.

Like they're just gonna expect that these apps have problems and it's more about, um, how they handle them afterwards. Uh, so I don't know what your thoughts are on that, but I, I've seen a lot of articles around that, But I, I also think that that is, that is a great way to go, um, prioritizing resilience over perfection. It's not that you are going to say nothing will happen, but we all know how expensive it is to get a, um, a system to even, you know, no one's gonna try and go to five nines.

It's just too expensive. It costs too much money, and often it doesn't make sense, but you figure out if something goes wrong, then what do we do? We fix that and hopefully we make it so that that problem, uh, doesn't reoccur.

So create systems that will detect, respond to and recover, uh, from those incidents effectively and hopefully, uh, in less than a week's time. Yes. Right.

Yeah. Well, but that's, so, so that's what, um, chaos engineering is all, I mean, chaos engineering is, it's been around quite, quite a while. Oh, that's, it's wonderful thing.

Um, and that would put you, I mean, to my sense that puts us in the 12 factor and, and app side, um, sort of approach. Um, I, granted there's a real continuum down into platform engineering now, because, you know, that's a whole software stack, it's own with development and life cycle and everything. Um, but, uh, um, are you really saying hope that, um, just get over it and Yes.

Respect it. I, I'm, I'm, and, and you know, it a little more nuanced, but I, you know, I like going all in that way. So, uh, invest in your observability tools, right?

Know what is happening, not just, you know, in the systems, but how does that roll up and impact your end users in the app, right? And then, um, failure is going to happen. Not that you're gonna make any, you know, you're not gonna be diligent in doing your work, but understand that unexpected things will occur.

How do you recover from it? Um, so yeah, I, I think, um, no sleepless nights if, if you have the right systems in place to, uh, to recover quickly. Okay.

So the platform engineer just said to me, oh, you worry too much. Stop worrying so much. Or maybe the platform engineering engineer just said to me, well, your app isn't very resilient.

Well, I, I think platform, I'm gonna sleep tonight. You, you worry about your app, I'm gonna sleep tonight. No, No.

But platform engineering, uh, if they are doing their job well, they are our partner, right? So if it is an organization that is setting up new apps, or is revisiting their processes and their practices around how they are developing these apps, that is a perfect time to get the platform engineering team engaged and to understand how, uh, end to end this can be more stable, more secure, more resilient. Um, if anyone on the platform engineering team says, you know, that's, you know, that's not our problem.

That person is probably gonna be looking for, for a new role pretty soon. Um, it, it absolutely is their responsibility as a partner to help the development teams understand what can be done. Yeah.

com site. And, uh, it's a survey by, uh, written by Mike Baard. And, um, it was a thousand platform engineers and IT decision makers across, um, across the world.

Mm-hmm. And, um, they're saying that the platform engineering success rates are higher. Um, they're, and they're seeing a lot more developer satisfaction, um, improved response times, increased customer satisfaction, increased deployment frequency.

Mm-hmm. Um, so, and this was a conducted by Red Hat. So, uh, we are seeing that as a, a, a potential solution moving forward.

If done. Red Hat's a pretty good source for this sort of thing. They, they, As a former red hater myself, I'll agree.

Okay, good. Alright. Um, uh, well, um, so I guess what I was driving at though, um, was that there are these two approaches to take mm-hmm.

Um, one just anticipates, um, the, the, you know, likelihood of issues mm-hmm. And you engineer both in the code and in the platform. Um, like you say, resiliency first.

That's a great way to think about it, but I, I do think that a lot of organizations can and should invest in reducing their frequency in, in mitigating the possibility of, uh, those same issues. Maybe what you're reacting to is an overemphasis on, on mitigation, an overemphasis on like, you know, a lot of these bold statements of secure, resilient platforms that you don't have to worry about. That turns out not to be the case.

But I, I, I think that, you know, uh, maybe I'm on the side of both, um, that Yeah, I think it actually, I think, I think it takes both. Um, but you know, again, um, there's A, there's a lot of shoring up of DevOps practices that could take place right now. I mean, let's be honest.

Right? Right. DevOps seems to have gotten a little sloppy.

It's, it, it, it, it reached the point. I think partially DevOps meant too many things, and a lot of those things weren't supposed to be called DevOps. Yeah, exactly.

So, so John, John Schwartz, who Amanda, uh, cited a little earlier, he is one of the great writers for Techstrong. Um, he, he has written about something called Authority Bias, which is outside of Dev, but the basic idea that, um, that culturally everybody trusts, you know, vendor X or tool X or whatever it is, it could be open source. Mm-hmm.

Um, 'cause of its track record or just 'cause it's a thing. Mm-hmm. And so the authority bias is to go with that and rely on it.

Nothing is sacred. Nothing should be sacred. No, nothing is Sure.

In certain, and that's the an example of the kinda sloppiness that, that we're talking about. Mm-hmm. You know, CrowdStrike, um, status sort of, you know, protected status within the Windows stack caused that huge adage.

Yes. And CrowdStrike's a great brand, great vendor with great products, just you have to remember, nothing's perfect. Mm-hmm.

For sure. And I'm not sure anything ever is gonna be perfect. I mean, we can have all the solutions in the world.

We still must anticipate that, um, perfection is almost impossible. So, And, and do you really want, you know, your team's gold plating and over engineering the systems for what might happen? Uh, No, but that's, this is the right conversation to have, right?

We want to invest in mitigation, we want to invest in resiliency before perfection. Yes. Okay.

So let's just, if I were to advise and you, y'all disagree with me or, or, or violently agree, or whatever you like mm-hmm. But if I were to advise, what I would say is just put that framework up when you're thinking about 2025, put that framework up and decide what your culture and your approach is, where you are gonna invest. Just don't do all of one.

All of the other are, you're gonna work more to mitigate, or you're gonna do 20% mitigate, 80% anticipate, you know? Mm-hmm. And true it up as reality hits you, you know, square in the face.

You know? That's a really good point. That's not it for the rest of the year.

Check in regularly whenever you, with whenever. Yeah. Let's talk, let's actually go back to a couple more, if it's okay with you guys.

Let's go back to a couple more, um, topics here. Mm-hmm. I wanna talk again, bring back AI like real quick.

Mm-hmm. Amanda, you talked about, um, uh, incorporation of AI code, AI generated code. We talked about that a little bit.

Um, there's also the incorporation of external AI services into an app. Um, these are all, uh, sources, new sources of fragility that are seeing intense investment. And I think another reason to think of 2025 is the year of the fragile app.

At some point, there's gonna be a backlash to, to the use of ai, and I think that would feed into this. Is there anything more, I've heard a fair amount about the, um, the, the strain put on the platform engineers or the platform managers by use of ai. Um, is that, is that going on?

I like resource constraints and, and management. I think it depends on the organization, right? If you have an organization that has not done their homework and just, you know, gets a basket of money and says, Hey, we, we, we need, you know, we need ai, everyone's talking about ai, we need to be able to tell the board something or shareholders something that we're doing something with ai.

Everyone is, is going to feel stressed, uh, because there's no real direction. It's just do something. Right.

But, uh, especially in the context of where we're going, uh, in this conversation, if they say, look, platform engineering, we want you to implement systems, um, that use ai, predictive maintenance, identify failures before they happen, intelligent monitoring, you know, what's a normal variation versus an actual problem, uh, dependency analysis, self-healing, um, you know, trend spotting, those types of things. They, even if there is more work, they will not be as stressed because if you have been in this situation, you can, you can, if you are working on something you enjoy, that you think is going to be good for you, even if you put in many, many hours, the way you feel at the end is very different than if you feel you're doing something that has no purpose or, or, or real, uh, real outcome. Right?

So I think if it's done with intention toward good outcomes, um, yeah, I think the platform engineering teams will be happy. The ones who are complaining are probably the ones who are being put upon, uh, with people with baskets of money that just want to do something with ai. I, I would like to, um, point out a article on, um, this is on business wire.

Mm-hmm. AI powered application development introduces new IT challenges. So again, um, we're going back to the IT teams too, and they're seeing high demand for these applications.

Um, uh, nearly three quarters of respondent say their organizations plan to build 10 or more apps over the next 12 months. Mm-hmm. Um, but you know, where this is a problem is it's a considerable workload.

So they're filling that workload, they're filling a persistent talent shortage. Mm-hmm. Um, high cost, uh, compared to traditional application development.

Mm-hmm. Um, and so, um, these are issues they're facing and complexities with integrating AI technologies, you know, uh, the trust, uh, there's some trust issues there. Um, and, and various things like that.

So that's a good article to check out too. But 10 apps, I would be the person in the room that, that leadership would, would be frowning at, because I would immediately protest. Right.

That's outrageous. I, I, you know, the justification would need to be really strong. And if it is 10, 10 over quite a bit of time, not 10 working at once.

Uh, yeah. So yeah, there's, there's some, It's crazy. It's crazy.

Like, like what they think they can do now with just because of ai, like they're just gonna increase the workloads so astronomically. Mm-hmm. I think it behooves us as a mitigation strategy, I suppose, to go ahead and say, maybe we should try less.

I know that's really hard. Culturally, that's super hard. Mm-hmm.

But, uh, hope we need more of you in the room to say maybe we should try five apps. Yes. And if we're doing great, then we can add a few And learn, learn.

Right. Because then you will actually get faster versus being bogged down and trying to do 10 things at once when everyone is still learning. Um, so yeah.

Well, let's wrap up. This has been a great session. I think I've learned a few things, and I hope, uh, it's been helpful, uh, to, uh, to, to those watching as well.

Um, uh, I, I'll just say, I think that, um, it, it's a trend to look out for and this framework of mitigating sources as well as just accepting that this is gonna happen and anticipating it, that's the right framework to use whatever balance works for your organization. Mm-hmm. Um, hope you wanna give some final thoughts and then we'll finish with Amanda.

Uh, if you're not already looking at platform engineering, look at platform engineering and make sure that they are a partner with the development teams. Uh, that's my statement, Amanda. And the one thing I always fall back on because it is at the root of everything, better communication, that's always key.

That'll tighten up DevOps. Yeah. All right.

Thanks so much. Hope, Amanda. This is Guy Courier signing off.

We'll see you at the next Predict for 2026. Thank you. Thanks.