The role of FinOps is to derive organizational business value from data that is “hidden” within the cloud cost, so organizations can make optimized decisions, plan resources and predict costs. Fulfilling this task is hard enough as it is, since FinOps often rely on DevOps and because they lack tools that can correlate customers, features, segments and products with costs. But when organizations operate a multi-tenant environment - achieving cost observability becomes almost impossible. Let’s see why and some practical solutions for FinOps to overcome this challenge.
Multi-Tenancy Cost Observability Challenges
In multi-tenant environments, a single instance serves multiple tenants. There are two main reasons this structure causes observability complexities.
1. Achieving Relative Slicing and Dicing per Tenant
In single-tenant environments, a dedicated resource is allocated to a specific tenant. This enables us to easily see what it costs because there is a direct correlation between the resource and the tenant. True, it’s hard to identify the cost and value of specific features or specific features, but the cost of the customer as a whole is clear and easy to calculate.
However, when multiple tenants use the same resource, various factors affect the division of resource usage between them. This includes times, types, and the number of users. Therefore, FinOps need to be able to find a way to slice and dice resources in a relative manner so they can allocate the relevant resources to the right tenant.
2. Allocating the Kubernetes Layer
Deploying on Kubernetes adds an additional logical layer of cost allocation - the pods. Organizations need to find a way to divide the costs according to the relevant pods, namespaces, and labels, and then correlate them to the correct tenants. Organizations today might be able to tell how much K8s costs them to deploy in clusters but without the ability to drill down to the pod and tenant level.
Why Do We Need to Understand K8s Costs?
As a result, FinOps and DevOps are finding it challenging to allocate costs to customers. This makes it difficult to
Multi-Tenancy Cost Observability Benefits for Organizations
When the unit and customer cost are calculated, a whole new world is revealed to FinOps, who can derive real business value from this granular level of information.
They can understand how to:
Price the product - based on the price it costs to host customers similar to existing ones, even for usage-based pricing
Leverage hosting cost at their next renewal point
Plan a budget based on the sales forecast
Align finance & R&D with the same KPIs of cost per customer, feature, segment, and product, instead of the total cost
Prioritize features base on their profitability rate
Market to more profitable customer segments
and much more
How to Achieve Multi-Tenancy Cost Observability
The benefits from calculating these costs have led many organizations to attempt to develop homegrown solutions for cost allocation. How should such a solution be designed?
1. Think of your physical cost and Kubernetes logical cost as a blank coloring book.
2. “Color” each business use case with a different color.
3. Match the colors to your KPIs. That’s your unit metric.
Identify that a certain S3 bucket, K8S namespace, three instances, and a certain RDS are being used by a specific product.
Color them in the blue (or green or yellow or pink)
Find that the product is being measured by ‘purchases per minute’ KPI
The unit metric is ‘cost per purchase per minute’
Measuring the unit metric price for each business use case can bring FinOps really close to understanding their cost per customer. All they need to do is multiply the unit cost by the number of units each customer used - and they have a pretty good estimation of their real cost.
If all of that sounds hard to create and maintain, Finout is here to help. Reach out to us to join our private beta and get observability into your cloud cost. By using Finout, you can attribute each dollar to its rightful place and understand your cloud and Kubernetes costs. Start today.