IT Costs in the Cloud Computing Era – Ben DeBow, Fortified

This is Techstrong tv. Hey guys, thanks for the thrill. We're here with Ben Debo, who's c e o for fortified data.

And we're talking about it costs, especially in the age of the cloud, seem to have gotten away from us. Things have spun a little bit outta control and what we're gonna do about all this stuff, Ben, welcome to show. Welcome.

Thank you Michael. How did we get to where we are today? Cuz so many organizations are struggling with the cost of it, and I seem to remember a time when we had a little more discipline and of course everything was in an on-premises environment back then, but what's changed and how did we get here?

Well it's, it's interesting because when, when I started technology around 30 years ago, uh, you actually had to worry about what amount of resources you actually coded to be able to even run your processes. Uh, you either had to schedule 'em or load memory, high load memory low and so forth. And it was very challenging and people actually had to pay attention to how many resources their code or processes or applications actually consumed 30 years later, which cha uh, been interesting is that the, the, the mindset has changed because anytime people have issues they just add more.

And whenever I have abundance in technology, um, and I don't have to go back and say, well, let's rewrite this process, it's created this mindset that the only thing I need to do is meet the functional requirement and I could, my code can use whatever resources, which then every server, every application end up having to use more and more. And that's been okay up until around, you know, seven or eight years ago when the cloud was coming online. But now the model has shifted to utility compute where actually have to pay for usages like your electric bill Michael, and, and that's now impacting companies, which is as having the CFOs now ask better questions.

Did we get a little sloppy writing the code over the years because we thought we had infinite resources, so we didn't really get focused on code optimization? I, I think so, and I actually think there's two, two components. One is the code and the process, but ultimately it goes back down to the data because within technology we actually don't need any technology if we weren't storing any data.

So every piece of technology we have is to be able to, to store, analyze, present, and understand data. So I think there's two components. Is it all started with everybody started storing data and then no one ever wants to throw it away.

There's that H G T V show that's called Data Hoarders. I like to joke that every organization is the data hoarder because everybody wants to retain everything just in case. Now you add code onto that, that was maybe not written as efficient as possible and now you have this increasing rate of data growth along with potentially inefficient code and it's creating a very interesting challenge.

Now I also think there's an element of, shall we say, developers have been given the freedom to provision infrastructure and you didn't really have that in an on-premise environment. And I think they have a tendency to overprovision because they're like, I don't wanna be woken up at two o'clock in the morning if something goes wrong. So I will just overprovision the crap out of this thing and all will be good.

Um, you know, are CIOs kind of coming around on that other side of that? We hear a lot about finops these days and is that part of that conversation? Yeah, it's, it's interesting, um, and I'm gonna talk from the developer's mindset first.

Uh, one of the challenges I see because I've been in technology working with both infrastructure app dev data and the business, one of the challenges is none of them speak the same language. Infrastructure speaks vcps memory and storage application developers speak code and process data speaks data, right? Uh, do the business speaks dollars.

The challenge is when when the application, even the old days used to go to provision and say, Hey Michael, I need a a place to run my application. First question, the infrastructure team goes, well how many resources do you need? They have no idea.

So the infrastructure offers three options. Developer picks the biggest size you offer because we don't want to increase the risk, um, of it going down. And that started the, the challenge.

But now we move into the cloud, we make it easily for anybody to consume and spin up resources. Well, the developers don't see the bill, right? Unless they're constrained and, and have certain policies in place.

So therefore the developers will spin up, they develop their, their solutions it runs. But I've also had clients that will get a hundred thousand dollars bill because the developer spun up something but they didn't understand the cost implication to their design pattern or design approach. And that's where it's coming into a, a challenge because the C F O does not get that bill until about 30 or 45 days later after that developer made the decision after it's in production.

And now to get something out of production, it's a process because the business is already focused on the next feature. And then that's where it just, it it's sort of that compounding issue that, um, you know, keeps reoccurring within organizations How much your CFOs really focused on reducing cost as much as they just want it to be predictable and they don't want that surprise bill at the end of the month and they want people to behave with a little adult supervision, but they're not really trying to clamp down on innovation per se. Correct.

Yeah, and I think that's a very good point is it's that fine line of enabling people putting boundaries and gates on 'em and then setting the goal and objective, right? So when you think about how do we accomplish that, so how do we create a, a a system and a culture of efficiency accountability and also understanding there is a cost to what we do, but we still wanna move fast cuz everybody's already about agile and really increasing the velocity of development and new ideas bringing on to the marketplace. And I, I think the, the model is going to go and even just finops is gonna go through a pretty radical evolution over the next, you know, one to three years because it has to, cuz to today there's only really three options within finops to control your costs.

And that's focused on the impact that I call it code has to processes. But I think developers will end up working more closely with, um, the business and infrastructure to start to understand their costs, start to set some boundaries on and or else's budgets around what that application has the, the right to spend to meet this s l a or this goal or objective. And then they're gonna be a, a, a party in that conversation more upstream versus after they've received the bill, which is where it sort of is happening today.

Do you think maybe someday AI will save us from ourselves? Is there a role for these algorithms to come and kind of get themselves in the middle of this? What it really is a human problem?

Yeah, actually I, I, I wrote a blog post on this because when you think about just the number of lines of code out there today, let alone us as humans, I'm gonna write a process based upon my knowledge, skill set and skill level and I'm gonna push it out to a development environment. Think about co-pilot, think about some of the other technologies out there and just in general, ai, those models can develop code very, very quickly and very well today. Uh, so it'll be very interesting to see based upon what inputs we give that code for success and the requirements and or else gates on how AI can help us solve this problem.

Both not only in writing new code, but one of the questions I pose out there is what about all the existing applications? If we were to able to determine the efficiency of the code, identify the, the top inefficient processes that drive the biggest bill and based upon our, our world, which is data, the top 1% percent of processes consume about 50% of the cost. That's a big ratio.

So that's where I think AI can help us not only design new, I think in the future with some evolutions, it could also help us fix the legacy code as well. Legacy applications. You would think with the current economic headwinds that this would be a high priority for folks.

But a couple of surveys I've seen recently suggest that it's gonna take people two to three years, they wrap their arms around finops and kind of get their processes in place. So what uh, what's the obstacle? A lot of it's lack of awareness.

I I think when people get, you know, their, their cloud bill even even for on premise. So we we're reviewing some very large systems today, whether it's, you know, credit card processing, hospitality, insurance, et cetera. And when we present these reports and give them the view of that one statement I just made a second ago, 1% equals 50% potential cost savings.

They have no idea they, cuz there's no dollar amount on what we call tech debt or potential cost takeouts, right? All this knowledge of tech debt is in people's heads and a lot of the attrition these days is walking out the door door. So until we actually start to bring better visibility into the cost of our decisions to build this process this way or design this, meaning finops starts that to bring down that level of transparency cuz right, today it's just at the server level, it's at the container level.

You never see it as far as an application or process level till it goes down. People won't know what the process is to fix, right? Therefore we really don't know what problem we're solving and what our potential benefit is.

And that, that to us is a big challenge. And I just wrote a book called End of Abundance and Tech because of this exact reason. And I think it's such a timely, uh, talking point because there is a lack of awareness.

But how do we better educate both the technology leaders, the people that are actually responsible for running and designing and building the next generation applications and all the people in the trenches that are actually coding, you know, fingers on the keyboard to design the next piece of code design, the next data model. That one decision or not a data type's, two bytes or four bytes. There's a cost to that cuz most apps live for about 15 or 20 years.

Are we too focused on the stick side of this equation and not enough on the carrots? And maybe we need to just go to the developers and reward them for doing the right thing and kind of encouraging the right behavior versus always coming down with and, you know, mandates to start with their words. Thou shal.

So one industry that I think has done a great job is gaming. So your point is very important because if, if I go and highlight the, the, the challenges, the, the, the things that can always be better cuz like, like in home inspector how my home inspectors, I inspect a home and come away and go, I didn't find anything. Your house is great Michael.

Right? And it goes back down to whenever we assess environments we always come away as something, but how do we twist this around and know that we're gonna find something, but where should we spend our time today that's gonna save us the biggest amount of money tomorrow? And then how do we incentivize both the business and the technology teams to align to that?

Because the business is focused on new features, product roadmap, technology does want to fix a lot of these issues. They do know a lot of where the bodies are buried, but when they go to prioritize the business and technology utilize competing goals, service new features for the customers, technology knows their tech debt and they're trying to do both new and old. But until those align.

And then once those align, how do we show that a developer just saved the company future meaning one to three years out by tuning this process that used to consume x assign a cost to that and forecast that out three years and say this developer just saved your organization $20,000 until we could get to that point. It's gonna be very hard to incentivize cuz we've been so focused on the future as far as building new and not really teaching the developers and allowing the developers to show their wins, their gains, their successes in helping the business become more efficient. Well I have bought enough houses in my lifetime to often wonder what the hell that inspector was thinking cuz how could they not capture any of this stuff?

But, um, to your point about technical debt, do we not think long and hard enough about that? Cuz we are running a lot of applications that are 20 years old. Yes.

And if we modernize them or got rid of them, our total cost would drop. But somehow or other I think we think that some a sunk cost that doesn't continue to impact the business. We just don't really understand the cost of it, is what it sounds like.

Yeah, it it, it it's a true statement. So if you go buy a car, I go buy a car, what do we usually do? com we, we find the car we want and we talk about and we can see that the finance costs, gas costs, et cetera in technology, how do we understand the true, true total cost of ownership?

Not just the price tag to buy the hardware to buy, you know, to support it day one because usually that's not realistic because it runs out in, you know, a lot sooner than what the vendor said. How do we bring a lot more visibility to the two, uh, total cost of ownership around technology? And I think that's something that is also gonna become, uh, more important later on as we start to bring down better financial instrumentation and applying that against the code, the data, the different technology services and the cloud's helping us some because they do give you a bill that does have monthly costs, uh, allocated to resources.

But the cloud providers are also making it a little bit more challenging. And the reason is they create things like DTUs and all these other abstract concepts. Why?

Because they in one way want you to have visibility. And another way they don't want you to have visibility. They don't want you to have visibility because if you truly go and tune those 1% of processes, their bill and spends gonna go down.

So I think that's where over time, um, some of those factors are gonna change and then that's gonna help us really understand where do we invest and what does this cost to support, uh, this application over one to three years. So ultimately, what's your best advice to folks about where to get started with this thing? Cuz I think a lot of folks kinda, they have an inkling about it, but they don't know where to start and the whole thing's a little overwhelming.

Yeah, one of the things, uh, I always love to do and, and we, a lot of people use this word assessment, but when you look at your environment and uh, really wanna understand what do I have, where does, where is everything and how healthy is it and how efficient it is, start by looking and capturing a lot of data around just inventory. What do you have? And then start to go into, and I'm gonna pick on the database world, you know, go and look at all the different database platforms you have, pull out those license agreements, then extract some key data from those servers around, you know, what's on them from a database container perspective and some of the processes.

And then you could start to understand a little bit around, uh, because once you start to, to bring clarity to that and bring a couple other people into that, it's interesting how many things are and can be de decom or decommissioned within an organization, but because no one does an assessment or a review, looking back on what they've invested in, a lot of this stuff just keeps on running. And people, one of the first comments that I hear very frequently is, I didn't know that's still running. Who, who you know and you like why even though they have all these monitoring tools and all this other great data on it, it's looking at your organization top down.

And another great example is this. On the data side, when you look at an organization top down usually have multiple copies of the same container for all the different environments. What, but what happens with many organizations, you know, because of policies and security, they will copy that data and before, you know, you have 20 copies equaling a hundred terabytes of premium storage in the cloud and that's today's cost.

Then they, if you were to forecast that out. But if you start to look top down and then you start to look at and find some of the stuff, then ask your question of how do my policies, how do my procedures impact the in, uh, the output of what we're finding? And then that's where you start to not only adjust and decom some of that stuff, but you start to change those policies so that you have one copy of the data, everybody has access through the right processes and security models, but you just lowered your cost because you changed your policy and how you access and provision and allow people to, to view that.

All right folks, well, you heard it here, nothing in it is free. At some point it's gonna cost you something and you might wanna start working your assumptions back from there. Hey Ben, thanks for being on the show.

Yeah, thank you Michael. All right, back to you guys in the studio.