Cost Optimization in software and systems engineering can offer real value - it’s not just a buzzword. I know this because I’ve done this type of work for multiple companies over the last few years, with fantastic results if I may say so myself.

In fact, it’s not just me who believes this: the entire (only?) reason companies hire me to help them with this is that I help them save more money than I charge them.

You probably clicked on this blog post because of the edgy title. Why would someone who makes money from “Finops” have beef with it?

Well, kids, I did cost optimization before it was called “Finops”. And when Finops emerged as a term that encapsulates cost optimization activities and promised to make it a more mainstream engineering concern, my first thought was:

OK, maybe I am jaded

Maybe I am just a bit jaded because I’ve been doing this for so many years, and all of the things the Finops Foundation has to teach seem either incredibly and insultingly and boringly obvious, or just useless fluff. Maybe for somebody newer to the game the FF is an amazing resource of unimaginable clarity. But 1: I doubt it, and 2: this is my blog so I’ll tell you why everything they do seems so 💩shit💩 to me.

And just for the record, I do think there’s value in bridging finance and engineering, but whatever FF is doing… ain’t it.

What is Finops? What is The Finops Foundation?

In case it’s not clear by now, “Finops sucks” in my title really refers to the Finops Foundation.

Let’s see what they have to say about what they think Finops is:

Finops is an operational framework and cultural practice which maximizes the business value of cloud and technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams.
https://www.finops.org/introduction/what-is-finops/

A framework and cultural practice?

No, really, have a look at https://finops.org

It’s depressing.

• You can take the certification exam to become a Finops Certified Practicioner for $500.
• And once you’ve done that you can level your game up and become a Finops Certified Engineer for another $500.
• And then you’ll be ready to take the course and the exam for the Finops Certified Professional for $2000.
• And once you have all those you get to pay another grand to attend a conference with other people who paid to be certified!

Oh and by the way they are a non profit. Yep, you heard that right.

You get to pay thousands of $ to a non profit whose presumed purpose is to help your business streamline and reduce costs.

Presumably they help you reduce your cloud spend, and by the way they are supported by all cloud vendors.

Because of course the one thing cloud vendors want is for you to reduce your spend with them.

You can’t make this shit up!

Am I the only one or… does this feel a bit scammy?

Because not only does the FF not help with cost optimization, they actively hinder it by adding more layers of bloat and generating more bureaucratic drones that offer no value to your business.

By spending just a few mere thousands of $ per person your staff will learn things like this:

[…] there are Core Personas who will always be involved in the practice of FinOps. These Core Personas provide all of the organizational disciplines to successfully use cloud effectively. Each Persona has a role to play in the organization as well as in the practice of FinOps, and each has perspectives, challenges, metrics and outcomes they seek that may be slightly different from other Personas.
https://www.finops.org/framework/personas/

Guess how useful all this will be when you have distributed systems spanning multiple clouds, teams, 3rd parties, vendors, and systems relying on some bit of code built 10 years ago by some guy who retired aged 42 in 2021, written in some obscure library of some weird flavor of a programming language you’ve never heard of, oh and nobody knows why but if you turn that thing off random things downstream start breaking - and your engineering team who have been working on this system for years don’t know how to run this more cost efficiently.

But thankfully you’ve taken the Finops Certified Professional course and you know that adding tags to resources is best practice and you know about personas and their unique perspectives and challenges, so not to fear! (here’s a random Reddit thread I found talking about this sort of experience: Is Finops the overlooked key to cloud efficiency?)

And what about the Finops Engineer certification? Surely a certification with the word Engineer in it will teach you about engineering, so let’s see what their learning outcomes are:

• Gain the vocabulary needed to collaborate with FinOps stakeholders
• Learn about the two main levers for cost optimization
• Get an introduction to cloud billing data and the FOCUS initiative
• Understand the Iron Triangle and how to use it to make data-driven decisions
• Learn how FinOps and Sustainability go hand-in-hand

It sounds a lot like this will teach you some shitty acronyms (“vocabulary”), some shitty levers that don’t work for any real world engineering problem, and how to read your cloud provider’s billing report. Oh and that Finops and Sustainability go hand-in-hand.

Wow, I am sure your company’s entire engineering department won’t be able to wait for your valuable feedback once they find out that you know Finops and Sustainability go hand-in-hand!

What else does Finops involve?

You know what else this polluted bureaucratic version of Finops has led to?

A whole lot of noise on LinkedIn. Endless hordes of “Finops Influencers” writing posts like this:

Companies: “We need AI to reduce cloud spend!”
Also companies: 🧠 No tags, 🔥 Idle clusters from 2022, 💀 No ownership.

And under each post? Dozens of “Great insight!” comments from other FinOps drones.

This is where they train before being promoted to becoming AI influencers on LinkedIn 😛

You don’t need an entire new discipline (Finops) to capture basic housekeeping tasks like tagging your resources and removing unused resources.

It’s literally the first few things you learn when using the cloud - I bet it’s part of the AWS Cloud Practitioner (and if it’s not, it should!).

Nobody benefits when engineering is relegated to such lazy oversimplifications.

Why is the FF version of Finops crap?

Finops should be about engineering. Good old engineering, doggammit!

You can’t do serious cost optimization work unless you’re an engineer. I am not saying that to gatekeep, I am open to various definitions of engineering. But you can’t do it sitting in a Finops team without an understanding of any of the systems involved.

And you know why? Because there is no size fits all solution. There’s not a single answer to the problem. It’s not like, “oh your system costs a lot? just switch to serverless/microservices/cloud/onprem/kubernetes/small team/big team/rust/golang/python/bash/client side/server side/caching/no caching/live reload/static/dynamic/aws/gcp/azure”. Any and all and none of these could be a good solution to the problem at hand. And knowing what you should try or bother with is what experience in engineering is about.

And to do proper cost optimization, you need to be capable of understanding the systems at hand at least as well as the architects and engineers who designed and built them.

Why did Finops become a thing now?

Finops is closely related to Big Cloud. Why? Because it’s so damn convenient to spin up tons of instances… and more often than not, developers are not incentivized not to.

That’s the entire promise of the Cloud anyways: elasticity. You pay some overhead for the convenience of using someone else’s servers, but if you hire any servers you don’t need - don’t worry, it’s all elastic, you can just scale down.

But the reality is that most businesses don’t go through this exercise of scaling down - or reviewing how much hardware is actually needed vs how much is currently being commisioned off of Big Cloud.

Sometimes there are excuses like “we don’t have time for this, we need to ship features” - so this exercise gets tagged as “tech debt” and is forgotten.

And sometimes that excuse is valid: what’s the point in spending 3 months doing engineering work to save 1 million off your AWS bill when you can use the same time to build a new feature that wins you a 100 million client?

Other times, companies crumble under the weight of this tech debt: that 1 million in cloud costs is damn heavy when your biggest client only pays you $10k.

In general though, I’d say about 80% of the businesses I’ve consulted for had almost 0 internal incentive (from the POV of the engineers) for cost efficient development, and almost 0 penalty for inefficient development.

Interlude: The masterfully written blog post I accidentally saved half a million dollars explores these themes - it’s the story of someone who managed to save their employer a lot of money despite the management.

More often than not, when a developer spins up some infra to run their service, whether that’s an EC2 instance or a k8s resource with requests and limits, the numbers they pick can be more or less anything. It’s usually a finger in the air exercise - “I think it probably needs a few gigs of RAM”. And managers (project/product/engineering, whatever) usually prioritize “platform stability”, aka “I don’t care how much it costs, my SLO is delivering new features and good uptime, not cost”. And so nobody really cares about picking the right system or setting the right resource requests. At best they’ll have some automation around this, something that looks at actual utilization and adjusts requests. These things are pretty bad too, in my experience.

But anyways, did people not have a cost problem before the cloud? Of course they did - except it manifested in a different way and you wouldn’t have been able to course correct as easily, because you’d buy hardware upfront so the cost was already sunk - so it didn’t really matter whether your service now needs or uses 2GB of RAM or 32GB of RAM, as long as things work.

Back then, just as today, only those engineers with a strong sense of integrity towards the software they build would actually take the time to understand their code and their systems intimately, and then work within self imposed limitations.

I say “self imposed limitations” because when you restrict yourself to achieving the required functionality with limited hardware, it takes more ingenuity and effort to deliver, but if your manager doesn’t care, and your bonus doesn’t depend on it, and nobody gives a shit if you just throw hardware at it… you just throw hardware at it.

What now?

We need to protect our craft from those who seek to diminish it.

(I am reminded of DHH’s post on celebrating incompetence)

And we need to protect it from bloat that harms the businesses we work for.

Not out of some romantic idea of duty towards the employer, but because when we don’t, it leads to enshittification of our jobs.

Engineering is first and foremost about finding solutions.

And good engineers of all flavors have been building stable systems that work efficiently with modest hardware requirements for decades.

If your flavor of engineering ends up crippling your business with extra bloat, it’s not really engineering, it’s just 💩.