Cloud changed the physics of infrastructure.
We traded scarcity for abundance, predictability for elasticity, and centralized line of sight for engineering autonomy.
Born from this schism was the FinOps movement. Armed with dashboards, chargeback models, and “best practice” playbooks, it attempted to reclaim what was lost. It promised to restore order, but instead, it created bureaucracy.
It was the right diagnosis: misaligned incentives and low visibility. But the treatment never evolved. Instead of adaptive operations, FinOps became archaeology: studying what was already lost.
It’s time to rebuild FinOps from first principles.
FinOps emerged for a reason. As elastic cloud spending replaced fixed CapEx, finance and engineering lost their shared frame of reference. The movement’s first, necessary task was translation: creating the dashboards, allocation reports, and unit economics that made spend legible again.
It also succeeded in framing the problem, correctly connecting cost and stability to business outcomes like velocity and innovation. This executive-level view was a crucial first step. But it’s also where FinOps stalled.
It never made the leap from reporting to action. It became too managerial, where it should have been, first and foremost, operational.
FinOps’ primary loop is human: review, decide, adjust. That works quarterly; it fails when cost decisions occur per workload, per minute, per service, directly impacting business outcomes.
The first era of FinOps made cloud economics legible — but also offloaded accountability. Vendors told customers to “eliminate waste” while offering no automated means to do so (and quietly ignoring the structural waste in their own pricing models). They gave us visibility and called it control. The next era flips that: control first, dashboards second.
Most FinOps practice looks like this:
Visualize → Analyze → Recommend → Ticket → Tune.
This fails for structural reasons:
The result: FinOps devolves into cost archaeology, studying what already went wrong. Dashboards are a necessary step, but they don’t close the loop.
What we need is a mechanism that expresses business intent and enforces it at runtime.
A concrete case makes this idea clearer. Google’s BigQuery is a good one: its layered pricing model (on-demand, Standard vs. Enterprise Editions, capacity autoscaling) is a microcosm of cloud economics and the perfect place to prototype real FinOps control loops.
Before we can redesign the control loops, we must first ask what they are actually optimizing for.
A lot of FinOps is focused on increasing efficiency, measured by low-level utilization metrics.
But those metrics don’t translate to customer and business outcomes.
In the BigQuery context, this means translating vendor-specific primitives like compute capacity (slots) and throughput (bytes scanned) into outcomes such as:
Optimize these, and you improve user experience, margins, and forecast accuracy — not just your Grafana charts.
At the heart of cloud economics lies a single, hard problem: allocation.
When resources are elastic but budgets are not, optimization becomes a control problem.
We can compute anything we want¹, at any speed — but at what cost, and within what budget?
Monetary, latency, flexibility, attention — every system has limits.
Any workable control system has three necessary components: a tension to balance, a mechanism to act, and rules to guide choices.
These three components are the system’s first principles. Let’s state them formally²:
Every organization in the cloud optimizes for some combination of these cardinal goals:
These forces don’t always align, and that’s what makes cloud economics a continuous optimization problem, not just a budgeting exercise. A startup chasing product-market fit will rationally optimize for flexibility and speed; a bank will optimize for predictability and control. Same cloud, orthogonal objectives.
The best systems close the loop between speed, efficiency, and learning velocity — so teams can move fast and stay within their economic and technical budgets.
That’s the real heart of FinOps: aligning incentives so that experimentation isn’t a financial liability.
So what’s the alternative to reactive cost management?
Proactive declaration of intent, and letting the system enforce it. But how to codify our goals from theory into practice?
A Service-level Objective (SLO) contract is the mechanism for this. It translates the competing goals of customer outcomes (latency), predictability (budgets), and flexibility (autoscale policy) into a single, declarative artifact.
In the BigQuery context, a simple contract might look like this:
service: analytics-warehouse
objectives:
- name: bi_latency
target: p95_latency_ms <= 2000
scope: dashboards/*
- name: ad_hoc_latency
target: p95_latency_ms <= 30000
scope: worksheets/*
- name: monthly_budget
target: spend_usd <= 250000
- name: limit_waste_factor
target: billed/utilized <= 1.2
- name: limit_slot_contention
target: slot_contention <= 0.01
policies:
- prefer_commits_when: forecast_utilization >= 0.7
- allow_autoscale: true (cap +40%)
- enforce_admissibility: true
audit:
- ledger: actual outcome metrics, counterfactuals
Config files are just one interface. Another option is to invert control and declare SLOs directly inside workloads:
-- @slo: p95_latency_ms <= 2000, budget_usd <= 0.05
SELECT COUNT(*)
FROM analytics.dashboard_usage
WHERE event_date > CURRENT_DATE() - 7;The execution engine reads the annotations, chooses the cheapest admissible runtime (edition, reservation pool, etc.), executes the query, and records the outcome in the ledger.
We don’t need to invent a new language for this. The industry is already converging on Policy-as-Code; we can define these economic constraints on top of OPA (Open Policy Agent) or Rego. Long-term, this could evolve into an open spec. We could build on the FinOps FOCUS specification but extend it to cover performance objectives, not just billing data.
A contract without an executor is just a wish. We need an allocator engine to close the loop and to make declared intent actually self-enforcing.
This isn’t one monolithic system; it’s recursive. Allocators can be composed at any scale — from a single workload to an entire business unit — forming nested feedback loops of micro-FinOps operating within macro-FinOps.
In practice, each allocator’s loop mirrors any self-correcting system: Plan, Act, Prove³.
Humans stay in the loop, but as governors, not manual routers. They set policy, approve changes, and hit the kill switch when necessary.
This model creates a new policy interface. Finance defines the economic envelope (the hard financial guardrails), while engineering is empowered to declare the operational SLOs that optimize performance within that envelope.
This system can be rolled out progressively to ensure smooth operations: Advise → Shadow → Enforce → Rollback. Start in observation mode, then run side by side, then fully autonomous with guardrails.
Hyperscalers sell optionality at a premium (on-demand, autoscale) and predictability at a discount (commitments). Their margin is the spread between the two. So they’ll keep shipping assistants and recommendations — but true autonomy that collapses their spread? Not likely.
If hyperscalers won’t close the loop, their customers can.
The primitives already exist, but they’re fragmented. What’s missing is the control plane: an allocator that continuously balances cost, performance, and policy in your favor.
The allocator operationalizes FinOps. It translates declared constraints (budgets and product-led SLOs) into real-time scheduling decisions. It’s an Economic Agent — it actively negotiates the trade-off between performance and price on your behalf. Think of it as your autopilot for cloud economics: transparent, explainable, and always defeatable by a human pilot.
Imagine a company’s BigQuery analytics warehouse with a $250k monthly budget and a 2-second latency target for its BI dashboards. Halfway through the month, ad-hoc queries start saturating the committed capacity faster than expected. The allocator detects that the BI workload still has 20% latency headroom, reroutes non-critical queries to a Standard edition, and expands commit coverage to keep utilization above 90%. No humans ticket anything; finance just sees the ledger prove both latency and budget stayed within bounds.
Once allocation becomes autonomous, FinOps stops being a discipline altogether. It becomes an emergent property of systems that understand and self-regulate their own economic tradeoffs.
FinOps started as visibility and became governance. Now it needs to evolve into real control — a hands-off system that aligns engineering, finance, and vendor economics in real time.
Declare objectives, let the allocator act, and prove the outcome.
If the cloud ever delivers true “optimize to intent,” great — turn the knobs down and let it.
Until then, don’t settle for dashboards. Ship policy-driven, self-auditing automation.
Demand control, not just visibility.
Paul Grau is a product engineer at Alvin. Alvin is building hands-off FinOps, cutting BigQuery costs by 30%-70% for customers. If you’re also thinking about the next evolution of FinOps, or building something similar in your stack, let’s compare notes.
Footnotes
