Deepak Ramchandani Vensi

Hi, I'm Deepak Vensi. I'm the Director of Strategy and Transformation for Contino, and today I'm here to talk to you about all things FinOps and why a practice like this could be just the thing that you need in order to help salvage your cloud and digital transformation program.

If you'd like to get in touch with me, on-screen you can see my LinkedIn handle, and I'd be more than happy to continue the conversation there as well as in the Slack channels for DevOps Enterprise Summit.

For those of you who might not be aware, Contino is the leading digital transformation consultancy that helps some of the world's largest, most regulated enterprises to become fast, agile, nimble, and competitive. On screen, you can see the customers that we've worked with and the kind of methodologies and skill sets that we apply in order to help our customers achieve their digital transformation goals.

Part of the reason why I'm here to talk to you today is because the one thing that we love is making sure people out there in the industry, in the community, do not repeat the same mistakes that we've been able to help other organizations overcome in the past. So do stick along, and I'm sure you'll be able to learn a thing or two today.

Why are we here to talk about FinOps today? And actually, what is the criticality for a program like this within your digital transformation journey? One of the things that we've heard time and time again over the last couple of years is that organizations are starting to see, as their cloud adoption has scaled, that their cloud costs happen to be much, much higher than they initially anticipated. They aren't actually seeing some of the cost benefits and the business benefits from the digital strategy that they initially set out to achieve. And it turns out, from a finance perspective, a lot of their actuals are far exceeding the initial budgets and forecasts that they had in place. With cloud consumption not stopping at all, this is a big challenge that organizations really need to uncover.

In today's talk, we'll cover a practice called FinOps that has helped solve some of these challenges out there within the industry. We'll introduce the concept of what we call a financial trace, and why that could be fairly critical in you being able to marry your costs with the actual business benefits. We'll talk you through how you can actually get started, what good looks like, and last but not least, we'll talk you through a community that you can look to join, where you can exchange a lot of these ideas with fellow practitioners out there in the industry who perhaps might have overcome some of the challenges that you're currently looking to go through.

What is FinOps, and how did this entire concept, this entire approach, come about in the first instance? If we look at public cloud and the spend behind public cloud and digital transformation, and the news that you see out there on what organizations are looking to embark upon, we all know that public cloud spend is predicted to far surpass more than $330 billion by 2022. That's less than a year away.

If we look at the approaches that have been employed to date when it comes to cloud consumption, cloud adoption, and digital transformation programs, a lot of these programs are very much engineering-led. CIOs and CTOs backed fellow engineers in the organization. They asked the finance teams to just work with them, but a lot of the approaches were being led by the engineering functions, by the product functions, and the finance teams were maybe there from an approval point of view.

This was okay whilst cloud costs were relatively low. CapEx was still the king when it comes to IT spend, and a lot of organizations still managed to go about just fine when it comes to separating project and build spend on one hand and run-based cost allocation on the other. They were okay by doing monthly or quarterly reviews of their spend. By and large, none of the finance teams actually got involved in looking at, for example, a billing console of their cloud programs.

In reality, this isn't something that can actually scale. If we look at the cloud costs that are currently being predicted within the industry, frankly, the finance function and the role of finance has to fundamentally change. If we go back to some of the challenges that we articulated, if we need to overcome those, finance has to figure out what their new role looks like. Finance has to be part of the actual architecture.

Cloud costs are currently on track to overshadow on-prem costs, and if you were to look at the current growth rate for AWS, Azure, and GCP as the top three, they're fast starting to outstrip and exceed that of your on-premise providers. So it's not rocket science knowing that cloud spend is only going to grow within the coming years, and OpEx is soon going to become the actual way of IT spend. It won't be CapEx-based spend anymore, and therefore you as an organization need to move towards an alignment and methodology where you can start to align product-based spend based on the capital that you're actually looking to spend out there.

You need to have a framework where real-time decision-making is a possibility, given the fact that you do have the technology and the pennies to do it. Last but not least, you need to programmatically start introducing all of these financial guardrails as code. Because as your cloud environments are all built by code, as the approach by these cloud environments is being controlled by the engineering teams, finance really needs to start figuring out the role that they actually look to play.

But guess what? This isn't a challenge that we haven't seen in the past. If we go back to 10 or 15 years ago, when we were all having this discussion around the wall of confusion between dev and ops completely on different sides, it turns out this is very much a similar scenario. Now what we're talking about is how do we bring the business, the finance functions, together with the IT teams? Just like before we were talking about BizOps and DevOps and SecOps, et cetera, now what we're talking about is bringing finance as yet another function that comes closer together with these development and operations and engineering teams in order to collectively make these decisions together. Finance is now yet another lens that we need to consider as part of it.

What FinOps actually is: an approach to managing and operating one's cloud spend by breaking down these silos between engineering, finance, and procurement, to bring everyone together to actually collectively make this decision together, very similar to what DevOps and SRE did when it comes to the actual engineering landscape where we were encountering these challenges in the past.

It is a methodology of collaboration between the various functions to be able to make the right decisions and trade-offs when it comes to looking at cloud spend, and not just looking at it from a finance perspective, but actually what is the consumer experience that we're collectively trying to build. It defines a set of metrics in order to have a common framework for decision-making using the notion of a financial trace that we'll go to in a second.

No longer are finance and procurement the gatekeepers of spend anymore, because back in the day, where IT spend was primarily controlled by these finance and procurement teams, engineering teams can just very easily go out there right now and, off the back of a credit card, go and consume cloud. So finance and procurement need to reinvent their roles, and how they are collectively going to take the domain knowledge and bring that to bear within this world of cloud consumption.

Last but not least, FinOps means having the ability to increase that visibility across all teams, whether that be finance, engineering, or operations, in order to make that collective decision-making process and drive the behavioral change within the organization where everyone has an understanding of what the implications of their cloud usage actually look like.

How do we bring all these teams together? What's our approach to making FinOps valuable for everyone within the organization? The methodology that I really like, and that has been tried and tested now with a lot of organizations out there, is establishing a financial trace.

What is a financial trace, and why do we actually need it? If we were to look at it on one hand, we've got things like cost drivers, business metrics, forecasted spend, potential architectural changes that we're making, business cases, benefits realization programs, et cetera. But in no way do we have the ability to trace these metrics, these data points, to the actuals that are being consumed or incurred when it comes to one's cloud spend.

A financial trace is a means to bring everything that you can currently see on the left when it comes to your core metrics and your core cost drivers with some of the data points that we're currently getting from the cloud providers, and actually being able to help answer questions such as: why have our cloud costs suddenly gone up and down? What does our forecast look like? Do we know why we're spending and what we're spending so much money on? What value has the digital strategy added to us? Or how much control do we actually have on our spend?

Later on in this session, we'll talk you through how you go about building a financial trace. Holistically, what a financial trace helps us do is bring together three domains: cloud engineering, product, finance, and operations as a collective partnership. It helps you build this framework where you can look at, at what point are you about to potentially launch a product, and what's your cost that's going on there? You can then start to visualize, based on potentially new features that you're looking to release, how your cloud spend is going up, and actually you as a product team know why your cost is going up, the finance team knows why that's happening, and the engineering team is able to provide that data.

As you start to make collective decisions such as purchasing reserved instances or making some architectural changes in your environments, you can actually see what decisions were made that had an impact in your cloud costs, which was a critical factor that organizations today have been missing. Because if today you go and ask someone, "Why do we suddenly see a fluctuation in our costs?" in reality, not a lot of organizations have the ability to give that answer, or at least to give it quickly, and they certainly don't have the ability to do that in real time.

What we'll talk you through throughout the rest of the session is what are some of the steps that you can take where you can start to bring these teams together, where you can start to answer some of these questions in real time. But also, what does good look like? What is the feedback loop that you can put in place between your engineering functions, your finance and operations teams, and your product teams to collectively make sound financial decisions?

How do you actually get started? Just like with every brilliant DevOps or FinOps or DevSecOps methodology, there is a maturity model. The FinOps Foundation has this phenomenal framework called the FinOps Maturity Model. We've then further tweaked it based on certain feedback that we've had working with our customers, and it gives you a very simple methodology. On one hand, you've got the crawl, walk, run model based on how quickly you actually want to go to your high level of maturity, and then you've got six different domains on the steps that you can take in order to increase your FinOps maturity.

For me, I've highlighted some of the key ones that one should focus on in bold. Being able to make sure you've got the right visibility into your IT spend is frankly critical, and we'll talk about some of the tooling that you can use to achieve that. Understanding what are the cost drivers with loosely coupled goals, as we talked about when establishing that financial trace, being able to pinpoint what business decision and goals we were looking to achieve that actually drove that cost up is fairly key.

Being able to understand if your resources are under- or over-provisioned: now we're looking at the more technical capacity management side of things, and removing those underutilized instances is also quite a key thing. Also being able to define those guardrails, those control frameworks for cloud usage. As your maturity increases, you can start to look to do more fancy things, such as perhaps internal team benchmarking and perhaps gamifying the process a bit, where you can look at which team has a much better FinOps coefficient compared to another.

Another element that we've seen work quite well is looking to tie one's carbon-neutral goals against your FinOps maturity, because a lot of the CSPs nowadays actually publish what their own carbon-neutral consumption looks like based on the cloud platforms that they're providing you. You can piggyback on top of that data and look at how carbon-neutral and carbon-efficient you are being when it comes to releasing new products into the actual marketplace.

When it comes to your FinOps maturity, there's lots that you can do, but I've highlighted some of the key ones that, as an organization, you should certainly start off with. My personal favorite is taking the entire FinOps maturity framework and building out an internal policy. On screen, I've given you an example of what a potential policy could look like, which looks to capture elements of information access, of how you actually organize your cloud environments, how you understand the data coming in from there, what are some of the controls that you're baking into your platform, and actually then how you're looking to further optimize that as time goes.

Personally, what I also really like to do is then take that and have real-time coverage and visibility on how every single product team is doing with regard to that FinOps policy. Again, you can start to gamify this process internally within your teams to look at how efficient your teams are being.

Once you've got that policy in place and you've got an understanding of how well that policy is being adhered to within the business, what you can then start to do is establish a lot of your core cost drivers. As we were saying, when it comes to establishing that financial trace, it's really key to be able to tie your business metrics all the way down to the actual potential cost implication.

The way in which you can start to do that is you start establishing the business objectives of the product or the change that you're potentially about to embark upon. Perhaps you might look to grow your user base. You then allocate a business metric against that objective. If you want to grow your user base, you could say, "We want to grow our user base by X%," or, "We want to track X amount of monthly active users." You then take it down yet another level, and you start to look at the technical implication of that business objective that you want to achieve.

Say if you want to grow your user base by X%, that means you now need to start scaling the number of instances by 5% in order to handle the request or that volume of consumption that you're about to see, which by default is going to have an implication on your compute bill. So now you can start seeing that people within the business can start to see the implications on their actual core financial bills based on the business decision they made. No longer is this just an engineering problem of, why has my cloud cost gone high? Actually, the business can start to see the implications to the financial side of things based on the decision that they've actually had to make.

The other element for me, which is quite critical, is collectively as a team across the engineering, finance, and product teams, building out a cloud benefits framework. This is something that you can again tie against your business decisions that you're looking to make. Some of those decisions could be tied to improving your customer experience. Some could be tied to business agility. Others could be tied to improving the raw performance and improving the operational side of things of your platforms. Some could be just financial optimizations, or it could be that actually, from a risk and compliance point of view, you want to improve the security posture of your environment. Once you've put these benefits together, you now have yet another dimension that you can work towards.

The last bit is making sure you have visibility for every single team out there, regardless of that being a business function, a finance function, or a product and engineering function. The way in which you could do this is initially, if you're at the lower levels of your FinOps maturity, you can use the native tools provided by the CSPs themselves. This, for example, happens to be a screen on Azure, but both Google and AWS have an equally mature one. You can then start integrating the data that you have coming in from these tools with your financial processes. If you happen to be an organization that's also multi-cloud, fear not, you've got tools out there that can give you multi-cloud visibility.

Now that you've got a policy in place, you've got the ability to track business drivers, and you've got business benefits with the visibility, how do things start coming together? This is what the holistic framework for a financial trace would look like. You, as an organization, for instance, want to become more resilient, or you want to increase your customer base. Phenomenal. You can track that within a system, and again, you've got automated cost management systems to be able to do these, or you could just track these manually.

You can then start to allocate business metrics of what you'd expect to see as an outcome from these business drivers and decisions. You then tie your architectural changes via architectural decision records on what it is that you're about to do. You can then start tracking the impact of those architectural changes, and soon you can start to see the cost drivers being impacted based on the business drivers that you collectively all agreed upon in the first place.

These cost drivers could be consumption of new services. It could be that you've had to scale your existing services, or you've had to change the size of your financial purchasing model, or you've actually had to reevaluate the suitability of your cloud architecture in its entirety. Soon, you can now start allocating business drivers suited to cost drivers. No longer have you got executives asking questions such as, "Why have my cloud costs gone up so high?" Because it was the collective executive decision that was made in the first place that you can now trace all the way through the end-to-end life cycle and look at the actual cost implications of making some of these decisions.

A lot of what we've talked about for now sounds quite theoretical. How do you actually go about implementing some of this? Because on paper, this all sounds phenomenal. What does good actually look like? To me, there are two elements to it. One element is how do you make this look good for perhaps your decision-makers and people who aren't necessarily involved in the day-to-day, but also how do you provide that feedback loop to your engineering and your product functions, whilst also making sure your decision-makers have the ability to make the right decisions?

To keep things simple, for us, what's critical is always establishing a continuous feedback loop. If you're a leader, we strongly recommend taking all this data and putting that behind a BI tool, and actually amalgamating all this data all the way from the actual cloud cost through to the forecasted cost. Again, this is data that you can actually get from the financial tools of your cloud providers. You can then start adding against every single one of these the actual benefits that you've currently been tracking throughout your actual cloud consumption, and this is something you can do on an application-by-application basis or on a product-by-product basis. It's up to you. But you can also start to see some of the cost drivers that potentially you can play with in order to further optimize your costs.

As a business leader, you now have the ability to look at your entire digital transformation spend on a page and say, "Brilliant. Here are some of the levers that we can play, and let's look at how that actually has an impact on our actual consumption."

On the other hand, if you're in engineering and a product function, you want real-time feedback loops. You want the ability to make decisions and changes quickly. On the right-hand side is an example of a Slack bot that we created with the team that had an AWS landing zone in place. In this case, what we wanted to know is how can we make sure we're optimizing the environment of AWS WorkSpaces that we were running, and the moment that we had idle WorkSpaces, either remove those completely or give us the ability to have a manual removal process.

What we had was a Slack reminder that, on a daily basis, every morning as the engineering team came in, would give us a pop-up of our FinOps status saying, "You've got X amount of idle WorkSpaces running." In this case, here's the potential impact when it comes to the commercials, which in this case you can see was incurring us a $2,000 cost per month that was completely useless. Therefore, as an engineering team, you can then go and look at getting those WorkSpaces out of the way and further enhancing the cost optimization of your environment. This is one way of how you can establish a feedback loop. I'm sure there are others out there within the community, and I'd love to learn more.

For us, the key thing always is having a North Star. The North Star for me always was: how can you have a perfect partnership between your finance, product, and engineering teams? That was certainly one. But on the other hand: how can we make sure that your maturity becomes so good that over time, as your maturity increases, the unit cost of your cloud consumption goes down? That unit cost can be on a per-environment basis, per-product basis, or per-service basis. That's totally up to you. Making sure that those costs can go down such that you've optimized that to the perfect level, whilst also having that partnership between finance, product, and engineering, such that you can collectively make those decisions, is key. Because to date, finance has been completely removed from those discussions. If your cloud consumption is going to scale, you need to bring them as part of that inner circle and make those decisions together.

To summarize, what is the value of FinOps? A, it helps you make sure you've got an end-to-end trace of your decisions, as we talked about with the financial trace. B, you have the right data to make that decision, and this isn't just us going on a whim and seeing if we can do something, but rather having the right data and the right visibility to make those decisions. The third bit is having a cloud-first approach to financial management, as opposed to the traditional approach to IT and management that we talked about.

The other bit is having product teams empowered with the right feedback loops to be able to make those financial decisions. No longer are they detached from the financial implications of the work that they're doing, but every single engineer, every single product owner, every product lead can now start to see what the implications against the company's bottom line are based on the decisions they're collectively making. That could be on the architecture, or that could be on the features that they're looking to choose.

You're now starting to collaborate with non-technical functions. Just like we said, DevOps and DevSecOps started to do that with other parts of the business, FinOps looks to bring in yet another domain to have everyone in the agile and modern ways of working. Last but not least, a byproduct of all of this happens to be cloud spend. Whilst everyone might be thinking that FinOps is all about optimizing cloud spend, if you did everything above, that happens to be the perfect byproduct that everyone's looking to get out there for.

If I haven't convinced you already of the power of FinOps, and if you haven't already got a good enough insight of some of the techniques and methodologies that you can use, you've got a plethora of content out there hosted by the FinOps Foundation, who've done some phenomenal work. You can go check them out on their website, as well as join their Slack channel, where you've got a lot of community members collaborating and sharing their techniques and their experience within this industry, and I'm sure you'll be able to contribute to that as well.

If you did enjoy this talk, we've got a lot more on our website as well. If you wanted to go check them out in the form of blog posts or webinars, go check us out on www.contino.io and you'll be able to get even more FinOps content that perhaps might be of interest to you.

Thank you for listening. I will be on the Slack channel for any further questions that you might have. But if I don't get to speak to you, enjoy the rest of the conference. Bye-bye.