Chapter 4. The Language of FinOps and Cloud
Successful FinOps involves teams from multiple parts of the business collaborating. Each team within your organization uses domain-specific terms, views cloud costs from a different perspective, and has separate motivators for what they would like to achieve. In this chapter, we discuss how you can enable teams to collaborate effectively by educating staff both on specific terms being used and on methods for avoiding confusing language in order to get a point across.
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 uses terms like usage, rates, costs, and possibly utilization. Engineers, on the other hand, refer to 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 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, asked procurement what spend was committed and which budgets it should be depreciated against.
When you distribute the purchase approvals 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. The language gets more complex when we add in cloud service provider–specific terms, and it quickly approaches incoherence as we 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
-
The process of splitting up a cloud bill and associating the costs to each cost center. We’ll look more closely at this process in Chapter 9. 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.
- Rightsizing
-
When a cloud resource is provisioned larger than is required, such as having too much memory or compute power, it’s considered oversized. Rightsizing is the act of changing the size of provisioned resources to one that better matches needs.
- 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 Reserved Instances (RIs), Committed Use Discounts (CUDs), or commercial agreements between an organization and a cloud service provider in order 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 11. 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.
- 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.
- Reservations/commitments
-
By precommitting to a cloud service provider a set amount of resource usage using RIs or CUDs, you receive a reduction in the rate normally paid for those resources.
- Reservations 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.
- Reservation 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 reservation 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 reservation. If you have resource usage that spikes during business hours and then is removed after business hours, committing to a reservation would result in reservation wastage and wouldn’t save money. When usage would result in savings by being covered with a reservation, classify it as coverable.
- Unblended rates
-
Some resources are charged in decreasing rates the more you use them. (We’ll cover volume discounts and sustained use discounts in Part III of the book.) 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.
- Blended rates
-
Some cloud service providers offer 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. While some cloud service providers offer a blended rate in their detailed billing data, often the way the costs are blended is not perfectly even, or some resource costs are not blended, which can lead to confusion about the true cost of a resource.
- Amortized costs
-
Some cloud resources and reservations come with an upfront fee. The amortized cost of a resource takes this initial payment into account and divides it out, attributing the prorated cost for each hour of billing.
- 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.
Defining Finance Terms for Cloud Professionals
- 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, this means you should expense spending using the billing data (e.g., Cost and Usage Reports in AWS, Cloud Billing Reports in GCP, Azure Billing File in Azure) rather than using the invoices from the provider.
- Capitalized expense (CapEx) versus operational expense (OpEx)
-
When you capitalize something, it becomes an asset of the company, whether or not it gets expensed within a specific period. The test you can apply is: if an organization writes a check to acquire something, does that acquisition benefit future periods? If it does, then it can be capitalized. If it benefits only the current period, then it’s an expense that is expended in this period with no future benefit, making it an operational expense. Capitalization causes total outlays to differ from expenses in a similar period, with the delta being that which is capitalized.
- Cost of capital/WACC
-
Cost of capital refers to the cost to an enterprise to deploy their money toward an investment. In cloud, cost of capital is an important consideration when looking at 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 RI purchases.
- Cost of goods sold (COGS)
-
COGS measures how many dollars of outlay it takes to generate revenues in a specific period. 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?
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. You can’t usually materially turn down your sales commissions or fire your support people, which shines a bright spotlight on optimizing your cloud spend without reducing revenue.
- When COGS can become capitalized assets
-
There’s a potential curveball when it comes to how expenses are used. Let’s say a power company takes some of its coal and uses it to make diamonds. If it burned coal to generate power that was sold for revenue, the company accounts for the cost of the coal as COGS. But if it creates diamonds out of the coal, and those diamonds aren’t sold in the period but instead are put into storage as inventory for future periods, the cost of the coal would then be capitalized as an asset. However, as soon as those diamonds are sold, then the cost of the coal switches back to COGS during the period of the sale.
- How do COGS and capitalization come together in cloud?
-
We recently saw a UK retailer that was developing a new shopping platform product and was applying these principles in an interesting way.
The company accounted for the EC2 hours used during the generation of the product as a capitalized asset that wasn’t expensed in the period. It was able to do this because the product in development wasn’t generating any revenue. The retailer was using EC2 hours to create an asset that would generate revenue in future periods, much like the power company creating diamonds from coal rather than burning it for power.
Once that shopping product went live, the capitalized EC2 costs began to be amortized into the relevant periods in which the product began to generate revenue. Note that the shopping platform product is not a physical asset, so it was amortized and not depreciated.
In cloud, it’s common for RIs to be amortized into the period in which they are used over a one- or three-year period.
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 we would get for $10 is relatively simple. However, if a resource costs $0.0034 per hour, working out how many hours we 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.
In a FinOps Foundation meeting, one of our 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.
We’ve discovered that 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 in 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 it worth putting in to achieve the savings?
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 go against the common lexicon. Sometimes the specific number of dollars spent or saved isn’t 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.
That same FinOps Foundation member correlated the amount of cost savings to cases of beer. If the team took a certain set of actions, they found they could save the equivalent of tens of thousands of beers. It may not surprise anyone that using beer as a unit of measurement was more clearly understood by engineers than raw dollar values.
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 business leaders, seeing cloud costs as a percentage of the company’s total revenue gives a complete 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. We’ll cover optimization methods in Part III of this book.
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. For a transport company, your unit metric might be packages delivered, or you might start with a simpler metric like percentage of revenue spent on cloud. 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 server instances. We’ll cover these in more detail in Chapter 13, but generally the idea is that if you make a commitment to a cloud service provider and use those reservations effectively, you can save money. If you don’t, you lose money. AWS calls its offering Reserved Instances, with each size server saving a different amount.
If your FinOps team creates a report for themselves, they need the details on the individual reservations made. But as you start reporting up to finance and then onto 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 RI 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 further 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 Babel Fish Between Your DevOps and Finance Teams
We’ve been in meetings where an operations 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 would have needed a translator—or the aforementioned fish—to cut through the confusion.
But if both the finance and operations 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 fish 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 Both Sides of the House
As noted, a FinOps team should help define the terms used by an organization to describe cloud spend and savings. Both industry-standard terms and variations used by different cloud service providers must be adopted, and/or adapted, into the common lexicon.
No one in finance or operations should be expected to try to learn all the common language of the other team. Ideally, everyone meets in the middle, where finance learns the necessary terms used to describe cloud resources and operations learns the terms used to describe costs. 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. We’ll dig deeper into the metrics used to compare groups in Chapter 16, but for now think of how being able to compare teams can lead into gamification.
For example, badges can be awarded for successful management of team cloud spend. Awarding 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” when we get to practices that help us reach our 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 domain-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.
-
Moving away from reporting only in terms of dollars and cents to abstracted units of measurements will allow you to build reports 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 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.
