Is FinOps Really About Saving Money?

Moving to the cloud was supposed to reduce costs. No longer owning infrastructure would remove the need to negotiate expensive licensing contracts, manage server maintenance or worry about substantial electricity bills. Our operational costs would also be reduced, with our DevOps and system admin teams freed from mundane tasks such as making backups and ensuring hardware was running smoothly — or that’s the theory.

Over the last few years, and despite recent noise to the contrary, adoption of cloud computing continues to grow. However, things are not going strictly as advertised on the cost side! Many CFOs are being presented with invoices that look similar to, or in some cases are greater than, their on-prem counterparts. This was not supposed to happen and it’s leaving some organisations dismayed — a feeling that is colloquially referred to as Sticker Shock.

Enter FinOps. It’s a portmanteau of Finance and Operations, a relatively new buzzword in the technical lexicon and is positioned as a philosophy that can save us from wayward cloud spending. In practice, FinOps typically manifests as a cost-cutting mechanism, by identifying which machines can be turned off and then hounding developers until instances disappear from the monthly naughty list!

When we talk to folks in the industry we’re commonly presented with the idea that FinOps is solely about reducing costs. However, we feel that pigeonholing it in such a way does it a disservice and prevents organisations from extracting maximum value when adopting the FinOps philosophy.

The FinOps Foundation has created a definition of this term. As of November 2021, it defines FinOps as:

There are two key parts to this message in our minds. First, FinOps requires a shift from CapEx to OpEx thinking. Second, it’s a change that organisations were expected to make as they moved to the cloud.

By embracing multidisciplinary teams that comprise engineering, finance and business, a FinOps mindset should result in an environment that empowers product teams to deliver while being cognisant of their budget. At the same time, the business is able to 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 are able to understand the cost and value of the services they deliver then an open, transparent dialogue can be had with the business decision-makers, who can then act on this information too.

What does this mean for product teams and businesses? 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’, and previously opaque, decision-making can be abated.

So, is FinOps just about saving money? No. Indeed, the FinOps Foundation flips this idea by stating : “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 who encourage and evangelise 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.

The first thing that strikes us when dissecting the FinOps definition is that it’s a data-driven process. FinOps requires telling a story to the business and to delivery teams and you need data 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.

It’s all well and good having a story, but you must get it into the hands of your readers in a timely fashion, we don’t want to do a George R. R. Martin and leave the story only partially told. To have maximum 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.

With all the moving parts in place, and engineered to the same standard as you would any customer-facing product, it’s crucial the story being told is accessible (to the right people) and is told in a way that is easily understood, perhaps even at a glance.

What does this mean? Input from your Design and Product teams input is essential — after all, you’re building an end product for your team, something tangible, something that your staff want to engage with and become invested in. Getting this input increases the likelihood of changing the way your business operates. We like to think of this as the carrot approach.

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 — if you can’t behave you will be punished, otherwise known as ‘the stick’. This approach may well reduce spending but it will also have an impact on innovation and motivation. Why? Because you’re telling your teams that it’s more important to remove all risk from how they work than it is to try something new. Congratulations, you’re now doing on-prem in the cloud!

So, if you want newer, faster, smarter features (and other developmental benefits), it’s important to remember that you can’t have the handbrake on at all times.

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

If we’re honest, measuring costs initially is fairly straightforward — CSPs have ‘out of the box’ tools that provide a great way to get started on the FinOps journey. From this position, requirements can be defined and redefined as you move forward and new tooling can be added to solve issues such as right-sizing.

Value, on the other hand, is considerably harder to measure and is something to be covered in a separate blog post.

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

One approach we have seen 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, which 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.

Automation will also help keep up with the cloud. For example, if a cheaper EC2 instance is added, you want the tool to tell you about that and not have to rely on someone being up to date with every cloud change.

When discussing spending, you might think about compute resources, but we often forget that everything you do in the cloud has a cost, from bandwidth to API calls to virtual entities like secrets. Then there are factors you 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 your cloud provider will help you and offer a discount, but that's not always the case. Again, this is when automation can help you. You can and should configure your cloud to send alerts when your 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 what if we tell you that FinOps should start as close as possible to your development environment?

We’ll give you 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, but if we allow that change into production where that API is triggered hundreds of thousands of times 'on Friday' to generate weekly reports then… I suppose you get our point!

What you want in general is the shortest possible feedback loop between your cloud environment and your 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.

Apply weights to your test cases measuring the cost impact of the same API call in production, and you have an excellent preemptive system at your disposal.

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 is a relatively new term, but as a field we like to rename and rebrand existing ideas on a seemingly endless basis. FinOps is something that many companies have been doing for years as part of their cloud governance effort — it just didn’t have a name. Now that it has a flashy term, the industry is scrambling to make the most of FinOps, especially given the current dynamic nature of the global economy.

We are a boutique software engineering and delivery company, we deliver modern digital experiences to our clients. Over our 10-year lifespan, we've realised that problems like those we’ve described in this blog post are dynamic — a ‘one shot’ solution simply masks the symptoms and doesn’t act as a cure.

This can be tricky for companies to put into practice because driving costs down has always been viewed as a sensible approach in many businesses. However, it’s never as straightforward as ‘pay less, save more’. Indeed, you may pay more in the long run if you try to avoid spending in the short term. What’s crucial is that you invest your money wisely, in the right ways and at the right times.

We operate with a set of core principles that are designed to deliver sustainable success for our clients and give them value for money. It’s why we’ve baked cost optimisation into our processes.

We always work with our clients’ best interests at heart and treat their money as if it was our own. It’s why we’re driven by delivering a high-quality service for them and giving them a great experience. It’s also why 85% of our clients refer us to their networks — because we care about making a real difference to everyone we work with.

Ping us if you want to assess your posture or if you need help embedding FinOps practices in your business.