FinOps 101: Can you? Should you?
We consider FinOps to be more than just a function or a service – it’s a culture change. And that...
In part 2 of this FinOps blog series (part 1 is here), our FinOps Lead Max Guhl tackles some burning FAQS with his characteristic honesty. Want insight on how to divide FinOps responsibilities within a team? Curious about how to make it work with multi-cloud? Wondering which workloads to start with?
Read on – you’re in the right place.
Max: I think it’s a cloud spend issue. Organisations are now at a stage of cloud maturity where the scale of spend is on the radar of senior leaders. Before, it simply wasn’t a big enough line item in the budget. Hyperscalers have always recommended using tagging and implementing spend controls and cost allocation early on. But because there was limited business impact in the early days of cloud adoption, people didn’t pay as much attention to it.
But hyperscaler platforms are far from just being “hosting” services. And that’s where the trouble starts. We need to rethink this view of cloud as a replacement for on-prem infrastructure services. The sheer richness of what it offers goes so far beyond servers and storage, that it’s nothing short of unprofessional to dump cost saving responsibilities on to IT.
Instead, I would strongly advocate for having at least 3 parties at the FinOps table: finance, IT operations and application developers/engineering. This is because:
It’s also very important that IT and finance learn to get out of the way of engineering teams when it comes to designing for an application’s best possible ROI / TCO.
Max: FinOps is the short version Financial Operation, it’s the art of managing financials in the public cloud. Here’s the quick definition: Real time reporting + just-in-time processes + teams working together = FinOps.
Each individual engineer, software delivery squad and operations team can start living FinOps simply by reading and analysing automatic suggestions from tools like AWS Cost Explorer and asking:
Start with thinking about it, and learn as you go. Another nice angle is thinking about how you can build an application the cheapest possible way, without sacrificing security, reliability or quality/performance. Make this a nice hackathon exercise for architecture teams.
We’ve seen great results with these bottom-up approaches, in terms of building up the right culture and capabilities. They give FinOps the same feel as the DevOps mindset of “you build it, you run it”. Think of it as “you build it, you fund it” – and see what happens next!
To be honest, without buy-in from your engineers and administrators, you’re not going to make FinOps a reality anyway. If you follow a pure top-down approach, you risk creating a sort of shadow IT. You also risk your best engineers thinking about whether they want to work in a place where finance gets to decide on technical architectures.
Max: There has to be vision and drive from the top, as with any change management initiative. At the end of the day, FinOps is about making money. By optimising cloud spend, you can drive more revenue, signal customer base growth, enable more product and feature release velocity and even help shut down a data centre.
From our point of view, the easy part is the top-down modelling and chargeback management. We solved this years ago and even built tools for it. So don’t waste time on that – instead, focus instead on people, organisation and culture.
Max: There are a few factors in play here.
First, this is where we enter the realm of contracting with hyperscalers. If you’re getting a big discount or co-invest from AWS, Azure or GCP, you’ll have a better TCO for cloud usage in a given time period. As an end user of cloud (e.g., an individual developer), these things are “given”, and the IT organisation and digital product teams aren’t in a position to influence them. They’re more likely to be in the hands of corporate purchasing and procurement departments, which sit across the organisation and are affected by many other factors.
Second, when you’re using more than one hyperscaler, you need a way to get an accurate and holistic overview of your spend. Moving between hyperscaler tools is inefficient and risks savings opportunities falling through the cracks. A “do it yourself” approach doesn’t really work here, because it’s so complex.
Tools like our Nordcloud Klarity suite provide full insight into and understanding of spend and cost optimisation opportunities across all clouds and VMware. When it comes to multi-cloud FinOps, everyone can then understand the contractual situation, discount models and spend across the estate – which gives you a mechanism for enforcing accountability and embedding that FinOps mindset.
Max: Everything has its limits. But as with DevOps, it makes little sense to start with why FinOps wouldn’t work.
For sure, FinOps is more interesting and impactful when used with dynamic workloads than with static server estates. But implementing a mindset and an approach that’s conscious of cost-of-usage and cost-of-design is of value, regardless of application type.
On average, people are leaving 20% of value from the cloud on the table because they’re not keeping on top of their usage and spend consumption.
Check out this FinOps guide for ideas on how to capture that value.
(And if you want to read more of Max’s honest insight about getting started with FinOps, read part 1 of this FAQ series.)
Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.