Chapter 4. The Language of FinOps

Each team within your organization likely uses discipline-specific terms, views cloud billing data from a different perspective, and has separate motivators for what they would like to achieve. This chapter discusses how you can enable teams to collaborate more effectively by educating staff on specific terms being used by each and by defining a common lexicon to encourage alignment and trust.

An early stage company typically starts with simple daily spend visibility that shows teams their respective spend. However, the common lexicon is important not only for those starting out in FinOps, but even the most well-versed FinOps practices. As your maturity in the cloud increases, the amount of terminology used in your cost reporting expands. As you continue to add capability areas in your FinOps practice, increase consumption of additional cloud services, and become more granular in your reporting, you end up with even more discipline-specific terminology. This increases the potential to use ambiguous (or duplicate) terms, which can create confusion and lack of trust in the data. Consistency becomes even more important in later stages to provide a better understanding of how all the reports relate to each other and drive accountability to the respective teams. Try to avoid using esoteric discipline-specific terms from finance or engineering and aim to agree upon a standardized lexicon.

Defining a Common Lexicon

It’s easy to highlight the need for a common lexicon: simply ask a finance team and an engineering team to each describe a service. A finance team typically thinks about the costs and rates of services while engineers will be thinking more about their service availability, reliability, and available capacity. Both are correct. The disconnect comes when these teams try to communicate with each other, which cloud forces them to do much more often than was common during the data center days. In that not-so-distant past, operations teams interacted with costs only when they proposed new equipment purchases. After that, their day-to-day job was about the efficiency and performance of their services. Finance teams, alternately, focused on what spend was committed and which budgets it should be depreciated against.

When you distribute technology buying power throughout your organization, you need to ensure all teams are using the same vocabulary for describing costs—and that you don’t overload terms to mean different things to different people. The language gets more complex when you add in cloud service provider–specific terms, and it quickly approaches incoherence as you switch between multiple cloud service providers and their vendor-specific nomenclature.

If every report you generate also needs to come with a dictionary of terms—or worse, someone has to sit down and teach a team how to read a report—that prevents the interteam collaboration at the heart of FinOps. People will refuse to give reports the time it takes to understand them, while the FinOps practitioner quickly will run out of bandwidth to keep everyone informed.

To build a common language across an organization, reports must consistently use specific terms, and teams must have learned how to correctly interpret them. While one person might understand that divided costs means the same as cost allocation, that won’t be common knowledge in the beginning of FinOps.

Where possible, it’s better to use existing language constructs instead of creating all-new terms that teams must learn. And if a cloud service provider uses terminology that doesn’t align with existing business language, it’s best to translate it before reporting out to the teams.

Defining the Basic Terms

Of course, having everyone read this book will also help build a common understanding of the terms used in FinOps. Let’s define some terms used in the industry:

Cost allocation (or cost attribution)
The process of splitting up a cloud bill and associating the costs to each cost center. Chapter 12 covers this process more thoroughly. It’s important to have teams understand how costs are being allocated, and to have a centralized, controlled, and consistent cost allocation strategy.
Wasted usage
Resource usage that isn’t actively used by an organization. If a resource is provisioned, a cloud service provider will still charge for it—even if it isn’t used.
Oversized/undersized
When a cloud resource is provisioned larger than is required, such as having too much memory or compute power, it’s considered oversized. It is worth noting that the opposite can be true as well. For undersized resources, you can increase the size if it derives more business value from additional power.
Rightsizing
Rightsizing is the act of changing the size of provisioned resources to one that better matches needs.
Workload management
The practice of ensuring that resources running in the cloud are only running at times when they are needed. It is one of the practices that allows engineers to optimize usage.
On-demand rate
The normal or base rate paid for a cloud resource. This is the public pricing for a cloud resource.
Rate reduction
Using commitment-based discounts such as Savings Plans (SPs), Reserved Instances (RIs), Committed Use Discounts (CUDs), Flexible CUDs, or commercial agreements between an organization and a cloud service provider to receive a lower rate for the resources used.
Cost avoidance
By reducing resource usage, either by removing a resource altogether or by rightsizing it, you can avoid paying for resources that would have incurred a charge. This method of reducing cloud spend will be covered in Chapter 15. Note that there will be nothing in billing data that actually tracks cost avoidance; it’s often measured as a reduction in the amount of cost for the current month’s billing cycle.
Cost savings
By reducing the rate you pay for resources, you generate savings. Unlike usage reduction where you avoid costs, cost savings are represented in your billing data. The usage is there, but you pay a lower rate for it. Usually you can track savings in billing data, either directly by monitoring credits applied to a bill or by comparing the rate paid for a resource versus the normal public price. Engineers should confirm with their finance departments the meaning of any use of the word “savings,” however, as some finance departments interpret savings as the ability to reduce budget.
Savings realized
When a saving is applied to billing data, you’re able to track the amount of savings you’ve generated in your cloud bill. By tracking realized savings against the efforts to generate and maintain them, you’re able to determine the overall effectiveness of your FinOps practices.
Savings potential
When looking at your cloud bill forecasts, you can predict the amount of savings using your existing commitments and commercial agreements. But until these savings are applied to your accounts, this is only savings potential.
Commitment-based discounts
By precommitting to a cloud service provider a set amount of resource usage using SPs, RIs, or CUDs, you receive a reduction in the rate normally paid for those resources.
Commitments unused/unutilized
For every hour you’ve committed to a resource usage that you don’t use, that reservation goes unused, or unutilized. Another term for this is reservation vacancy.
Commitment waste
Having a reservation with some amount of underutilization isn’t an issue as long as the discount you’re receiving is larger than the cost of the unused reservation. When the reservation is costing you more than what you would save—that is, it’s not utilized to an amount that saves you more than the cost of the reservation—you call this commitment waste.
Covered usage
When a resource charge is discounted by a reservation, you call it covered. The usage is being covered by the reservation, and the result is a lower rate of charge.
Coverable usage
Not all usage in the cloud is coverable with a commitment. For example, if you have resource usage that spikes during business hours and then is removed after business hours, making a commitment might result in commitment wastage and wouldn’t save money. However, it’s also possible that some overnight batch work starts as the day usage rolls off and a commitment would cover both workloads, resulting in savings for both. When covering usage with a commitment would result in savings, classify it as coverable. What is important is for a set of resources to provide enough consistent usage for a commitment to be utilized to save money, not whether a single resource runs consistently.
Unblended rates (AWS specific)
Some resources are charged in decreasing rates the more you use them. (See Chapter 16 for more on volume discounts.) This means you’re billed different rates for resources as you use more, or for longer periods during the month. By examining your bill, you can see that some resource costs are larger than others, even for the same type of resource or an identical resource. When the rates are presented this way, they’re called unblended in the AWS vernacular.
Blended rates (AWS specific)
AWS offers a blended rate in their billing data. This blended rate standardizes the rate you pay for the same type of resource by evenly distributing the charges to each resource, except when the usage is covered by commitment-based discounts. While AWS offers this blended rate in their detailed billing data, the way the costs are blended is often not perfectly even, or some resource costs are not blended because they are covered by commitments, which can lead to confusion about the true cost of a resource. There is still a specific use case for blended rates in reconciling invoices when using Cost and Usage Report (CUR) data files, but beyond this blended rates are rarely useful.
Amortized costs
Some cloud resources and commitment-based discounts can be purchased with an up-front fee. The amortized cost of a resource takes this initial payment into account and divides it out, attributing the prorated cost for each hour (or second, or millisecond) of billing. For example, a one-year all up-front commitment vehicle (SPs, RIs, or Reservations) will be split up over all the periods of time where that commitment was applied to a resource.
Fully loaded costs
Fully loaded costs are amortized, reflect the actual discounted rates a company is paying for cloud resources, equitably factor in shared costs, and are mapped to the business’s organizational structure. In essence, they show the actual costs of your cloud and what’s driving it. Your organization may choose to define fully loaded costs differently based on the discounts and cost components you wish to include. Or you may define another term to represent this in your organization’s reporting.

Defining Finance Terms for Cloud Professionals

Some terms that come from the finance discipline that are helpful for the engineers to understand include:

Matching principle
Expenses should be recorded in the period in which the value was received, not necessarily during the period the cloud provider invoiced them or when payment was made. The matching principle applies to the accrual basis of accounting and is the main difference from the cash basis of accounting. In IaaS billing, the (typically monthly) invoice you receive from the cloud provider may include up-front payments that will apply benefits—discounts—to resources over the longer (12- or 36-month) term of the commitment; most of the benefit of the up-front payment is not in this accounting period. This means you should expense spending using the billing data (e.g., Cost and Usage Reports in AWS, Azure Billing File in Azure) rather than using the invoices from the provider.
Cost of capital/WACC/ICC
Cost of capital refers to the cost to an enterprise to deploy their money toward an investment. Sometimes this is referred to as the internal cost of capital (ICC). In cloud, cost of capital is an important consideration when looking at paying up front for additional discounts on commitments like RIs. For example, if a company borrows money at 8%, then its cost of capital is 8%. That 8% becomes the bar the company needs to exceed in its return on investment. However, this 8% example is vastly simplified. In reality, most companies have a variety of sources through which they gain access to capital. Various types of debt and equity financing may bring very different rates. When doing cost of capital calculations in such a situation, companies must use a blending of those rates, called the weighted average cost of capital (WACC). Most finance teams will know what their WACC is and must consider it when making up-front RI purchases.
Cost of goods sold (COGS)

COGS measures how many dollars of outlay it takes to generate revenues in a specific period. For example, if a power company is trucking coal out of storage and into the power plant, it would record the cost of the coal burned. That cost has no future benefit, so it’s going to be an expense that is directly traceable to revenue in that period, making it a COGS expense. The test of COGS is: are they directly expensed and directly related to revenues in the same period?

Hosting costs spent on R&D may receive more favorable tax treatment than that spent on COGS, so the ability to clearly distinguish between the two is a potentially valuable capability of the FinOps effort.

Jason Rhoades, Intuit

For a software company, the COGS would be the monthly cloud bill to operate its software, salesperson commissions, and support costs. Notably, cloud is the most variable and has the most potential for optimization. Since it isn’t generally good business practice to turn down your sales commissions or fire your support people, this shines a bright spotlight on optimizing your cloud spend without reducing revenue.

EBITDA
Earnings before interest, taxes, depreciation, and amortization (EBITDA) is a widely used metric of corporate profitability. This metric also excludes expenses associated with debt by adding back interest expense and taxes to earnings. Nonetheless, it is a more precise measure of corporate performance since it is able to show earnings before the influence of accounting and financial deductions. EBITDA can be used to compare companies against each other and industry averages. EBITDA is a good measure of core profit trends because it eliminates some extraneous factors and provides a more accurate comparison between companies.

Abstraction Assists Understanding

Human beings tend to have trouble with very large and very small numbers. For instance, if something costs $1 per hour, calculating how many hours you would get for $10 is relatively simple. However, if a resource costs $0.0034 per hour, working out how many hours you would get for $10 will require a calculator. Number formatting is also important. Without formatting, 100000000 is hard to read. Most people would need to count the zeros and add commas to determine the amount it signifies.

Another human issue with large numbers is that we tend to lose our sense of scale. This can be a problem with teams working with large dollar amounts, like thousands, millions, tens of millions, or more. As Hans Rosling points out in his book Factfulness (Flatiron Books), the size instinct kicks in when humans deal with very large or very small numbers, and you need to identify ways to deal with this.

In a FinOps Foundation meeting, one of the members showed how using abstraction can assist FinOps. He strengthened his point by noting that the difference between one billion and two billion doesn’t sound like much, but it’s actually a huge change.

Many organizations with large cloud spend struggle to give their engineers meaningful metrics about spending. Imagine an organization is going to spend $100 million a year on cloud. At that scale, all humans will struggle to understand the scale of the numbers involved. And when you have trouble with scale, it becomes difficult to answer questions like these:

  • Is a $30,000 a month optimization a little or a lot?

  • How much effort is worth putting in to achieve the savings?

  • Does it really matter to the business?

  • Are there more important priorities?

Keeping a culture of accountability, so vital to a successful FinOps practice, becomes more and more difficult when the numbers get too large to relate to.

To help with context and understanding, it’s sometimes helpful to not use the common lexicon, because the specific number of dollars spent or saved may not be the key takeaway. If the impact to the business for spending or savings can be articulated using other units of measurement, the message comes across much more clearly.

For example, a FinOps Foundation member correlated the amount of cost savings to beer. If the team took a certain set of actions, he showed that they could save the equivalent of a thousand beers. In the years since the first edition of this book, that same beer metric practitioner has been able to evolve his reporting to include tangible business metrics such as requests served, revenue delivered, and customers served to their offering.

This move away from reporting only in dollars is important, because each team involved with cloud spend has a different set of motivators. Using the motivations of teams to find an appropriate example is one way to put cloud spend in a more meaningful context. For example, an up-and-coming motivator of engineering teams is the introduction of sustainability metrics like carbon emissions. See Chapter 19 for more on sustainability and FinOps.

For business leaders, seeing cloud costs tied to an important business value metric, such as a percentage of the supported product’s revenue or the output of some key activity, gives a more understandable picture of the overall efficiency of your cloud spend. An organization can then set target limits for the spend percentage and use this to drive projects to optimize using a number of techniques to reduce growth of cloud spend relative to revenue growth. Part III discusses optimization methods.

But that overall business strategy doesn’t directly relate to teams’ motivations. Engineering teams, for example, turn their efforts into functionality for users, so their motivations revolve around growing their engineering team and delivering more functionality. A FinOps Foundation member found that by reporting cloud spend in terms of the monthly cost of the engineering team, he had landed on a meaningful way to engage the engineers. When evaluating a cost-saving action, they were able to say that an optimization action might result in a specific amount of additional headcount, or they could say how quickly a cost-saving action might pay for a team’s salary.

Knowing the teams’ motivations helps you find an effective way to engage them. For service managers, reporting in alternative units like cost per daily active users (DAUs) is a good tactic. By dividing the cloud spend by the number of DAUs of their services, they can show the amount of business value those services are generating per dollar spent.

As a FinOps practice continues to mature and you start adopting unit metrics, you can associate a true cost to a business function and start to steer cost conversations to value conversations. For a transport company, your unit metric might be packages delivered, or you might start with a simpler metric like cost per request or API call. When you can equate a cloud cost to each business delivery, you can report on cost optimizations in terms of how many more shipments you can make from the savings you generate. All of this contextualizing helps create a common understanding among teams.

Cloud Language Versus Business Language

As you create reports that move away from the people operating the cloud resources, or from the FinOps team that’s operating the cost-saving programs, it makes sense to abstract away the cloud-specific terms. When you switch those terms for more generic business terms, you can summarize reports while still being accurate.

As an example, let’s look at cloud reservations for compute resources. These will be covered in more detail in Chapter 17, but generally the idea is that if you make a commitment to a cloud service provider and use those commitments effectively, you can save money. If you don’t, you lose money. AWS calls them Savings Plans or Reserved Instances, with various options saving different amounts.

If your FinOps team creates a report for themselves, they need the details on the individual commitments made. But as you start reporting up to finance and then to the business at large, the important message changes. What you focus on here is the overall success: did you save money or lose money? When you move from reporting with cloud-specific terms like commitment utilization into more generic business terms like savings realized, you create clarity.

Reducing the number of individuals that need deep cloud knowledge, especially as you move farther away from the technology toward more general business reporting and monitoring, reduces the knowledge barrier. And focusing your reports on the actual business outcome being reported continues to foster more trust, credibility, and understanding.

Creating a Universal Translator Between Your DevOps and Finance Teams

We previously referred to this using the concept of a Babel fish from the Douglas Adams masterpiece The Hitchhiker’s Guide to the Galaxy (Harmony Books). However, it was a reference that not everyone understood. Instead we are going to use a Star Trek reference to a similar idea called a Universal Translator. In Star Trek, the Universal Translator is used to interpret alien languages into the user’s native language. It’s exactly the kind of thing every FinOps team wishes they could give to finance, technical, and product teams so they could all perfectly understand one another.

For example, we’ve been in meetings where the technical team talked about the specific values they use to tag cloud resources while the finance team talked more broadly about the need for cost allocation. Both teams were describing the same thing, but there was nuance to the reporting they were reviewing, such as details of how a tag value was used to allocate costs, that prevented these two teams from understanding each other.

They could have used a translator to cut through the confusion.

But if both the finance and technical teams are clear on how FinOps practices such as cost allocation work within the organization, the conversation always starts from a common level of understanding—no universal translator needed.

Finance and engineering teams are very smart. However, you must remember that they have different practices and different terminology. FinOps should help finance teams to understand the cloud language by abstracting the cloud-specific terminology away for those who understand the dollars and cents, and they should simplify the finance requirements for the engineering teams.

FinOps practitioners build reporting and processes that reduce the need for both finance and engineering teams to spend large amounts of time learning and working outside their areas of expertise. Building those reports with consistent language enables teams to familiarize themselves with a common set of terms and then use those common reports to have conversations around the cloud benefits and costs.

You need FinOps to enable teams to communicate efficiently. Ideally, someone from the FinOps team isn’t required in the room at all. That person’s presence becomes less necessary when everyone shares a vocabulary. However, the FinOps team is always there to assist in building these reports, so that trust, understanding, and clarity will continue to grow.

The Need to Educate All the Disciplines

FinOps teams can then help collect and define the terms used by an organization that will be used to describe cloud spend and savings. Discipline-specific terms, industry terms, and variations used by different cloud service providers must be adopted, and/or adapted, into a common lexicon.

No one in finance, technology, product, procurement, or management should be expected to try to learn all the common languages of every other team. Ideally, everyone meets in the middle, where finance learns the necessary terms used to describe cloud resources, engineering learns the terms used to describe costs, and product teams learn to communicate with both. When teams learn more of the language used by other teams, the conversations lead more quickly to successful outcomes.

Benchmarking and Gamification

When common reporting built around the same language is used to measure each team’s spend and optimization, it becomes possible to compare the teams—and even create some friendly rivalry. Chapter 22 digs deeper into the metrics used to compare groups, but for now think of how being able to compare teams can lead into gamification.

For example, virtual achievement badges can be awarded for successful management of team cloud spend. Celebrating teams that perform the most optimizations, and highlighting the specific positive effect on the overall cloud spend and optimization, is a great way to engage and encourage teams.

Alternatively, having reporting that highlights the worst offenders—those who have shown a lack of optimization actions, ignored their team’s cloud spend, or were slow to respond to unexpected spend anomalies—can be effective and even fun, if done well. From our experience, teams don’t like to be listed as the worst offenders and will often put in extra effort to change their position on the list. We will look more at what we call “shameback/worst offender lists” in Chapter 11, when we get to practices that will help you reach your FinOps goals.

Conclusion

Ultimately, you use your common lexicon to build a shared understanding of your cloud costs and optimization opportunities.

To summarize:

  • Be aware that different teams use discipline-specific terms.

  • Help staff learn common vocabulary and stay consistent with the terms used in reporting, which will help eliminate confusion.

  • A FinOps team doesn’t have to be a constant translator in meetings but should assist in learning and enabling teams to communicate more and more on their own.

  • Consider adding reporting using abstracted units of measurements to communicate in ways that are more meaningful to your teams.

  • Dividing out costs and savings against some unit of business value allows you to gauge how efficient your cloud spend is.

Before you can optimize your cloud spend, you need to understand your cloud costs. We’ll take a look at the anatomy of a cloud bill in the next chapter.

Get Cloud FinOps, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial