Our Working Group would like to introduce the results of our first sprint: the start of a practical guide about cloud unit economics. Our mission with this project is to create common ground, identify standards, and build a better understanding of what cloud unit economics are and how they can be leveraged by your organizations as part of a greater FinOps strategy.
Our WG gathered to collect information and create the overall outline and fill out sections about cloud unit economics. The group scoped the following concepts and sections of the guide:
While the guide is a work in progress by group members, finished sections will be published on this WG output project.
Our WG also conducted a survey to supplement the definitions and best practices that we’re generating with real world data. We’ll reveal the results of the survey during a future sprint.
The results of our first sprint also brought some interesting discoveries, definitions, and insights to help our community improve the Measuring Unit Costs Capability. In future sprints, we’ll work with the Technical Advisory Council and FinOps Foundation staff to see how we can incorporate what we’ve learned to improve the Capability definition and supporting content.
The cloud’s ability to scale resources up and down to align with current demand requirements, often referred to as elasticity, is simultaneously both one of the key benefits of cloud computing and its greatest liability.
This elasticity and the cloud’s inherent variable cost structures (that made the emergence of FinOps inevitable) have created new financial and operational challenges that require the creation of systems and processes to measure the variable costs and usage metrics associated with these dynamic infrastructure changes.
This document focuses on the system of Cloud Unit Economics as one such system, which is the specific application of the broader concept of unit economics to the cloud computing domain. Below you will find an introduction to its practical application and a methodology to quantify the associated cost and usage metrics of elasticity.
This document also covers how the application of unit economics can enable cloud-driven organizations to build more efficient systems and ultimately provide a common language to align both business and engineering leaders.
“One of the most important concepts in FinOps is unit economics”
- Chapter 1: What is FinOps, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
The FinOps Foundation define six principles that serve as guidance for the FinOps professional. Why do they specifically call out unit economics? What makes it such an important concept?
In short, because Cloud Unit Economics directly supports each principle. Just like the FinOps practice as a whole, Cloud Unit Economics is not a goal in and of itself, but rather a powerful system for achieving the maximum return on your cloud investment in pursuit of the six principles of FinOps.
Cloud Unit Economics is a system of profit maximization based on objective measurements of how well your organization is performing against not only its FinOps goals but as a business in the market. Cloud Unit Economics achieves these noble goals by leveraging the measurement of marginal cost (a.k.a., unit cost metrics) specific to the development and delivery of cloud-based software and marginal revenue (a.k.a., unit revenue metrics).
By calculating the difference between marginal cost and marginal revenue, you can determine where your cloud operations break even and begin to generate a profit — an important concept in economics overall and one of the most effective ways to make data-driven business decisions regarding your cloud investment.
This document was written mostly with commercial SaaS and cloud-driven commercial organizations in mind. But, Cloud Unit Economics can be applied to other types of organizations. While most companies measure their success in revenue or profit, a public sector organization (e.g., federal, state, or local government) or nonprofit does not. Instead, value is typically measured in terms of the success (or failure) of the delivery of civic goods or services.
In addition, the value may be derived through the accurate forecasting of overall spending to maximize the use of budgeted resources. If you want to apply unit economics to a non-profit or a public sector entity, simply replace the words profit or revenue with value.
Cloud unit economics can unlock the following benefits:
Quantify the cloud’s role in your financial performance. Cloud Unit Economics is an effective tool for a company’s management, investors, and employees to understand its financial performance.
Forecast profitability. Based on a unit cost analysis, unit economics shows how profitable a business is or how soon it will achieve profitability, and what factors are affecting its margins.
Build a plan for cloud cost optimization. Cloud Unit Economics allows companies to understand whether their product is overpriced or undervalued. This can help them identify what should be optimized, and how.
Evaluate a product’s future potential. Relying on Cloud Unit Economics, businesses can better understand what products and features customers are using, making it easier to make changes to product roadmap and engineering priorities.
Ultimately, by quantifying the cost to produce or the cost to serve, cloud engineers can articulate their contribution to gross profit margin due to the architectural, development, and operating choices they make. Product teams will have key data points to support pricing decisions, and the business will be able to forecast cloud costs better even though cloud resource consumption is variable.
Cloud Unit Economics also supports a broader set of metrics used to evaluate the profitability of products and customers. These include:
One of the goals of this document is to help you learn how you might put Cloud Unit Economics to work for your organization. One of the most important details to determine upfront as part of your Cloud Unit Economics journey is what key metric best serves your business needs.
Consider using the following examples to kick start that journey and to give you a taste of what is possible:
Cloud Unit Economics is a universally useful system, but there’s no one-size-fits-all approach to metrics. The right metrics are a product of what you do, who you serve, how big you are, and any other defining factors about your business.
Use this glossary of helpful terms to define better and understand the domain of Cloud Unit Economics.
Cloud Unit Economics is a key way to communicate both the cost and the value of everything an organization is doing in the cloud. As such, it depends on key interactions across all other FinOps domains.
Unit Economics: A system of profit maximization based on assessing the impact of incremental costs relative to incremental revenue. The revenues and costs associated with a defined and measurable unit of a product or service. FinOps teams today strive to provide actionable unit costs to enable organizations to calculate unit economics for the products or services utilizing cloud services.
In manufacturing, marginal economics help businesses optimize production levels and maximize profits. In the cloud, marginal economics helps us understand if engineering changes to products or services via changes to the architecture, development patterns, or cloud operations are delivering incremental business value.
Unit Cost: The cost allocated to a defined and measurable incremental unit of a product or service is one of the more important concepts in unit economics. Unit cost is also sometimes referred to as the marginal cost specific to the development and delivery of cloud-based software or services.
Unit Metrics: KPIs used in unit economics that indicate business value, technical value, or other important measurements.
Activity Based Costing: A process establishing direct costs associated with specific tasks that can then be attributed to products and services based on demand. The tasks are staff-related (time required to perform task x hourly rate) but can also be related to machine time. Also referred to as Task Oriented Costing.
Cost to Produce: This is the total cost to produce for non-production workloads and is used as a measurement with other business metrics similar to how you would use the cost to serve. These metrics can be compared to similar tech stacks and non-production workloads to determine the efficiency of teams and cost controls.
Note: This activity should not be confused with something akin to a tax write-off with Research & Development.
Contribution Margin: This is usually revenue minus variable cost. Can be performed at the unit or aggregate level, with the latter indicating the amount available to support the company’s shared costs. Typically applied at the product level, but can be applied to any dimension — e.g.: market, industry, etc..
Cost to serve: Cost to serve kicks in once the application has been promoted to production and production begins.
Direct cost: Costs — variable or fixed — that can be identified and attributed to a specific resource or group of resources that support the delivery of products or services to an internal or external customer.
Indirect cost: An allocation of a general business expense that is not readily identifiable but necessary for the general operations of the organization.
Shared cost: Identifiable costs allocated to a pool of products or services through an agreed-upon distribution methodology.
Demand driver: A factor that has material influence over cloud resource usage.
Cost attribution vs. cost allocation: Attribution is based on cost causative principles while allocation is generally arbitrary — i.e., we could allocate costs and end up with different answers.
Measuring Unit Economics for Cloud IT is as important as it is complex. Complexity stems from many sources: variable cost models, shared resources, on-demand provisioning, and so on. The organization needs to track how much cloud usage vs. cloud spend is profitable and sustainable.
More to come in a future sprint…
Cloud Unit Economics provides a common language for all levels of the organization so stakeholders can discuss cloud spending in a meaningful way. A goal for Cloud Unit Economics is to relate cost/spend to business value. Organizations that are cloud dependent Cloud Unit Economics metrics as primary metrics for business decisions.
More to come in a future sprint…
Building a sustainable Cloud Unit Economics practice starts with a strong unit cost model. Seek out people in your organization who are already thinking about or doing it at some level.
Planning should start as early as possible to identify the metric or metrics needed to collect meaningful data. This may give direction to engineering teams on the necessary data points to be collected later. Collecting and processing the data should happen as customers start onboarding a system.
In the beginning, the most important thing is to get started! With your first unit cost metric identified and the data necessary to calculate it flowing, be prepared to learn a few new things about your system and its use. Preparing the data and sharing those insights can be a powerful way to build support and encourage your organization to more broadly incorporate unit cost metrics into your cloud operations.
With your first metric under your belt, use the Cloud Unit Economics maturity model as a guide to planning your next steps and achieving more impactful use and adoption.
The path you take will ultimately be dependent on the architecture of your organization. During the crawl phase of adopting Cloud Unit Economics, it is best to start with metrics that can be supported by existing data sources such as logs, data warehouses, or APM platforms.
Cost per-customer (or cost-per-tenant) is a common goal that can typically be applied to most organizations and is often a good metric to start with. Using the maturity model as a guide, you could achieve cost-per-customer using the following process:
Depending on the complexity of the application, this may also be done in multiple phases, where some cloud costs are handled initially as “direct” and others “shared.”
This could include things like Datadog, ServiceNow, or PagerDuty. Once you start bringing in SaaS tools, you may need to work with the team responsible for that product to understand the KPIs they care about and how they quantify time spent. Using ServiceNow as an example, the support team may be tracking usage based on the number of comments instead of the number of tickets. Or placing different SLAs on different types of tickets.
Depending on the organization and emphasis on professional services, this may be an earlier phase. This is bringing in costs like technical support or account management.
The run phase is typically when a firm starts collecting more than one metric for various parts of a complex system getting more granular over time.
In other situations, engineering might play a more central role in your FinOps organization, and you can leverage engineering time to produce the necessary metrics. This might be where organizations start their journey, or it might be where you ultimately end up. Regardless of the resources you have at your disposal, start small and focus on clear metrics that will be tangible to all stakeholders.
Through all of this, the centralized function of FinOps should be apparent: the FinOps team should be responsible for maintaining the Cloud Unit Metrics repository and be capable of clearly articulating their business value. Without it, a company can end up with “one metric to rule them all” or a bunch of clashing metrics.
Unit Economics typically will fall into several categories that follow FinOps personas. If you aren’t familiar with FinOps personas involved with building and operating your practice, catch up on the personas page.
|Executives||Product Owner||Engineering and Operations||Finance/Procurement||FinOps|
|INPUT||A CTO/ CIO / CFO should own the initiative of Unit Economics and determine scope as it relates to coverage of Products||VP of Product / Product Owners should collaborate with Finance to determine key product metrics||VP Engineer collaborate with Product Owners define input requirements for metrics to best determine how to collect metric data from systems||Finance should collaborates with Product Owners to determine key product metrics||FinOps should be aware of executive scope and identify gaps in cost allocation alignment to strategy|
|OUTPUT||Actioning on business decisions as a result of cost metric data||Define frequency of reviewing unit cost and determine benchmark thresholds||Support solutioning automation and identify blockers to outputting metrics||Actioning on business decisions as a result of cost metric data||Integrate cost allocation with cost metrics|
NOTE: This table is best viewed on a wide viewport, like a desktop or tablet.
More to come in a future sprint…
More to come in a future sprint…
There are many more stories to tell. If you have your own perspectives on tackling this challenge or topic, submit your story to our WG, or contribute to the FinOps Framework GitHub repo.
See our contribution guidelines for more details.
The FinOps Foundation extends a huge thank you to the members of this Working Group that broke ground on this documentation: