Challenges of Application Modernization – Derek Ashmore, Asperitas

This is Textron TV. Hey guys. Thanks the throw we're here with Derek Ashmore who is a application transformation principle with the spirit is Consulting and we're going to be talking about the challenges of application modernization Derek.

Welcome the show. Oh, thanks. Thanks Michael.

It's great to be here on the face of it. It would seem simple enough. We're taking some applications.

We're gonna either give them a facelift. We're gonna move them up to the cloud. Maybe we'll refactor them along the way what makes all this so difficult.

It seems like everybody's having a hard time. That's a very good question. I would say that it's not that it's incredibly difficult.

I would I would I think of it is it's more than they expected. When they entered their Journey essentially when everybody got into the cloud they they went initially with a lift and shift strategy, which is the predominant strategy that I saw our customers use and after they got there they realized that they had a hard time doing or leveraging the clouds Dynamic scaling which helps them right size their applications and only pay for what they truly need. And it also didn't initially make them able to manage changes to their AppSec.

Any better or any faster and in a competitive environment getting additional features and additional capabilities into your user's hands is is key if in particularly for applications that are competitive to the business. So I think for a lot of organizations it may also have to do with the folks involved because frankly they're only going to do it a couple of times a handful of times and so it's not really a core skill set. That's not like, you know running the APM system that you're going to do 24 by seven.

So it's part of the issue is that a lot of these companies just don't have the internal skills on hand to move an application because it's not something they do every day. Well, I think there's something to that I also think that if done right. Application monitorization is as much about people process in the way you manage change to those AppSec as it is just a Hosting technical issue.

Right? And so it actually requires a paradigm shift not only for the the staff that physically do the coding and physically do the moving but there's a little bit of a paradigm shift for management as well. Right, essentially the big birth release style for application changes basically kind of gives way if you're going to do continuous delivery or continuous deployment.

And that requires that managers change their mindsets too and Paradigm shifts are harder. Than just going out and learning a new technology, right? So do you think application modernization once you're down the path, you're pretty much well on your way to devops best practices and maybe a AppSec down the road but you know are people prepared for that the understand that and or is that part of a as much a cultural changes?

It is a technical change. It is as much of a cultural change as it is a technical change and I think that a common problem I see is that people don't expect that when they start on the journey. they come to understand that when they're Midway through the Journey and they start making making those adjustments but I with 2020 hindsight.

I'm trying to get better at with customers who are at the front end of that Journey. I'm trying to get better at studying those expectations and basically making customers aware of the changes that are coming down the pipe sooner. So that they can and in an effort so that they can they can better prepare themselves and I say that but there's a difference between me delivering that message and then understanding each word in my sentences and actually internalizing how that's gonna impact how they think there's a little yeah, there's there's a difference there right?

So there's there comes a time when they realize that perhaps they're not in, Kansas anymore. Do they tend to Zone in on one cloud, or are they trying to figure out which workloads or optimize best for different clouds? I mean, what's the level of maturity and how quickly do they get down that path?

That's a very good question. Vendor lock-in is is a hot. Button for most execs and I see a lot of our customers are have Footprints in multiple clouds at least at least two and I like the fact that you tied that to maturity right because I think that what it takes to manage One Cloud.

Is a progressive enough change? I I could I look at it as an evolutionary process basically. I wouldn't I mean I I have one customer that wants to do active what's deploy an application and active in an active active mode and one one side and AWS and one side and and Azure and due to the different capabilities of clouds that actually it takes a lot of maturity to get right.

Right, you have to have expertise and and and and yet not only is there more Technologies to learn but the cloud vendors have different capabilities. So oftentimes you're kind of if you want to do active active and multi-cloud you basically need to go with least common denominator features that are available. in both clouds that that you're working with and I think In terms of priorities.

I usually don't recommend customers adopt multiple clouds early in the process because they've got enough to learn right with the Paradigm shifts that are coming anyway, and the people process issues that they deal with with their first Cloud if they They grow to be this tall. They can enter the next ride. Yes.

He's the way I praise it speaking of growing are they lifting and shifting and existing monolithic app into the cloud or are they trying to modernize it into a set of cloud native services or how long does it take for them to get down that path? Because yeah, it's almost to me like there's phase one and phase two. Well, there are multiple phases and most AppSec don't go.

Don't complete their modernization effort in a big birth kind of style the whole thing about change management for applications these days is we go for very frequent deploys, but very much smaller deployments much smaller changes. All right smaller chunks and often times applications when they move from on-premise to the cloud. They're not perfect.

In other words. They can't necessarily dynamically scale. They can't necessarily take advantage of the clouds availability features that comes in time.

Well, I normally recommend to customers is that to the extent possible. They either change they they do some combination of changing before you move move changing after you move basically the act of free hosting Should ideally not be coupled with a series of feature improvements for the application something along those lines just to keep just in keeping with the concept that smaller change is easier to manage and less risky. Do you think that initially people make this transition because they think they're going to be reducing costs and saving money or and then at the back end they kind of discover all this flexibility and capability that they never thought it organizations would have or and for that matter do they actually save money doing this or is it just a matter of gaining the flexibility?

um That's a good question part of that is accounting base and I'm not an account. I'll tell you that right now the capex versus Opex. kind of kind of paradigm shift goes into the equation because essentially now that you're not investing hardware and data centers and property and that kind of stuff that that you don't have to like purchase assets that depreciate you basically get to expense it when you use it that that that kind of switch has a financial implication for customers and and that gets into your point about whether they save money right do they save money they what I've seen is they they end up saving money but not quite as much as they expected and what they also end up coming to realize is that to save even more money they have to We retool their applications so that it can grow and Shrink with Demand, right?

It's a subtle point. But if you have a monolith that can't grow and Shrink with demand. What you have to do is you have to buy enough compute power and enough resources on the cloud side to handle your Peaks.

Which means that you're paying for idle a good percentage of time, right which doesn't really help them from from a financial perspective. So if they're gonna be able to adapt in that way, they've got it enhance their application to be able to capitalize on that. Another hot button for a lot of customers is availability.

They want their AppSec always up. right most of us do and if A monolith is into built to be able to handle the availability the features of the cloud in other words. They can't they can't gracefully one one occurrence of an application can't gracefully be shut down and another one graceful you be established without users knowing that there was a switch behind the scenes then they don't get the availability features either which incense them to change their applications so that they can take advantage and their customers end up anything from that now, I hope you can tell me if I'm rambling too much.

Yeah, you're doing fine. Essentially what you're saying is that once they get there they discover that the Wardrobe that they brought does not fit the climate they're in so they're basically Asian the entire That is correct. And that is correct.

I'm as we go down that path or do you think also that the job roles within the organization change to and there's this whole conversation about who Moved My Cheese because there may not be a classic storage admin or a network guy the way there used to be so, you know, do you need to think through the job roles and they were it organization? Um, that's a very good point. We went into that quite a bit.

Basically, I'll take I'll give you an example. One of our customers has for decades been, you know, their Network team manages DNS entries manually and there's a whole submit this form if you want this kind of change in DNS that worked fine for on-premises but in the cloud where everything so dynamic there's no way for that process to keep up. And so what ends up what ends up happening is America management has to do this paradigm shift and they eventually realize that hey the way we managed stuff and on-prem needs to adapt.

It doesn't scale in the ways that the cloud is basically requiring us to scale and and it goes further the DNS entries that we see a lot network engineering teams. I liken it to what happened to you know, database Administration services along the way right at some point in the past 10 or 12 years, basically. The pocket of people most organizations that do database Administration kinds of things basically have gotten a lot smaller in the application developers have taken on that work.

I'm seeing the same thing happening in the cloud application developers need to acquire Cloud skills that they don't necessarily have and they weren't necessarily prepared for but now they're in this new world and we've got to they've got to figure that out along the way they've got to do the Paradigm shifts for how they manage code and how they manage change because managing change in smaller increments means you divide the work of differently and you organize it differently and you manage it differently and that I think I I think the skill set increase or the skill set change that happens along the way. Wasn't expected. Well most corporations expect when they first get into the cloud.

What a corporations do they create a silo for it, right a new technology comes along. They create a silo for it. So when the cloud came along they create a silo for it and they quickly realized that this world is different that that Silo encompasses all these other disciplines.

Yeah that network engineering and security engineering used to do and suddenly, you know, as you said who Moved My Cheese here if if you're a system administrator and you're noticing that your Footprints are going to the cloud and increasingly they're not going on Virtual machines like they used to they're going into kubernetes or they're going into other Cloud specific work. Would deployment mechanisms and there just isn't enough as much to manage, right? And so yeah, they they look at that and they look at the increased Cloud footprint and the decreased on-premise footprint and some people get get scared of that change.

Hey, have you ever seen anybody either just give up or for that matter repatriated Cloud application after they got there because of some of these issues they run prepared for. Um, I have not seen anybody go to the cloud and then move back to on-premise. I have we do have customers that have contractual constraints or legal constraints that keep certain applications on premise, but that's a different discussion.

All right, cool. Well, I guess one way or another once you get to the Cloud the proverbial Bridge has been burned behind you. So there's no going back.

So you might as well go for it. Hey, Derek. Thanks for being on the show.

Thank you very much Michael. I appreciate the opportunity. All right back to you guys in the studio.