Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEEDBACK]: Standardize billing tags and provide them as first-class columns #648

Open
jesseadams opened this issue Nov 15, 2024 · 11 comments
Assignees
Labels
dimensionality Fields that describe / group / filter metrics

Comments

@jesseadams
Copy link

jesseadams commented Nov 15, 2024

Summary

Right now there are no tagging standards for to support the Invoicing/Chargeback and Allocation FinOps capabilities. Practitioners define their own standards and must use the Tags column of the FOCUS specification. Then you must have an extra step to somehow expand those tags to gain meaningful insights and support chargeback models.

Which area does this issue relate to?

A: Missing FinOps feature, use case, or scenario

Detailed Description

A standard FinOps tagging strategy that works across multiple cloud providers typically includes a consistent set of tags that support invoicing, chargeback, and cost allocation. This strategy ensures that you can track and manage cloud costs efficiently across environments like AWS, Azure, and Google Cloud, aligning costs with business units, projects, and other organizational structures.

Here’s a example tagging framework that could be used:

1. Environment (e.g., env or environment)

  • Purpose: To differentiate resources based on the environment where they’re used.
  • Examples: prod, dev, test, qa

2. Cost Center (e.g., cost-center)

  • Purpose: To associate costs with specific cost centers or accounting groups.
  • Examples: HR, Marketing, Finance, Engineering

3. Project or Application (e.g., project, application)

  • Purpose: To identify resources belonging to specific projects or applications, supporting allocation of costs to those initiatives.
  • Examples: project-X, app-Y

4. Business Unit (e.g., bu or business-unit)

  • Purpose: To group resources based on the organizational division or business unit.
  • Examples: sales, operations, customer-service

5. Owner (e.g., owner, responsible-party)

  • Purpose: To identify the primary person or team responsible for a resource, which helps for accountability and chargeback.
  • Examples: [email protected], devops-team

6. Department or Team (e.g., department, team)

  • Purpose: To track spending by department or team within the organization.
  • Examples: development, security, IT-support

Example

For a specific VM resource in a multi-cloud environment, a tagging strategy could look like this:

Tag Key Tag Value
environment prod
cost-center HR
project RecruitmentApp
business-unit sales
owner [email protected]
team HR-Dev

This approach ensures that invoicing, chargeback, and allocation are more straightforward and consistent across any cloud provider.

What use cases, FinOps or others, can't be performed with the existing specification unless this issue is addressed?

While it is certainly possible to perform the Invoicing/Chargeback and Allocation FinOps capabilities with the current version of the specification, I propose we collaborate to define a tagging standard to support these FinOps capabilities. Once defined, they could be top level fields of the FOCUS specification.

There are two things here.

Defining a tagging standard

Coming up with a single, generic standard for billing related tags that can be adopted by everyone. Right now different companies, teams, projects, government agencies, etc. do their own thing. This makes it impossible to add more relevant use cases to https://focus.finops.org/use-cases/ around billing tags and chargeback models. Having these examples available could help accelerate FOCUS adoption.

Query complexity

Right now we have to add complexity and potential additional latency into SQL query execution times. One example is having to use Amazon Athena's data extraction functions json_extract_scalar and json_extract to get the values we need out of the Tags column. Your forced to use functions such as these that differ across various SQL engines.

Docs for reference: https://docs.aws.amazon.com/athena/latest/ug/extracting-data-from-JSON.html

Example Query:

SELECT
  ServiceName,
  EffectiveCost,
   json_extract_scalar(Tags, '$.owner')
FROM focus_synthetic
LIMIT 100;

Which FinOps personas does this issue relate to?

FinOps Practitioner, Engineering, Finance

Which provider groups or specific providers does this issue relate to?

This would apply generically to all providers.

On a scale of 1 - 4, how critical is this for your organization?

2: Important for adoption in the next 3-6 months

Objective

The desired outcome would be to not have to do anything special to expand these tags out from the Tags column. You could simply use the chargeback/allocation tags immediately on a FOCUS compliant dataset. This will support adoption and make it easier to gain insights in various analytics and AI related tooling that supports a healthy FinOps practice.

Data Examples

No response

Issues, PRs, or Other References

No response

@github-project-automation github-project-automation bot moved this to Triage in FOCUS WG Nov 15, 2024
@jesseadams jesseadams changed the title [FEEDBACK]: Standardized billing tags and provide them as first-class columns [FEEDBACK]: Standardize billing tags and provide them as first-class columns Nov 15, 2024
@mike-finopsorg
Copy link
Contributor

While I love the idea of this, I will add that this one maybe difficult for practitioners as they are likely to have existing Tagging Polices and processes that use different key names than those proposed here. We would need more research on how likely practitioners are to adjust their tagging practices.

I guess if the specification supports some "blessed" values, but a practitioner chooses not to use them they can always fall back to using the Tags column.

@shawnalpay shawnalpay added dimensionality Fields that describe / group / filter metrics needs use case Needs a description of the why (use case or other problem to solve) labels Nov 20, 2024
@jesseadams
Copy link
Author

@mike-finopsorg Yeah I don't see this causing any issues with backwards compatibility. Their tags would still show up in the Tags column. They just wouldn't be available as first class columns.

@shawnalpay
Copy link
Contributor

@jesseadams In your initial post, could you please add at least one use case that adding such columns will unlock? You touched on it a bit: I think your concern is more about the complexity of fetching the data, rather than the presence of the data itself -- is that right? If so, please phrase the use case along those lines.

@jesseadams
Copy link
Author

@shawnalpay I have edited the initial post. Please let me know if you need anything else.

@shawnalpay shawnalpay removed the needs use case Needs a description of the why (use case or other problem to solve) label Nov 25, 2024
@Lvandavasi
Copy link

  • Tags help organize resources by categorizing them based on attributes like workload, environment, or owner.
  • Easily locate resources associated with specific teams, projects, or environments.
  • Helps in budgeting and forecasting by providing detailed insights into resource consumption
  • Supports governance by ensuring consistency and adherence to policies across resources

@killrathy
Copy link

Looks good. Let me know if you need anything else.

@vazzanag
Copy link

Looks good to me!

@jpradocueva
Copy link
Contributor

Summary from the Maintainers' call on Nov 25

Context:
This issue focuses on standardizing tagging columns within the FOCUS dataset to ensure uniformity in how user-defined and system-generated tags are represented. The goal is to reduce ambiguity and facilitate better parsing and analysis of tagged data across implementations.

@yebiomesfin
Copy link

Looks good to me!

@dannberg
Copy link

I agree with @mike-finopsorg . I do like the idea of FOCUS possibly having some "blessed" values, but I think that the six proposed might be too many. If I were to whittle it down, I'd vote team and project as sort of the absolute minimum for a solid FinOps practice. Although I think the six outlined here can serve as a solid run-stage lodestar for people building out a super robust tagging practice.

@shawnalpay
Copy link
Contributor

One other thing to keep in mind here, and to build on what @mike-finopsorg intimated: a provider would need to implement an upstream structure that allows the practitioner to map their org's various tag keys to these "normalized" tag keys. For example, the org may have tag key biz-unit, but that would need to get mapped to Business Unit (or whatever the official FOCUS tag key name might be).

As a FinOps vendor, we built a front-end tool that facilitated this mapping. Obviously that's beyond the scope of the specification, but such functionality would be a necessary consideration for a FOCUS data generator. We have no such definitions in the FOCUS spec today to recommend FOCUS dataset configuration, but I believe it would be a prerequisite for this issue, if and when we implement it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dimensionality Fields that describe / group / filter metrics
Projects
Status: Triage
Development

No branches or pull requests

9 participants