The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Last reviewed: 2023-01-03
Provide actionable insights to multiple stakeholders and broaden awareness of the cloud cost of GitLab's SaaS platforms, driving operational efficiencies and reliable cost projections.
Adoption of GitLab's SaaS services is growing, and with it, the cost to provide those services.
As a result, it is becoming more important that GitLab is able to:
We will accomplish this by:
There are four primary personas whom we are trying to serve:
In order to support our goals of splitting cloud spend by tier and category, we need to combine data from multiple sources. This is because no single location has all of the information we need:
Our cloud infrastructure is shared across product tiers, and in some cases product categories. For example our rails nodes serve as the compute for a wide range of features, along with our database nodes. Even when we have infrastructure specific to a feature, for example our gitaly or registry nodes, they are shared across all product tiers. This means the billing data from our cloud providers cannot by itself provide the insights we need.
To solve this, we have been instrumenting the product to be able to output product usage information at a granular level. We are now able to report on storage usage by project and namespace, and we are working towards transfer usage (internal only) as well. We can then take the storage or transfer usage for a particular category, and aggregate it to determine the breakdown of storage/transfer by product tier. From here, we can then apply these ratios to the overall cloud costs for this particular service, to determine the tier breakdown. CI is very similar, where the cloud runner costs are shared, but with the compute minutes usage data from the product, we can allocate the costs to the correct tier.
In some cases when we lack product usage data, we can supplement with other data, for example the logging information from our registry service can provide download statistics. In addition for shared services like the database or our rails nodes, we can utilize other usage data as a proxy to allocate these costs by tier.
In order to provide detailed cost information beyond what is provided in cloud provider reporting, we need to leverage instrumentation of our own. To achieve this we are primarily working to report more detailed usage information in the product, and then ship that data over to the data warehouse.
We are working to allocate costs in primarily two ways:
By Product Tier - to accurately allocate costs across Free, Paid, or Internal Use, in support of Financial Statement classifications. (i.e. allocate to Marketing, COGS, or R&D)
While we work on refining the input data, we can continue to improve the cost dashboards we provide to our personas. We have an initial dashboard available today in SiSense.
We are working to improve this dashboard in a few key ways:
This work is being tracked here: https://gitlab.com/groups/gitlab-com/-/epics/1683
Long term, we'd like to have a few key results: