This blog includes a transcript of a talk given at autocon/23. Watch the full video below:

In a recent survey conducted by McKinsey with IT directors and IT organizations, one of the key takeaways was that FinOps is one of the most important and emerging practices that they have been adopting throughout their IT and technology organizations in the last couple of years.

So FinOps has moved away from the fringes of adoption in quite a few organizations and have become mainstream in the last few months and years. My name is Nikhil Gopinath. I'm a VP of engineering here at Sedai, and what I'm going to talk about is the future of cloud cost management and how autonomous FinOps has a major role to play in this.

I'm going to talk about the different stages of operational maturity when it comes to FinOps at different organizations, some of the challenges that they face when they move through these levels of maturity, and we'll quickly see how autonomous FinOps can help in this journey and overcome many of these challenges.

FinOps Capabilities

This is a slide -- if you have been ever familiar with FinOps or did any research on FinOps, you would have seen it multiple times. This is by the FinOps Foundation, and what this is actually essentially summarizing is what FinOps means to a lot of people.

On one side, you have the core principles, the tenants that drive FinOps. And these are very common sense principles, like you need to work in a team, you should have reports that should be accessible, there should be a centralized team enabling FinOps. So there's a very common sense set of principles that drive FinOps adoption in organizations.

Then you have a set of personas who are responsible for FinOps in different organizations. This is very interesting because, unlike a lot of other practices a framework that people follow at the organization, this is very cross-cutting. You need participation from different organizations, from the executives, you need from the engineering team, from accounting, from procurement. So this is a very cross-cutting practice that needs to be established throughout the organization.

Then there is a bunch of domains and capabilities that FinOps enables, like tracking performance, cloud optimization, aligning the organization, and things like that. So those are some of the domain capabilities. And then there's the phases that organization goes through in terms of the optimization and the adoption that they do.

Now, what I want you to focus is on the top right corner where they talk about the maturity cycle. So this is how the FinOps foundation measures maturity in a typical crawl, walk, run fashion where organizations take baby steps and eventually are in a state where they are running with the operations of unions.

So now, what we are going to do here as a part of the rest of this presentation is talk about the different aspects of those adoption and then talk about the levels of maturity that organization goes through. And then let's see some of the challenges that they face.

So just to repeat myself from what I mentioned earlier, people are very core to the successful adoption of FinOps in organizations. And there are numerous departments that should play very synchronously with each other for a proper adoption.

Now, when you have different people and different teams and different parts of the organization working with each other, disagreement is rife.

Everyone has a different view on what FinOps means.

To the accounting team, it's just numbers.

For business, it's all about achieving the business goals. For IT or for engineering, it is about performance and a bunch of other things.

So how do you have a discrete set of people with different opinions, different points of view work together? That's one of the challenges people go through when they go from crawl, walk, and run and spread out the FinOps umbrella throughout the organization.

Next one up is budgeting and reporting. You can't change something that you cannot measure. You cannot manage something that you cannot measure. So reporting provides that essential thing for a lot of FinOps organizations to understand what they need to effect change and how to get it effective.

A lot of times, though, what ends up happening is this reporting takes a life of its own and becomes the end by itself, but what is lost in translation, what is lost in adoption is the fact that reporting is not your end goal. Reporting is just a tool to get to your end goal.

So you have a plethora of reports and dashboards that's flying around and there's effort to manage them and make them actionable, but then that loses the message. Why do you need these reports in the first place?

And what are the metrics that you are collecting here? What are the actionable items information that you're getting out of this?

This is yet another challenge that organizations face as they mature.

Next step is recommendations. So you have the plan. You have the teams. Everyone working together, and now you want to effect change. And to get those change, you need to know what are the changes you need to make. And this is where these recommendations come into play.

Now, when you are getting started, there are very obvious changes that you could make to improve your efficiency, improve your performance or decrease your cost, but as you mature, those opportunities becomes harder to find. And those opportunities - so previously when you had one single change that could save 10% of your cloud spend, eventually you get to thousands of changes that might give you a 0.1% improvement in cost.

So this becomes complex, and the numbers of recommendations increase as you mature over time. And the complexity of some of those solutions that's required to execute this or implement these recommendations also increases over time.

Metrics and KPIs. Now, this is again another aspect where people have a lot of disagreement on.

A KPI to a business person would be, how much am I spending to get my unit revenue? What is my unit cost for revenue? What is my unit cost by customer, by accounts? These are metrics that's very relevant to business.

Accounting looks at it from a very different perspective. They look at the numbers and the overall spend.

For an IT engineer or for an SRE, their focus is more on performance and a bunch of other technical metrics that they need to focus. Now, how do you rationalize and bring all these numbers together and manage and track them together in one single unified view? That again becomes a challenge as you mature.

Executing FinOps Recommendations

And finally, the most important part, in my opinion, is what do you do with all these things? Unless you effect a change, you are not getting the value out of the FinOps implementation. You can have recommendations all day, you can have reports all day, but you need to make changes. You need to have actions. You need to have executions on those recommendations to realize the value of FinOps.

Again, this becomes very hard as you mature because now the recommendations are more in-depth, are not the low-hanging ones, and then you also have the problem of death by 1,000 cuts, death 1,000 paper cuts, right? Because you have hundreds or thousands of recommendations that you want to implement and execute, but each one of them is very elaborate in its execution. So what do you do with those kind of things?

- So these are, again, just to summarize some of the practical challenges organizations face as they mature in their FinOps journey. The teams are generating the recommendations. They are very remote from the teams that that's actually raising them. The teams who need to work on recommendations or execute them, they have other priorities. FinOps might not be their priority.

So you send a ticket to a support team, and it goes in a queue and gets its time to get executed.

And this is an ongoing thing. You can't just say, oh, I did FinOps, and then stop. You get these recommendations, and they keep on coming every year, every time you make a new deployment to your applications. So you can't just stop. It's an ongoing journey. So these are some of the practical challenges you face.

The Need for Automation in FinOps

And just to elaborate a little bit further on that, this is, again, from the FinOps foundation where they said in 2021, it's only around 29% of the advanced implementers of FinOps who had some kind of automation in place. So you can see automation is--

the amount of automation that's required for successful implementation of FinOps goes up over time as you mature.

What's also more important out of this, in my mind, is the last number here, where 12% of the automation, of those who actually implemented automation, actually goes into doing something. The rest of them is housekeeping and maintenance. So what is emerging out of this is the fact that autonomous hasn't made it's--

is just starting to make the impact in FinOps. You need autonomous to be effective with FinOps, and people are just starting to get there.

The Impact of Autonomous FinOps

So autonomous to the rescue so this is the anchor point for what I'm going to present for the rest of this.

So how can autonomous or augmented FinOps help you with this transition? How can it help you mature? Now, one of the first things that's not shown here is, when you start your journey, you want to make sure you know the goals of FinOps. Why are you doing this?

Building Autonomous FinOps Capabilities

If you boil down the essentials and get down to the root cause of why you want to do this and what you want to achieve out of FinOps, end of the day, it's efficiency. You want to be efficient in your operations, which means getting the best performance and having the cost at the least possible point as possible. That is the end goal of optimization. That's the end goal of FinOps.

So with that in mind, and when you start with that as the goal, things open up for you. There are things that you can do without inputs. For example, when it comes to people, we saw that the people come up from different teams, from different verticals. They have all different point of views on FinOps. What you need is an easy way for those points to be expressed.

So if you have the same dashboard being seen by a person from procurement and in SRE, you lost that battle because they are both going to confuse each other out of that. What you need is the system to understand the different personas and help them achieve their own independent goals, realizing the fact that all these goals together eventually merge towards the organizational goals.

Reports, like I mentioned earlier, reports are just a means to an end. So you want reports that are actionable, reports that provide some value to you, and a tailor made for your specific needs.

When you generate reports, they have to be living documents of sorts. You can't just have a report and show numbers, and then they become stale.

It's not even the staleness that's important. It's the fact that the data in your reports are impacted by what you do with those reports. How do you feed back that data back into the reports? So these reports that are generated needs to be organic, and they have to be alive in a way so that you can actually get meaningful value out of those reporting.

And the other aspect of reporting is, how do you get the visibility? How do you get visibility to the right granularity?

And executive versus an SRE will have very different views or different--

they look at the same infrastructure at very different levels of abstraction. So how can you surface that as a part of your reporting tools?

And same goes with budgeting. And we'll see a little bit about budgeting towards the end after this.

Recommendations, when you get recommendations out of your system, you have to make sure that those recommendations are all mutually compatible. Oftentimes, what we see is a lot of tools generate a lot of recommendations and show you a potential for a lot of values, but they are very contradictory in nature. They are not complementary.

So you an autonomous system should make sure that these are all recommendations that holistically can be executed and provide you the value. And then you also have to factor different conflicting interests. Financial engineering and an SRE, who is going to optimize their cluster and their infrastructure, will look at things very differently.

Now, a recommendation system for FinOps should take care of that.

And what if you have recommendations that are low value?

If the FinOps tools that you have today tends to show you recommendations that might save you $10, you generally tend to ignore that. What you're also ignoring the fact is that there might be recommendations that can save you a few cents, but there could be a million of those.

Now, those add up, but your recommendation systems are afraid of giving those because you don't think that there is any value for those. That is, again, one of the challenges that autonomous FinOps will solve for you, and metrics and KPIs. And metrics and KPIs, again, these are not tracked independently of each other.

This has to be part of the overall picture in terms of not just monitoring the metrics and the KPIs continuously but also realizing what is the impact of the recommendations and the executions? And how do they circle back and complete the loop when it comes to overall execution?

And finally, again, executions, the key here is the ability to autonomously execute recommendations. If you have a system that generates, again, I was I saying, a recommendation that can save you a few cents and if you spend a few dollars to execute it, it doesn't make logical sense to do that. But an autonomous system is where you can get that value. So you can work on the long tail of optimization opportunities and recommendations and get the most value out of this.

So here today, as we build our autonomous FinOps capabilities, we come in a little bit more opinionated than most tools.

We believe that autonomous has to be the goal of FinOps. With that in mind, some of the things that we are building is Cost Explorer, for instance. Opinionated in the sense that we show you the data that we think you need.

Of course, you can dive deeper, and you can slice and dice it however you want it, but then decisions are being presented to you in a manner that would make more sense and more actionable sense to you.

The recommendations that comes out of Sedai. Now, in other talks, you already saw the optimization recommendations, how we can optimize lambdas or Kubernetes clusters or VMs. Now, those are all at an operational level from a technical level.

We also give these recommendations from a financial engineering point of view. And these are not independent. These are all done in conjunction with each other. If you have RIs, we factor that into the recommendations and also into the optimizations.

If we know that there are optimizations that's going to be done next week to scale down your cluster, that needs to be factored into your savings plan as we give those recommendations. So that's how we complete the loop with all kinds of recommendations, be it financial or be technical in nature, and bring them all together into one single executable set of recommendations.

Budgets again. Budgets are not just pretty graphs to look at. These are things that are actionable in nature.

You set up a budget. These are suggestions to the system that this is one of your goals. You want budgets to stay within this. And now said, I can take this as a hint to understand what are the recommendations that should come out Sedai? How can you get the best value out of this?

So in general, again, these are some of the things that we are getting started as we build autonomous FinOps capabilities. There's a lot more to come.

And just to give you a sneak peek preview of some of the things that we're building, the interaction with all these FinOps systems has to be more natural too.

If you look at the current state of arts with FinOps tools, very heavy on reporting and interaction. So what is a natural way to do that? I'll just leave with three letters, acronym, LLMs.

And with that, I'll just end my talk here Thank you.

‍