The Critical Gap in Cloud Cost Governance
The financial reality of cloud adoption continues to present a stark challenge. Organizations estimate that 28% of their cloud spend is wasted, yet a shocking lack of maturity in financial discipline persists, with only 22% reporting a mature cloud cost management strategy. In my interview with Mike Julian, CEO and co-founder of Duckbill, a firm specializing in cloud financial management, Mike argues that the current approach to FinOps is flawed. The speed and innovation inherent in AppDev workflows are accelerating cloud consumption without the necessary cost governance, leaving finance and engineering teams in reactive, siloed positions. To close this gap, FinOps must move from a “backseat equation” to a “front-and-center” part of application architecture and planning.
Redefining ‘Wasted Spend’
Julian contends that the 28% figure for wasted cloud spend is not only an underestimate but also based on a misunderstanding of where the true waste lies. The biggest negative for customers is focusing on superficial, tactical wins, which he refers to as a “micro-optimization trap.”
“They think like, well, I should turn off staging overnight because that’s wasting money. Yeah, maybe, but like how much? And every time that exact scenario has come up, the answer is pennies compared to the rest of the bill.”
These “small wins,” like resource right-sizing or scheduling non-production environments to shut down overnight, are finite and yield diminishing returns. They are the easiest things to fix and therefore get the most attention, but they do not fundamentally change the cost structure.
The real driver of enduring cost is the production architecture. Julian stresses that the core question driving cost optimization should be: “How did you build the thing you built? Why did you build it that way?” Architectural choices like the selection of databases, the approach to networking, or the decision to use complex services like Kafka create the structural costs that cannot be solved by a simple on/off switch.
“What if you re-architected? What if you did more than turn stuff off? What if you rethought how you built what you have? That line is actually potentially much lower.”
This fundamentally re-frames cost management as an engineering-driven problem. Engineering teams, by virtue of designing the architecture, are the only ones who can truly drive lasting, structural cost change.
The Innovation-Efficiency Continuum
The push for financial discipline often creates friction because engineers are driven to ship features, while finance is driven to cut costs. There’s tension between balancing developer autonomy with financial governance and organizations tasked with innovation often spin up resources without worrying about financial impact.
Julian challenges the notion that these two forces must be in constant, equal balance. Instead, he proposes a model of an Innovation-Efficiency Continuum:
- Innovation is intentionally expensive. When a team is innovating, creating something brand new, overhauling infrastructure, or running a large experiment, they must accept that they will be wasteful. Efficiency is a “stranglehold” on true innovation.
- Efficiency is for maturity. Once a product is running, and its behavior and usage patterns are known, the dial can be turned back toward efficiency to optimize the workload.
The key is to be intentional about your position. An organization should consciously decide where on the continuum a project needs to be, understanding that the resource consumption will reflect that choice. This allows for necessary waste during high-growth periods and mandates optimization when stability is the priority.
Shifting Cost Left
Adopting this intentional, architecture-first approach requires operationalizing cost accountability directly into the workflow; a form of “Shift Left” for FinOps.
Julian warns against the common mistake of reaching for a tool as the first solution. This aligns with our research which shows that over 75% of organizations use six to fifteen different tools in their CI/CD pipeline, often increasing complexity.
Instead, the focus should be on process and planning:
- Architectural Reviews: Treat the architecture plan with the same rigor as a code review. Teams should ask: “Here’s how we think the cost is going to behave.”
- Test Financial Behavior: Directly testing and validating those cost assumptions is crucial. Teams are often surprised by “family costs” such as data transfer and network egress, which are not captured in the initial core resource plan. Testing the plan reveals these hidden cost drivers before the architecture is deployed.
By embedding cost planning and validation into the design stage, FinOps becomes an active partner to innovation, ensuring that resources are provisioned with cost-awareness, governance, and long-term architectural efficiency in mind. The conversation, therefore, shifts from what did we waste to how efficiently did we architect.
Conclusion and Next Steps
To get started on this journey, it’s advised that organizations stop chasing tools, start by simply looking at your bill, and asking questions about the cost drivers. For community and further education, the FinOps Foundation Community is an excellent starting point. The goal is to move beyond tactical resource management and fully embrace cost-aware architecture as the future of secure and sustainable application development.
