Cloud Spend Podcast Episodes

When developers deploy resources, there is little to no insight for them to understand how much a resource is going to cost.

Infracost is changing this by shifting the cost component of cloud resources "left"—i.e. into the hands of developers in a new approach to FinOps.

The existing paradigm of cloud financial management and the traditional FinOps way of managing cloud spend mean waiting for the cloud bill to arrive, then trying to identify opportunities for cost savings.

First-generation FinOps companies like Flexera, Cloudability, and CloudHealth emerged around 2011. They provided an improved user interface for complex billing data, and followed the monthly billing cycle of cloud providers.

However, a month is not sufficient with today's automated and dynamic cloud environments driven by infrastructure–as-code. A new generation of tools have shortened cycles, and delays between cloud bills and their analysis has come down to a day or less.

In broad terms, efforts to lower the cloud bill are based on a simple formula:

$$cost = usage \times price$$

Existing approaches mostly focus on the "price" component of the equation. Procurement mechanisms to lower the price point of a cloud resource include reserved instances, enterprise discount programs, savings plans, etc. Finance "slices and dices" the cloud bill after resources have been deployed to optimize price points and the overall size of the cloud bill.

However, the procurement-driven approach doesn't account for the "usage" component of the equation, which is a function of developer activity. Finance lacks the context that developers have when deploying resources, while developers lack visibility into resource prices and the cost of their deployments.

Infracost is closing this gap by providing cloud cost estimates for Terraform in pull requests to show engineering teams how code changes affect their cloud bills. Infracost adds comments to pull requests (e.g., "this change will increase your cloud bill by 25%") which are visible to engineering management, FinOps, and product teams.

Hassan Khajeh-Hosseini is Co-Founder and CEO at Infracost, which he co-founded with his brother Ali Khajeh-Hosseini and their friend Alistair Scott. The founding team has a decade of cloud cost history together, with two previous cloud cost start-ups founded and exited.

In this episode, Hassan walks us through the science and engineering behind building Infracost. We also discuss broader infrastructure trends, including "cloud financial engineering" and the general "shift left" of testing, security, and (of course) cost in the development process.

ITAM is an established category in the IT market, with its own Gartner Magic Quadrant.

Gartner defines ITAM as "[providing] an accurate account of technology asset lifecycle costs and risks to maximize the business value of technology strategy, architecture, funding, contractual and sourcing decisions." ITAM is usually divided into two subcategories, SAM and HAM.

With cloud computing and SaaS tools, the requirements for ITAM have changed.

In the old world of IT, there was tight control over who could purchase servers and software licenses. IT was a (literal) gatekeeper that determined who could push a new server into a rack and provision that server with software.

That control is gone in today's world, where developers and employees have the flexibility to swipe a credit card or push a button in a console to "procure" cloud resources and software.

There are, of course, benefits of giving employees flexibility—namely, "development velocity", the speed to build and launch new products.

A challenge remains to optimize the value of these infrastructure expenditures, however, which means balancing "development velocity" and "business velocity." Without balance, the result is tool and infrastructure sprawl, as well as out-of-control spending. Decentralized procurement may sound great on paper, but usually leads to the "worst best deal."

Balancing business with development velocity is Amit Mizrahi's job as Head of Strategic Operations at Wix.

Wix's flagship product is their free website builder, around which they've also built a portfolio of e-commerce products. The Wix company mantra is "to measure everything," and Amit's work includes measuring the ROI on Wix's IT assets—a tall order when Wix's employees number nearly 6,000.

In this episode, Amit walks us through how he built an ITAM program at Wix from scratch. The ITAM program is part of the "Value & Impact Center of Excellence at Wix," which has two pillars:

1. ITAM: Managing procurement and operations for everything related to SaaS products and tools within Wix.

2. FinOps: An organizational function that is in charge of monitoring cloud activities, governing cloud spending, and educating teams on financial-driven KPIs. (See Episode 5: Shifting From FinOps to Financial Engineering.)

To understand the business value of tools, Amit and his team built an internal data integration and analytics layer that extracts usage data from all tooling—an abstraction across Wix's IT assets. This abstraction layer is coupled with procurement processes that create alignment between development and business velocity for Wix.

There is a new generation of companies that are building their applications 100% cloud-native, with a pure serverless paradigm. One such company is Ekonoo, a French FinTech startup that enables customers and organizations to efficiently invest in retirement funds.

Jonathan Bernales is a DevOps Engineer at Ekonoo. In this interview, Jonathan walks us through Ekonoo's approach of giving developers the autonomy to build and deploy code along with the responsibility for security and cost.

Holding developers responsible for security and cost is a rather new part of "shift-left." Cost awareness becomes part of the development culture. To keep cloud bills under control, Ekonoo developers are responsible for their individual test accounts and have access to the AWS Billing Console and AWS Cost Explorer.

At Ekonoo, there is no dedicated "production team." Rather, DevOps collaborates with developers to create guidelines and guardrails for architecture, automation, security, and cost. The entire Ekonoo stack runs on AWS using native AWS services such as CloudFormation, Lambda, and Step Functions.

Watch this episode to learn about Ekonoo's transition to a microservices architecture and the lessons learned along the way.

Dvir Mizrahi is Head of Financial Engineering at Wix, the leader in website creation with 220 million users running e-commerce operations. And with over six thousand employees, Wix ships more than fifty thousand builds each day.

Dvir is also among the original authors of the AWS Cloud Financial Management certification.

In this episode, Dvir covers how Wix shifted from FinOps to Financial Engineering. It's an engineering-first approach to build tooling and processes tracking financial key performance indicators (KPIs) for its multi-cloud infrastructure. The new approach established a culture of financial responsibility that supports Wix's continued growth.

Wix started in 2006 and initially ran its infrastructure on-premise. Today, Wix runs a multi-cloud environment on Google Cloud and Amazon Web Services (AWS). As Wix shifted from on-premise to the cloud, the procurement process of resources changed with it.

In the old world, purchasing additional hardware was a closed and controlled process. But in the cloud, Dvir compares resource procurement to "a supermarket where people can go in, take whatever they want, and leave without passing the registers." A developer could spin up a hundred thousand instances with just the click of a button.

Wix realized the financial risk that comes with liberal permissions to spin up infrastructure and hired Dvir in 2017. FinOps approaches infrastructure governance from a billing perspective and handles workloads already provisioned in the cloud. But at Wix's scale, where there are thousands of engineers, the FinOps approach stops working. "By the time you have a financial incident, it's too late and you didn't govern anything."

Dvir shifted the strategy to proactively preventing waste in the first place, by incorporating financial KPIs into engineering goals. In addition, Dvir built an internal platform called "InfraGod" which collects infrastructure data, integrates with Terraform, and enforces rules at the time of resource provisioning. Taking action at the time resources are provisioned rather than after the fact is "the difference between Finance and Financial Engineering."

Listen to this episode for a deep dive into the tactics that Dvir uses to run Financial Engineering at Wix, such as data collection, engineering post-mortems, monthly reports, and mandatory resource tagging.

Companies build in the cloud for growth and speed. 📈

Engineering teams love building new things—so much so that cloud spend commonly becomes a major part of a company's profit and loss statement (P&L).

Cloud vendors have introduced pricing and discounting schemes to incentivize increased consumption and lock in long-term commitments from customers. Management gets involved at this point, but they often lack context and understanding of how cloud procurement works.

Forecasting cloud spend and aligning growth with infrastructure efficiency become important capabilities when you are about to sign a multi-million three-year contract with a cloud vendor. 💰

In this episode, Lars talks with Dieter Matzion, Senior Cloud Governance Engineer at Roku and long-time expert in cloud procurement and cloud financial operations. Before joining Roku, Dieter was an engineer at Google, Netflix, and Intuit, where he established infrastructure efficiency programs that combined cloud operations, analytics, and finance.