Add cloud price publication & quote interface

[gerbsen]

Disclaimer: The following demo is an AI-generate mockup for a specific user story to prove a point and start a discussion within a specific target audience. The new AI-defined scs-04xx standard is only needed for example computation and is not meant as a real addition to SCS in its current form. Please consider this more of a conceptual rather than a technical question.

What I've noticed in the past couple of months working with SCS-compatible clouds is, that I can very reliably deploy workloads in clouds of multiple independent providers. I love that the behaviour is guaranteed to be identical. What I've also learned, especially within the discussion about the PaaS-standardization and usage metering in general is, that I don't know what a particular deployment would cost. Or to be more precise, which provider offers me the cheapest offer. OpenStack does not provide metadata for this use case and even if, it would be behind user authentication. I've seen several cost calculators on forum members websites for IaaS and KaaS, but those are, for me at least, not comparable and require repetitive and manual labour. For this reason, I think it would be very beneficial for the whole SCS ecosystem to make the costs transparent and machine readable. The advantages we would get, as I see them:

• all SCS-compatible clouds are more connected and federated
• I can programmatically buy resources within a financial budget over a timespan
• other companies (e.g. PaaS/SaaS provider) building on top of SCS IaaS/KaaS get better conditions and access
• CSPs get more exposure and sales through appearing in comparisons
• SCS-KaaS providers could build on top of SCS-IaaS providers
• through transparency there will be more competition and therefore faster growth
• at each stage a company can decide on hard facts to switch providers
• discounts for specific customers are easily configurable
• invoices can be generated automatically based on standards (xrechnung, zugferd) defined in the so-called Deutschland-Stack
• special features like environmental impact could be integrated as well

You can find the proof-of concept click-dummy here: https://scs-tech-demo-paas-and-pricing-62eb5f.gitlab.io I would be very interested in what you think about this proposal. I especially would want to know if you think something like this is necessary at all. In my opinion it would be a very beneficial step in order to get a broader set of users on board and additionally we can further underscore our claim of being a open, transparent and vendor-neutral cloud ecosystem.

[raclettejs]

We definitely see a lot of value in standardizing billing and pricing information. As there are currently no widely adopted open-source billing UIs or management UIs in general, having a standardized, machine-readable representation of pricing and usage would provide a very useful foundation for building such tools.

As part of our efforts to provide a generic open-source tool for OpenStack management, we currently support uptime-based billing. For implementing workload-based billing, however, we believe that a well-defined standard would be highly beneficial. It would allow management and billing tools to work independently of individual service providers and, more importantly, make pricing and usage comparable across different SCS-compatible clouds.

From our perspective, it would be useful to clearly separate a few aspects that are often coupled today:

• Pricing: What does a resource or service cost, and in which units?
• Metering: How is actual usage measured (e.g. vCPU-hours, GB-hours, storage GB-months, network traffic)?
• Billing: How are the measured resources translated into charges, including different billing models, tiers, minimum charges, quotas, etc.?
• Invoicing: How are the resulting charges ultimately represented in an invoice?
• Energy: Could or should the main EnergySource also be part of the provided information per Datacenter/Service Provider? -> Personal Opinion: I'd rather pay more for Wind or Solar Energy powered Datacenters than for Methane Turbine powered ones.

Having these as standardized, machine-readable building blocks would make it possible to build different UIs and tools on top of them rather than requiring every provider or management platform to implement its own proprietary integration.

It would also be important to account for things such as the validity period of prices, since pricing changes over time. Public list prices and customer-specific discounts could potentially be represented separately, with the latter only being exposed to authenticated customers where appropriate.

This could benefit both sides of the ecosystem: customers could programmatically compare providers and make decisions based on transparent pricing, while service providers could expose their offerings through a common interface without having to support a proprietary integration for every management, billing, or PaaS solution.

From our perspective, this would therefore be a very valuable addition to the SCS ecosystem. A standardized pricing and metering model could enable an ecosystem of independent open-source management, billing, and comparison tools, while further strengthening the goal of having an open, transparent, and vendor-neutral cloud ecosystem.

[depressiveRobot]

I really like the mockup and the idea behind it. I believe this is/can an important building block on the path to a distributed hyperscaler based on federated public SCS clouds.

[max-ch-dd]

@gerbsen please clarify, as I'd like to give feedback but don't quite get the scope of the discussion yet:

1. Is it about providers exposing their pricing information in a structured format over a defined API?
2. Is it about the complete functionality that your click-dummy shows?

[theSilverFisch]

It is about what you described in Point 1.
When opening the click dummy, click the scs-04XX button circled red in the screenshot to see the current draft

[gerbsen]

what @theSilverFisch said. the click dummy is only a/the way to show what this solution could enable us to do.

[toothstone]

A glimpse of what happens elsewhere, elstio recently announced support for T Cloud (formerly known as Open Telekom Cloud), which is OpenStack-based - so they probably implemented an OpenStack wrapper.

They even have the T Cloud prices listed: https://elest.io/pricing - hard to tell how they gather these, might be manual.

[toothstone]

Those are reseller prices, so they have probably some contract with Telekom, nothing to fetch dynamically.

[theSilverFisch]

another reason to standardise that to make it "open cloud" again :D

[max-ch-dd]

Thanks for putting this together, and for opening the discussion. My feedback focuses on the proposal "Cloud price publication & quote interface" (scs-04XX). I'm not commenting on the rest of the click dummy or the related processes.

General idea
I like the idea of providing an endpoint that exposes price information in a machine-readable format. That is a useful building block for transparency and comparability.

Level 1: Price publication

• Pricing models beyond vouchers: I think the proposal should also cover price optimizations such as reserved plans and savings plans. I'd suggest explicitly listing multi-year options. Providers could then decide for themselves whether to publish the same hourly rate as on-demand or a discounted one for long-term commitments. A voucher system limits the market to special-price effects and I have no good suggestion how to integrate different long-term commitments in a voucher.
• Innovations and customizing: Providers may be interested in solving concrete business problems as a value-add service besides the plain infrastructure resources. This might be an important factor for a customer to choose a provider and can only be reflected in a limited way in the current spec, or not at all. A provider might make a customer an offer "under certain conditions" that never shows up in the standardized comparison.
• Muliple Sites: In the current proposal, I don't get the idea how a cloud-provider can show the price for multiple sites/regions. You may want to go a bit more in the details, how this can be implemented in Level 1.

Level 2: Quote interface
This is not something we would provide in the near future. I'd vote for doing quote calculation in client logic or in separate SCS tooling rather than at the provider's endpoint.

For example, a cloud provider uses a CRM that handles quoting and calculation and has associated processes in onboarding customers based on the processes in this system. If the Level 2 provider interface were the source of truth for quotes, they might run into problems. The CRM may not offer an export interface for the quotes, and the cloud provider has to implement custom logic, which can be error-prone.
I understand, that the Level 2 in the proposal is optional but in my opinion the first iteration of the standard should leave this part out of scope and see how well Level 1 is adopted.

Kubernetes clusters
We price managed services differently depending on the level of integration and on response times (SLAs). I haven't looked deeply enough into the K8s standardization to give well-founded feedback yet, but I'm happy to take another look if there's a concrete question in my direction.