FinOps isn’t just a cost saver — it’s a revenue driver

The FinOps Foundation defines FinOps as:

"… an evolving cloud financial management discipline and cultural practice that enables organisations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions."

There are two key parts to this message. First, FinOps requires a shift from capital expenditure (CapEx) to operating expense (OpEx) thinking. Second, it’s a change that organisations were expected to make as they moved to the cloud.

By embracing multidisciplinary teams that are comprised of engineering, finance and business, a FinOps mindset empowers product teams to deliver while being cognisant of their budget. At the same time, the business can understand what teams are doing and how that impacts the bottom line. Succinctly, FinOps fosters accountability.

Placing accountability into delivery teams means they are responsible for trade-offs between speed, cost and quality. If product teams can understand the cost and value of the services they deliver then an open, transparent dialogue can be had with the business decision-makers. These decision-makers can then act on this information.

At times spending will contract, which is why FinOps is often associated with cost-cutting. However, the opposite is also true — investments can be prioritised. There is a potentially unappreciated consequence, if all sides of the organisation understand why changes are made then the consequences of ‘top-down’ decision-making can be abated.

The FinOps Foundation states: “FinOps is about making money”. The rationale for this is that it’s about optimising and empowering delivery teams by stripping away blockers, so they can deliver more for businesses and help them to grow.

If this sounds familiar it’s probably because you’re thinking of your Security Operation Centre (SoC) — a centralised team that encourages and evangelises best practices for things like encryption, networking and software supply chains. Like SoC, the central FinOps team exists to create efficient, streamlined and automated processes that increase velocity while shifting ultimate responsibility to those who own business-facing issues.

FinOps requires telling a story to the business and to delivery teams, and data is needed to do this. To tell a story, data needs to be consistent, it needs to have a single definition of truth and clear ownership; it needs to be high quality — it must be fit for the purpose it was collected for.

To have maximum and sustained impact, the effect of each change should be visible as soon as possible. This may mean minutes, hours, days or, potentially, longer — context needs to be taken into consideration. It’s crucial the story being told is accessible (to the right people) and is told in a way that is easily understood.

Input from Design and Product teams is essential — after all, the organisation is building an end product for its team, something tangible, something that staff want to engage with and become invested in. Getting this input increases the likelihood of changing the way the business operates. 

Failure to engage with staff will likely result in no net change around OpEx spend. This typically results in the implementation of draconian and inefficient processes that aim to limit behaviour This approach may well reduce spending but it will also have an impact on innovation and motivation. This is because organisations are telling their teams it’s more important to remove all risk from how they work than it is to try something new.

For newer, faster and smarter features, it’s important to remember you can’t have the handbrake on at all times.

If FinOps is about cost optimisation then the data must include a measure of monetary value as well as a measure of business impact.

Measuring costs initially is fairly straightforward — cloud service providers (CSPs) have ‘out of the box’ tools that provide a great way to get started on the FinOps journey. Requirements can be defined and redefined as you move forward and new tooling can be added to solve issues such as right-sizing. Value is harder to measure, but Google provides a useful starting point. 

Even with appropriate definitions of value and associated metrics in place, there are still a couple of problems: velocity of change and the scale at which changes happen.

One approach is to deploy tooling that will report cloud costs, review outputs regularly (once a month to once a week) and implement changes based on these reports.

To implement this correctly, we must rely on something other than manual processes; we cannot hope that people will remember to tag their resources correctly or that we will be able to pre-empt our utilisation for the next 12 months accurately.

The cloud moves quickly and people simply can’t keep up; from start-ups to enterprise estates, things scale and change way faster than we can predict or act. This is why FinOps needs to form part of the delivery process, just as much as security.

Modern organisations automate their security. CSPs have made this fairly simple by providing tools to assist in doing so, and the same is true for FinOps. Adding automated cost management into software and infrastructure pipelines shifts FinOps left, minimising engineering impact and reducing cognitive load.

Everything you do in the cloud has a cost, from bandwidth to API calls to virtual entities like secrets. Then there are factors that organisations cannot control with the weekly review — how often have we seen messages online like “because of X, I’ve received a huge cloud bill that’s much larger than I expected”?

Sometimes the cloud provider will help and offer a discount, but that’s not always the case. This is when automation can help. Organisations can and should configure their cloud to send alerts when their bill exceeds a fixed limit, but even that should not be a one-off.

You might think FinOps is just about monitoring your production environment and applying corrective actions. But FinOps should start as close as possible to your development environment.

Here’s one example. Imagine a developer changing a line of code and triggering double the cloud API calls for the same action. This might not seem like a big deal. However, if we allow that change into production where that API is triggered hundreds of thousands of times ‘on Friday’ to generate weekly reports then… your weekend will be spent sifting through a mountain of identical reports!

In general, what is desirable is the shortest possible feedback loop between the cloud environment and the engineering team. Having something as simple as an alert saying, “You just doubled your cost for this test case” might have saved you from this incident.

Applying weights to test cases measuring the cost impact of the same API call in production is an excellent preemptive system. 

In the same way that you monitor your system for critical metrics (e.g. latency) and have your engineering team exposed to them, so they can spot changes right after deployments, you want your team exposed to FinOps metrics continuously. And you must allow them to respond appropriately when code/infra changes trigger unexpected events.

FinOps optimises cloud financial management through a data-driven, collaborative and automation-centric approach. By aligning cloud spending with business goals and fostering a culture of accountability and cost-consciousness, organisations can not only reduce costs but also increase revenue. This is achieved by being able to reallocate resources to more valuable endeavours and seizing new opportunities in the cloud environment.