At Ternary, we embrace a Software-as-a-Service (SaaS) model and leverage public cloud infrastructure to power our FinOps platform. To ensure we deliver a feature-rich and cost-effective product, we practice FinOps ourselves. In this article, we’ll explore how Ternary uses Ternary. By prioritizing FinOps, we enhance our platform and empower our engineering teams to understand how efficient their code is as we scale. This proactive approach allows us to manage costs effectively while maintaining the high quality our customers expect.
Once Ryan Heiling joined Ternary, as our Senior Director of Finance, he immediately had questions! He needed to understand metrics that are important for any SaaS company: how much revenue we are bringing in compared with how much it costs to operate the service we provide for that revenue. The two most important metrics for us are gross margin and our unit cost. Let’s start by defining these terms.
Gross margin
We choose to define gross margin as the % difference between the cost to operate (scoped only to cloud costs) and the associated revenue we receive, on a per-customer basis.
Example: If a customer licenses Ternary for $1,000 a month, and it costs $100 in cloud costs to serve that customer, then the gross margin is 90% ($100 is 10% of $1,000, then subtract 10% from 100%.) Note: These are not our real numbers.
Unit cost
A unit cost is a measurement of cost per a specified level of business output. A business output could be a customer account, a transaction event, or an amount of resources maintained for a customer. Unit costing is an extremely important FinOps concept. It allows us to understand our costs regardless of the variability inherent in the cloud. So, if business increases and cloud costs scale up or down, the unit cost should not change during that scaling event.
Example: An ecommerce company operates a website (and backend services) where customers browse items, add them to carts, and check out. Suppose the company defines a unit cost metric of “cloud cost per checkout,” or “cloud cost per $10,000 gross revenue.” The company experiences $300,000 of gross revenue in October, then $1,000,000 of gross revenue in November, due to Black Friday. If the metrics are accurate reflections of the cost of operation, the unit metric of “cloud cost per checkout” (say, $0.10) should not change between October and November, because the cloud cost and number of checkouts are increasing at the same rate.
Calculating business metrics for Ternary, with Ternary
At Ternary, our primary expense in the public cloud is our world-class data warehouse, Google BigQuery. We would not have gotten this far, this fast, without it! You can read more about how Ternary uses BigQuery here, on a joint blog that we did with Google.
We wanted to study the efficiency of our production environment by understanding the relative proportions of BigQuery usage for every customer we have. Our BigQuery jobs are tagged with a service account that is unique to each customer. So, by using Ternary’s BigQuery Usage visibility feature, we can easily export a list of BigQuery jobs performed at Ternary. We group these by the service account email running the job:
We can now see the accounts running jobs plus the total number of slot seconds (a unit of BigQuery work) each of them consumes. Next, we export this data to CSV and map the account identifiers to human-readable customer names. We calculate the percentage of the total slot hours each customer is using. Finally, we can multiply the slot hours percentage rates by the total cost of our entire production stack. (The result includes BigQuery as well as all other services we use to produce Ternary.) Here’s an example:
(Given total cloud cost = $10,000)
| Customer | Slot Hours Used (Monthly) | % of Total Slot Hours | Extrapolated Cloud Cost for Ternary to Operate |
| Strickland Propane | 1,000 | 11.1% | 11.1% x $10,000 = $1,110 |
| Dunder Mifflin | 5,300 | 58.8% | 58.8% x $10,000 = $5,890 |
| Wayne Enterprises | 2,700 | 30.0% | 30.0% x $10,000 = $3,000 |
| Total | 9,000 | 100% | $10,000 |
We can now map this data to the associated revenue from our customers to arrive at our gross margin:
| Customer | Monthly Cost for Ternary to Operate | Monthly Revenue | Gross Margin |
| Strickland Propane | $1,110 | $7,000 | 100% – ($1,100 / $7,000) = 84.1% |
| Dunder Mifflin | $5,890 | $15,000 | 100% – ($5,890 / $15,000) = 60.7% |
| Wayne Enterprises | $3,000 | $6,500 | 100% – ($3,000 / 6,500) = 53.8% |
These calculations provide our team with great insights. We can see that Wayne Enterprises and Strickland Propane are similar in terms of revenue and likely have similar amounts of cloud spend under management. But perhaps Wayne Enterprises has a more complex bill or more cloud accounts that Ternary has to connect to. That could explain why the gross margin is much less. With this awareness, our revenue team can rightsize our renewals. That way, we can properly represent how much it costs to serve each of these customers.
Unit cost to operate $1 million of spend
Gross margin is a useful metric to determine whether we are making good deals to license Ternary. We would also like to make sure that Ternary is operating efficiently over the ~$7 billion of total cloud spend that we manage. We can then consider unit cost metrics such as cloud costs per $1 million of cloud spend managed. This way, regardless of how customers come in, we are able to get a single number that represents how our cloud spend is expected to grow as the cloud spend we manage increases.
How do we calculate this unit cost on an ongoing basis? Luckily, Ternary is here to help. Our unit economics functionality allows us to define an external source of data that will provide the divisor or dividend for the normal cloud costs and usage values that come out of Ternary. We want to divide cloud cost by millions of dollars of cloud spend managed. So the external data we need to provide is the millions of dollars of cloud spend under management, over time. We created an ongoing process to populate a BigQuery table with this metric, which looks something like this:
| Date | ($) Millions Under Management |
| 2024-01-01 | 123.4 |
| 2024-01-02 | 122.5 |
| 2024-01-03 | 127.6 |
| … | … |
We save this in a table on an ongoing basis and grant access to our Ternary service account. This is the account that has access to all our other billing data. Now, Ternary will automatically pull this data as it gets updated by the other parts of our system.
Next, we head to the Ternary Reporting Engine and build a report with our Unit Reporting Metric linked to our BigQuery table. Here, we’ve already got one prepared, but it looks the same on creation:
Now that we have our SpendUnderManagement custom metric prepared, we can use it in a report.
In the report builder, we define the cloud costs that we want to divide by our unit reporting metric. That’s the net cost (e.g., cost less credits and reservations) of our primary Google billing account.
Then we move on to the Unit Econ tab, select our prepared custom metric, and apply the desired formula.
Once the report renders, we can see an interesting graph. There is a clear trend line hovering around the third horizontal axis line, and it’s slowly rising. This is reasonably good evidence that, as the amount of spend we have under management scales, our cloud spend rises somewhat linearly with it. There are also some issues we can solve—the process of loading spend under management into BigQuery doesn’t run consistently every day. That means there are some drops in the data that are also visible, but the trend line is visible despite these drops.
As we can see, this kind of calculated ratio cannot be a perfect science. There are irregularities between accounts, and growth is not linear between the services we use. There are technical migrations that result in more spend per customer dollar than usual. Those fluctuations then resolve and return to regular levels. We can always select and calculate other unit costs that show different reflections and perspectives on our platform’s scaling nature. An exciting one that we have yet to try is “cloud cost per 1 billion billing rows.” This metric would best reflect raw units of work that our platform deals with, rather than dollars of spend. For $1 million, that data could be concentrated in just a few rows or spread out across millions of rows.
Nevertheless, these unit cost numbers enable us to identify potential improvements in the efficiency of our platform. They can also help us set challenges for ourselves. For example, we can try lowering the unit cost number, rather than reducing costs by some amount or percent. That’s a common request from finance teams prior to implementing FinOps.
Finance is a critical part of FinOps
Before Ryan joined as Ternary’s finance partner, we felt strongly that we were FinOps-aware (as we should be, since we’re building a FinOps platform). Thanks to Ryan’s efforts, we have an internal feedback loop that encourages us to identify gross margin and unit costs accurately. The takeaway: Without a dedicated finance stakeholder, it’s hard for an organization to take full advantage of FinOps. Now that we have Ryan, whose job it is to think about finance, the FinOps feedback loop has become totally natural, and Ternary practices FinOps the way FinOps is meant to be practiced.
Understanding our own cloud costs, we operate that much more efficiently. That’s how Ternary uses Ternary—not just for our own business considerations but to benefit our customers and partners.
Ready to learn more? Request a demo today.