In the beginning, companies and cloud cost management vendors focused on reducing the absolute cost of the cloud. That would be the equivalent of solely focusing on the total cost of a sales organization versus considering how much new revenue they were booking, or the productivity of the sales team or the cost of customer acquisition.
As cloud spend followed its rapid growth trajectory, curbing it most often relied on discounts. Organizations paid upfront for greater discounts or reserved a certain amount of compute usage and paid less than the on-demand price. To complement this strategy, companies eliminate the obvious waste as it does not make sense to pay for something you are not using.
In other words, companies focused on buying better in the cloud, getting as many discounts as possible.
But the upside of buying better has limits. In survey data released 2021, executives estimated that as much as 30% of their cloud spend was wasted. Given the aggregate $410.9 billion of cloud spend last year (Gartner), that’s $123.27 billion of waste!
If you’re using that much more than you should, it doesn’t matter how good a deal you get — discounts alone can’t balance out that magnitude of overspending. Moreover, buying better does not engage the people who are making the usage decisions, the engineers. This has resulted in poor engineering adoption: In a recent survey, 40% of FinOps practitioners listed low engineer engagement as their top problem.
The first generation of cloud cost management solutions focused on buying better in the cloud — carving away portions of overall spend, getting the best price, eliminating obvious waste. The next generation will focus on building better in the cloud.
What Does “Building Better” in the Cloud Mean?
Where buying better was a financial paradigm, building better is an engineering philosophy.
“Building” refers to every architecture, coding or operations decision engineers make in the process of developing a product and bringing it to market. Until recently, there has been no way to understand the real cost of these decisions, and limited pressure from elsewhere in the organization to consider it.
Buying better focuses on reactive cost-cutting. Building better focuses on building and running efficient software, using cost as a key metric to measure the efficiency.
Striving for long-term efficiency is never a bad idea, but as we enter an era where the “tech industry is bracing for a historic slump”, it’s non-negotiable.
Why Is it Better to Build Better?
Higher engineer engagement
To date, two concurrent phenomena have produced low engineer engagement:
- In an age when top-line revenue growth was the be-all, end-all for valuations, companies felt pressure to innovate at all costs, allowing engineers to spare no expense in architecting products. This created bad behaviors in many teams.
- Cloud cost management solutions targeted financial professionals, expressing their value in terms of dollars saved. Before FinOps (and still, to this day), there were CloudOps and DevOps teams who had a responsibility to manage the overall cloud cost. As a result, many companies formed Cloud Centers of Excellence to try and instigate cross-functional approaches to cost issues, but these initiatives had limited organizational support, and as a result, didn’t gain much traction.
Building better in the cloud addresses both issues. It’s fundamentally targeted at the engineers who develop software, and it equips them with the tools they need for cost-effective innovation.
By delivering information in a language that appeals both to finance and engineering professionals, building better enables strong cross-team communication, making engineers more responsive to (and accountable for) the company’s overall economic health.
Accommodates a multi-service stack
The earliest cloud cost management solutions were built for the big three cloud providers: AWS, GCP, and Azure. That’s where companies were spending the most, so from a market perspective, it made sense to build solutions that targeted those areas.
But this isn’t how a software developer thinks. They look for the best overall cloud service, typically within their primary cloud or at specialized vendors outside the big three. It is rare for a single application stack to have services from more than one of the big three. It is more common for development teams to use one as a foundation platform, then pick additional services as they move up the stack. For example:
- Data – After selecting one of the big three providers (e.g. AWS), engineers need to decide what service is best to support their data element. Maybe it’s AWS, but it could also be Snowflake, MongoDB or Databricks.
- Authentication – They then need an authentication service like Auth0.
- Management – For management tools, they might select a platform like NewRelic.
- Content Delivery – For content delivery, maybe they use CloudFlare, Fastly, etc.
As time goes on and new pressures emerge, it takes more and more services to build a credible cloud-native application. There’s also cost fallout when organizations adopt a technology like Kubernetes, which is cloud agnostic but only increases visibility challenges. Thus, a cloud cost management product that only focuses on one of the big three providers won’t be able to provide meaningful savings throughout the chain. But a well-built cloud platform will.
Unlocks cloud unit economics
Finance teams must both motivate engineers to care about cloud cost management and give them the tools to manage it autonomously. There’s no way to do both things without business context: easily understood information about the financial impact of engineering decisions.
Each specific engineering team must understand how their products, features, and architectural components correlate to use of the public cloud. To do so, organizations need a sophisticated way to organize and allocate their data, combined with telemetry around how people are using the product. (This is the central benefit of a platform like CloudZero.)
This combination allows organizations to unlock cloud unit economics: tying products and features to customer usage or consumer transactions, understanding the profitability of specific customers, and possibly revising pricing models in light of new information.
Rather than conversations focused narrowly on overall cloud spend (“You’re spending too much, you’re going over budget”) the conversation shifts to looking at cloud spend in the context of what’s happening in the business more broadly (“Our cloud costs are outpacing our user growth,” “We’re spending more than we should on our freemium features”). Vague issues cannot be addressed in meaningful ways. But specific challenges, rich with context, can.
Organizations which focus on building better in the cloud acknowledge that the public cloud is not just a part of modern business — it’s the engine. The more smoothly your engine runs, and the cleaner its fuel, the better poised you’ll be to thrive in any business climate.
CloudZero pioneered the cloud-building paradigm. Curious to see our platform in action? 
!
The Cloud Cost Playbook
The step-by-step guide to cost maturity
