GitLab’s Lee Faus on Integrating FinOps with DevOps

This is Techron tv. Hey guys, thanks for Throw. We're here with Lee faus, who's global field CTO for GitLab, and we're talking about fit ops.

It's all the rage these days, but it's not clear everybody knows how to do it. Hey Lee, welcome to the show. Thank you so much, Mike.

Appreciate being here. What do you think is going on with finops? Because I remember back in the day we had capacity planning and there used to be finance teams and IT folks would walk around and figure out how much they were gonna spend almost out of the penny, and it was a fairly exact science, and then the cloud came along and did we just forget or, or we kind of relearning some skills that we lost sight of?

I think it's a combination of both. Um, one of the items that we see from our customers is there's two different buying models that you have for products and services. So when they're on the public cloud, they're learning how to adjust to things like commits and consumption based pricing for some things.

So if I've got a database and I've got a bunch of storage that needs to be to back that, that storage is something that they get charged on a month by month basis, where you then have other products that charge by user. So the procurement teams are trying to figure out how do I blend these two models to make sure that I'm meeting the financial targets that they have internally while still capturing things like return on investment and total cost of ownership. Do you think folks are being surprised as they do that?

Are they spending more money than they initially thought? I mean, I'm kind of liken it to my television set where I have all these different apps that I'm subscribing to now and I'm probably spending more money on television than ever. Yeah, I, I agree with that.

I, I run into that same situation with, uh, uh, two girls in the house and very surprised at the end of the month when you get the bill and you start to total things up. And, um, I think that is something that's running with, uh, our customers today is, um, they have targets that they want to meet for their budgets, for the applications that they're building and deploying. And those applications, when they become wildly successful, um, they're not targeting for what are the additional services that they need to, uh, generate budget for.

So items that I, a lot of customers are surprised on are things like egress costs and being able to move stuff between the data center and into the public cloud. These are things that you normally wouldn't have to budget for if you were just targeting your own data center. So there are some surprise costs that do pop up, but at the same time, um, as we look at what the overall lifecycle looks like of an application, they only target things like what does the production infrastructure look like?

And now that we have these ephemeral environments that we can spin up and tear down, and we're not tied to the old legacy hardware that we used to have in our data center, even with virtualization technologies, we never felt really comfortable just tearing things down, spinning up new environments. And as they're doing that, they have a lot more flexibility in how they do things in dev test, a lot more performance testing. They're able to run through their regression tests.

Uh, there's just so much more that they're able to do that they just weren't able to do before. And that's where some of these surprise costs are coming in. There's a lot of different models in the cloud.

Um, and you hear a lot about spot pricing, but I, I also talk to folks and a lot of 'em don't use that simply because it's a lot of work to figure out exactly what the optimization is for particular use case at a given time of day. Do we need another way of thinking about kind of capacity on demand versus an application that runs more consistently? I mean, is the model kind of broken?

Yeah. I remember back when, um, I first started building applications and running my, uh, engineering teams. You know, one of the things that we did is we had profiles for applications that we were building.

Are they memory intensive? Are they CPU intensive? Are they IO intensive?

Is there a blend or a mix? How do we go ahead and target the correct infrastructure for the correct applications? And now a lot of people look at things inside the public cloud as just general compute type resources.

So I think as the cloud is evolving, we're starting to see more and more customers treat it as a platform rather than just infrastructure services. So they're able to get an economy of scale in the cloud by leveraging services that they would normally have to build themselves. So they're sort of hiding what some of the infrastructure costs look like underneath because they're getting the value that actually sits on top of those resources internally.

Can I go after this holistically or am I gonna kind of two step it where I need to, uh, optimize the cloud spend by category? So it might be in your case, uh, DevOps platform, but then I've got storage and to your point earlier, there's a lot of different models. And then I gotta aggregate all that into some sort of more comprehensive analysis that lets me get to my total cost.

Is that kind of the, the, the flow and the skills required here or how does this play out? Yeah, it's um, interesting because one of the things that we're asked for from our customers are wanting to know things like when they're running CI jobs. So when they're running those, they wanna know how many minutes a project is consuming of those resources to try to do some sort of chargeback showback type model inside across, um, application owners.

So things that we see in the future is when we start to look at those things holistically, we've gotta move away from just talking about minutes and we need to start thinking about the value that these services provide. And that's where a lot of the customers, when we talk about value, it needs to be, unfortunately for them, there is some vendor tie in, but what are the specific services that you can consume that makes it easier for your users to monitor their applications, to be able to do auto scaling, to be able to uh, uh, do things like DNS and auto failover and being able to do hr, uh, HADR, um, inside their environments for their applications. And as they start to abstract those things away, they're now no longer needing to worry about, well, how do I provision a virtual machine?

Or how do I provision elastic storage? So those things are going to be interesting about how we value those services above the individual minutes that we're seeing a lot of people measuring today in their finops environments. Do you think that AI might come along and help us with all of this?

'cause it seems like there's a lot of data flowing around and I need to kind of maybe rationalize and summarize it. So that sounds like generative AI to me, and then I can apply some algorithms and some controls and is that where we're headed? I I do think that there are definitely opportunities for generative AI to step in and provide some forecasting models.

Um, so when I've worked with other customers inside of the public cloud, there's trends that they have. So there's spikes in workloads, let's say at the end of a quarter or if you're, um, selling things online, you see spikes in between the holidays. So how do we build that forecasting model to automatically build future compute like models that we can scale proactively rather than reactively and optimize that spend even further based on time of year, time of day.

Um, we have people that will be building applications and those applications, they may not have developers and other parts of the world, or they may just be America's based. Well, what do I do with the compute resources? Do I have to run them at their high watermark or at seven o'clock in the evening, can I run a minimum amount of workload and then coming in at 6:00 AM East coast time, do I spin those resources back up?

It really comes down to how far do you need to optimize before you start running into situations of, um, the complexity of being able to set up those environments. How many people really know how to do that? So those are things that I think, uh, generative AI can really help with is being able to find those trends and analysis and then automatically building the scale up, scale down type models for those applications.

I don't wanna accuse our developer friends of being quote unquote drunken sailors here, but um, it seems like a lot of times they create a development environment and they don't wanna take it down or they forget about it or they have a bunch of BMS running and they forget about that too because, you know, they think they're gonna use it again any day now and then it just sits there and some costs. And then on the back end it seems like, you know, everybody over provisions. 'cause nobody wants that call at two o'clock in the morning and we're not really optimizing the compute infrastructure because well, if it comes down to cost versus, you know, my wife being mad at me because I got roused out of bed at 3:00 AM I'm going with the compute cost.

So, um, how much of this is kind of our human nature that we need to kind of work around a little bit? I I do think that there's, uh, some human nature elements to this. Uh, there's a lot of people, even with how long the cloud's been around, there's a lot of people still somewhat hesitant to moving workloads into the public cloud.

Um, when a funny story, uh, a company that I was working for, um, it wasn't until they generated actual showback of the resources that were being consumed. Normally central it manages the budgets for all applications and the development teams are, their budgets are really just about the people on the project. So they'll go to external staffing, they'll go to internal hr, they'll grab their people that they need and they can sort of break it down into what the cost looks like for that application based on the time that resources are allocated to it.

They never take into account the actual infrastructure that requires that application to run all the way from issue all the way into production. So they don't think about things like, Hey, what does it look like for CI to be running 24 hours a day for GPUs that are building new models for generative ai? Those things usually come out of the central IT budget because the developers usually don't have to worry about it.

In this company, there was a group that they had a budget that was really low and they were like, yeah, you know what, these are our people. And um, then what they did is when they started getting showback, they were surprised by the infrastructure that was being generated by these 36 developers on this team for exactly the reason you just described. They were leaving environments up and running.

They, um, would spin up another environment. So they were trying to create an almost an environment per, uh, task or per ticket. And when they started learning how they could optimize and share resources, they were able to draw that budget way down just by being able to show them what the cost actually looked like.

This is something that's very difficult to do if you're running in your own data center because it's usually a, a CapEx type expenditure. So it's really hard if I'm running in a four U server that's been racked for five years, do I still measure it off of the five year cost from when we bought it or based off of the price of what that particular hardware would cost me today? This is something that's great about the public cloud is we usually have very recent infrastructure that we get to work off of.

And because we're being billed on a per hour basis, it's much easier for us to be able to generate that chargeback showback to those, uh, application teams so they know where the spends actually coming from. Mm-Hmm. Do you think we're gonna see as more organizations wrap their arms around the cost?

Um, more movement of workloads because some of the things that are running in the cloud, let's be honest, you know, it was covid times, it was the only place we could put them. So maybe we need to kind look at the total cost of running something in the cloud. Likewise, to your earlier point, some of the financial quote unquote engineering that goes on to justify on premises may not stand up to the light of day either as we apply finops not just to the cloud, but also to on premise.

So are we gonna see a lot of workload movement just because as people get a better handle on these cost issues? Yeah, that's a great question. Um, what I'm seeing with our customers is there has been a little bit of a slowdown for workload migrations.

A lot of that comes down to staffing. Um, the, there's been, uh, reductions in force inside these IT organizations. The people who had a majority of the knowledge about the applications themselves and how they ran.

They're a little hesitant to move them to a new environment because it may or may not be running okay today, but they would rather fix it in place rather than building a migration path. But then other companies that we're seeing when they break that application apart into the platform components and really leverage the cloud that it was in the way it was intended to not as individual infrastructure services, they're able to create building blocks. And so they have reusable templates that they can create and they're using GitLab to drive that automation for those workload migrations.

So they can see, oh, if I need a MongoDB database, here's what that Mongo D database, MongoDB database looks like inside of AWS for us as an example. They can reuse that template over and over again and get the economy at scale for the movement of that application in the public cloud. And then they get a lot of the other, uh, flexible benefits that we were just describing.

They can now see what that particular resource costs them on a per hour basis. So what have you seen people doing well to get down this path? 'cause I feel like a lot of folks look at this stuff and it's immediately overwhelming, right?

Because to our earlier point, there's all these things that are priced somewhat differently and now no apples and orange and all this other stuff. So how do I get started? Where do I begin?

Because, you know, ultimately I, you know, the first time you look at this you just shake your head and go, never gonna get there. Yeah. So, um, I have a number of conversations with CIOs and CTOs, um, CTOs think about this problem a little bit differently.

They're really interested in the architecture side of it and a lot of the CIOs are interested in the financial side of it. Um, the first thing that we see a lot of our customers wanting to do is not only measure what it costs for a production runtime sitting in the public cloud, but holistically, what does it cost to be able to take an individual feature or bug from development all the way through to production? What does that cost look like?

So we're seeing teams being spun up out of the finops concept that are driving this thing called value stream management. So how do I organize my people and how do I organize my projects in such a way that I can maximize the value of change to a particular customer or for a particular event that allows us to then aggregate all of the different steps that it takes for that reorganization and for that change to occur for us to be able to funnel that up into our Excel spreadsheets and to other things by measuring all the different parts as well as the runtime environments, aggregating that cost and being able to show that to A CFO or to A CTO so they can figure out where they need to do optimization. We do this inside of GitLab ourselves.

So we have somebody who is, uh, director of finance and um, about once a month what they will do is sit our CEO, our director of finance and our CTO, they get together and they look at, there's a concept in GitLab called a merge request. And what they'll do is looking at that merge request. Anything that is open for more than three days, we have to justify the expenditure of why that has not been merged and released into production.

So we wanna keep that pipeline of change moving quickly because the faster we can get those things into production, we're able to do things on the backend. Like we can reduce support burden because we may have a number of customers who are running into an issue. This is the part where finops has an opportunity to expand into is usually when I'm talking to customers, they're only interested in that optimization on the cloud side, but when we start to say, Hey, by the way, I now can allocate a support person to be able to work on different tickets 'cause they're not answering the same question 30 times in a day because we have a consistent bug inside of the system that allows 'em to be able to get new features, new capabilities out, rather than trying to walk them through a workaround or something else.

So we're able to optimize that process all the way into the support side. So that's where having that total cost of ownership of what change means is where I see this, uh, finops concept going down the road. You mentioned value stream management and we've been banging on that drum for some time in the land of DevOps.

Um, do you think finops will pull value stream management or at least create more awareness of that as a motion for managing or assessing the value proposition of software initiatives? I definitely believe it's pulling it forward. Um, so the value stream consortium is seeing this as, uh, sort of top of the funnel for being able to drive awareness of the importance of measuring change and change is both measured in good and bad.

So, um, when you're able to evaluate those trends across the organization, you'll be able to measure, okay, well where are certain teams excelling and how do I get other teams to act like them? What are they doing right? And how do I retrain other teams to be like them?

How do I go ahead and build patterns, uh, for reuse? Um, I'm, I used to be an enterprise architect and that's near and dear to my heart is how much of this can we templatize create blueprints out of build components that are reusable so that way we're not recreating a wheel every time we go into a new project. And as we're able to do that, that ends up being realized in value stream management.

And then I'll, um, at the end of that, when we start looking at finops, that funnels up to the CFO and they can see the cost of building new applications goes down while customer acquisition costs are going down, while revenues are increasing. And I have yet to meet A CFO that doesn't wanna meet their board of directors and show them those charts and not be jumping up and down and saying, look at how awesome I am at being able to optimize for this. So do you think ultimately that finops should be just kinda another metric we're tracking alongside all the Dora metrics and it's just in our console and we should be able to see in real time what things actually cost?

Or is this gonna be like, you know, a separate platform somewhere with a separate console that, you know, a finance team is using and then sending off nasty messages to the IT team? Uh, so I definitely think this is gonna be embedded in your, you know, DevSecOps platform. You know, the near term things that we're already showing to customers is for, uh, how many CI minutes are being consumed by project so we can show them the minutes, but because we don't necessarily know what sort of infrastructure lies underneath that, it's hard for us to be able to put a cost to it.

But they can easily do that mapping by being able to know where their, what we call runner fleets, which is where CI jobs execute for GitLab. They can do that mapping by being able to pull reports from AWS or GCP or Azure and then mapping that to the minutes for that project. So that's a short term win.

But I do believe over the long term is we're gonna be able to know more about how these applications are being deployed and managed and you know, um, what happens when I've got a bug in production, we've all heard the numbers. Oh, finding a bug in production is x cost. Finding it in depth test is another cost.

Finding it in the developer's ID is another cost and it's usually a 10 x type of increase every time you go across. Well, let's actually show that. Let's, let's have that visible to a development team that when they find a bug in production, why is it important that that's getting fixed as soon as possible?

Because we've gotta draw that cost down because it's driving costs and support. It could be driving a loss of customers having that kind of visibility we just don't have today. And the only place you're gonna get that is in a holistic platform like GitLab.

Alright folks, I know it feels like the cloud infrastructure is free, but trust me, there's a bill that shows up every month and somebody starts screaming about it somewhere. So we need to get better at all this stuff. Hey Lee, thanks for being on the show.

Thank you so much for having me All.