Cost allocation 101: building the foundations
There will be a lot of diagrams in this series, because there are so many steps in this overall pipeline that it's impossible for me to understand them all without being able to visualize the flow between them. For the most part each post in this series will focus on 1 major step in the cost allocation pipeline. Let's start with the very highest level conceptual overview of the job.
Company overview
My employer is a B2B and B2C product company. We are a midsized company of about 300 employees and we have customers. We don't have internal business units to which we chargeback cloud hosting, rather our customers run their (typically web-facing) workloads on our platform and we handle the infrastructure for them. They never see the underlying cloud bill, and are free to totally ignore which cloud vendor is actually hosting their workloads.
Product line overview
We only have one primary product as far as our customers are concerned, and the base sellable Thing that we sell is called A Project. A Project has a 1:1 relationship with a Git repo, and we operate a platform that handles your DevOps needs for you, i.e. - you git push to us and we handle it from there.
Internally, we have two main COGS centers. The main COGS center by mindshare is the containerized hosting platform, what we refer to internally as "the grid". I like to imagine it in Jeff Bridges' voice. One of the marquee features of the platform is that any Git branch you create in your project will instantly create a new hosting environment for that branch, complete with data cloned from the parent branch and all supporting infrastructure already wired together. This means that containers come and go as Git branches come and go, and we'll account for this in our cost allocation.
The other main COGS center is simply called "dedicated". Dedicated is for customers that want significant resource guarantees for their production workloads. These dedicated "environments" are just another "deployment target" as far as our platform is concerned - a child of a Project. A project can look like this:
First problem - container allocation
Dedicated resources show up in the cloud bill and if properly tagged can be tied directly back to a project and therefore a customer. Containerized resources cannot. Any FinOps practitioner who's dealt with Kubernetes knows this problem - containers are an abstraction. Additionally, a given container can live for 5 minutes or 5 years. It can also move across hosts during the day. We'll go deep on the nuances of container allocation in this series, because there's a lot here.
Second problem - shared costs
Between the containerized segment and the dedicated segment, that accounts for 75-80% of our total hosting costs that are able to be directly tied in some fashion to a customer's workload. The remaining 20+% is shared infra, R&D, and frankly some of it is god-only-knows but it has to be accounted for. We'll go into how we spread these costs.
Third problem - credits from cloud providers, or The January Problem
This is completely hypothetical of course, but picture an alternate dimension where you have a contract with an imaginary cloud provider and that contract includes some yearly credits back to your account as part of your incentives. These credits might land all at once on an annual basis, and might materially discount the cash basis cost of your bill for the month in which they land.
This will make that month appear noticeably cheap in comparison to its temporal siblings on either side of it, and so all your cost allocation work will be operating on data that some might consider artificially depressed. We'll need to account for this and amortize these credits via some schedule, which your bill might not do for you.
Zeroth problem - multi cloud
The above are real cost allocation problems, and none of them can be solved before solving this one: we have multiple bills from multiple cloud providers. We host essentially identical workloads on AWS, Azure, and GCP because reasons. Some of those bills are in USD, some are in Euro. They all use different terminology and names for their VMs, their object storage, their network disk or block storage. We have to normalize these bills together to do anything, and for this we're going to look to the FOCUS project for guidance.
FOCUS makes this entire thing possible in the first place, since any meaningful analysis or allocation has to gather all the costs together in 1 dataset to get started. This is where we'll start in the next post - building out your unified FOCUS dataset.
