CloudZero has a useful article about the true cost of cloud computing although the headline isn't particularly surprising:

Cloud is expensive.

Yes, it's expensive but the interesting number is in the cloud WASTE. Most organizations have a LOT of cloud waste, and the solution is familiar: right-size instances, buy commitments, eliminate idle resources, architect for cost, and measure cost per customer or feature.

I think there’s something fundamentally wrong with the idea that we look at reports and try to scale down.  As with most of our tech stuff, it’s not really about something going rogue, we usually build up services that we need for the architecture we built. 

We’ve all gotten very good at spinning up services, and to some degree spinning them back down. We haven’t gotten very good at asking, “did I really need all that?”

This isn't just my  weird little architectural obsession, it’s basically what FinOps has been saying but not getting out of tech teams.

The FinOps Foundation's current framework actually says the goal isn't simply to get a lower price for cloud resources. It's to maximize the business value of technology, and under its Usage Optimization capability, it pretty much gives the business rule for flat stack's rule number one:  resources should be properly selected, correctly sized, only run when needed, appropriately configured, and highly utilized.

I generally feel that FinOps starts with the bill and works backward. The flat stack manifesto starts with the architecture and asks what the bill should look like. But they end up in the same place. Yes, you can buy a reservation, scale down and right-size the instance, you can move storage to a cheaper tier, you can negotiate a better rate… but that all assumes you actally need all that tech in the first place.

Flat stack is the concept of doing less so there shouldn't be anything TO scale down. We say, delete resources you’re not using, don’t set up a scheduled tasks to run a workload nobody needs, don’t create an archipelago of data islands… 

This is where the flat stack is a FinOps strategy because the objective isn't:

How cheaply can we run this architecture?

It's:

How little architecture do we need to run at all?

Rule #3 of the Flat Stack says the balance sheet is the product owner. The FinOps Foundation says essentially the same thing in more diplomatic language: business value should drive technology decisions, and everyone should take ownership of their technology usage.

Or, more to the point, every architecture has a financial consequence.

A database running 24/7 , the ec2 instance that's running the Kubernetes cluster is sitting idle on, the warehouse that wakes up to answer queries that could have been answered from somewhere cheaper… a dependency that runs another service… a home grown solution that requires an engineer to maintain it… these all have financial consequences.

I’m not saying engineering teams aren’t aware of costs, but they’re often caught between doing nothing (we don’t have budget) or arguing with Finance to let them keep running things. But honestly, these aren’t Finance problems, these are Engineering decisions. 

If you look at the Flat Stack rules through a FinOps lens they start looking less like an architecture manifesto and more like a cost-control policy.

Do not wake the Beast. If the warehouse isn't needed, don't run it.

FinOps explicitly calls for workloads to run only when required.

Keep your center of gravity low. Keep data in open, inexpensive storage rather than forcing every access through an expensive always-on engine.

That's architectural optimization.

The balance sheet is the product owner. Make cost part of the architecture decision rather than something somebody discovers in the monthly bill.

That's financial accountability.

Every dependency is a decision. Every service you add has a cost, even when its first line item says $0.

Someone is going to have to pay for compute, storage, traffic, monitoring, maintenance. FinOps calls this optimization of technology usage.

Build it stateless. Build it to scale to zero. Don't pay for idle capacity.

That's literally one of the principles of FinOps pretty much verbatim. 

But when you read through these with a Finance eye there is no requirement to use cheaper tech, nothing about negotiating rates or target percentage savings, it just says… architect it to use less and the FnOps savings will appear in the mix. 

And I think, with all due respect to our friends at Cloudzero, reporting doesn’t solve the problem, it just gives something for people to argue about.  Not saying we don’t need visibility, in fact I just found a service that was chewing through compute because it showed up on a report and we were able to fix it. 

But we fixed it to this standard… we found a practical problem, had a framework for a practical solution, dropped the bill by 20%. If Finance tells Engineering that the AWS bill went up 30%, Engineering has to go find something to change but that’s just a witch hunt.

If cost awareness is part of the architecture from the beginning, the optimization happens before the invoice which is the entire point of this whole scale-to-zero flatstack stuff I keep evangelizing.