search

Azure / azure-rest-api-specs

The source for REST API specifications for Microsoft Azure.
MIT License
2.68k stars 5.1k forks source link

RateCard API and reserved instances #2750

Open Gaploid opened 6 years ago

Gaploid commented 6 years ago

Hi, Reserved instances were launched in September 2017 and there is still no data about it in API. Any plans to add reserved instances in RateCard API?

Victor

lmazuel commented 6 years ago

Tagging people that might know: @wilcobmsft @kjeur @panda-wang

AdityaTurbo commented 6 years ago

Hi, I am also looking for an RateCard API which shows data about reserved instances. Is there any update on this?

Thanks, Aditya

lmazuel commented 6 years ago

@juhee0202 ?

masters3d commented 6 years ago

blocking https://github.com/Azure/azure-sdk-for-net/issues/1846

masters3d commented 6 years ago

Is this a dup of https://github.com/Azure/azure-rest-api-specs/issues/1897 ?

masters3d commented 6 years ago

@mozehgir What does the tag Reservations means in this context?

jagan-at-sl commented 5 years ago

Any update on this? If so, is there a link to where the RI rate card APIs are described or any experience from anyone using it? The pricing calculator is able to provide the info for RI but the ratecard API for this is still MIA.

Gaploid commented 5 years ago

Yep, it seems that's much easier to sniff calculator backend API and use it instead of official rate card API.

kvaes commented 5 years ago

+1

lukeschafer commented 5 years ago

+1

alexeldeib commented 5 years ago

@lmazuel is there any update here? Rate Card API in general seems poorly documented and supported by SDKs. Latest API version is 2016-08-31-preview which is not in this repo or any of the SDKs, despite being 3 years old (e: checked Go, Python, or JS).

Documentation has not been updated and isn't shown on the current version of docs.microsoft.com because it's marked as a 'previous version'? Do you know what is going on with this API or who owns it?

Can we try to get the owners to push specs and get these downstream into SDKs?

Barring that, can we get this API properly spec'd and documented as a complement? https://azure.microsoft.com/api/v2/pricing

We are trying to build internal tooling which depends on this information being programmatically available, I don't want to invest in this if the APIs are not actively supported.

I'll do some sleuthing myself, but figured you may have an easy answer.

alexeldeib commented 5 years ago

@pargall @BryanLa sorry to pick on you, you have the only commit history I can find. Are you the owners of this API? If so, what is the current status of it? If not, do you know who is?

alexeldeib commented 5 years ago

Is it replaced by e.g. Consumption API? https://docs.microsoft.com/en-us/rest/api/consumption/pricesheet/getbybillingperiod#pricesheetproperties

Also seems like both Consumption API and RateCard API support only specific agreements: 

No subscriptions were found for guid(s) GUID. Only EA subscriptions are supported for this request. Please ensure that offer type of the subscription is either AZR-0017P or AZR-0148P.

Looking here, I can see 0148P is Enterprise Dev/Test, and though not listed I know 0017P is EA. Is there no API for general price estimation, except what is exposed at https://azure.microsoft.com/api/v2/pricing ?

JohnnyPark78 commented 5 years ago

+1 here. Trying to work through the APIs and not having a ton of success. Pricing, including RIs, for non-EA agreements is a pretty big part of an internal solution we're working on.

BryanLa commented 5 years ago

@alexeldeib - no worries.. I'm not the owner anymore, but let me see if I can find someone to comment..

DenisSa commented 5 years ago

@alexeldeib Have you discovered anything new in the past two days? A programmatic way of accessing pricing information is imperative for the solution we are working on. AWS, in comparison, makes their pricing info publicly available through API, as well as CSV and JSON.

Another issue I've noticed, for anyone trying to use ratecard API is that cursory price comparison returned different prices through pricing calculator vs ratecard API.

alexeldeib commented 5 years ago

@denissa I'm discussing this with a few people offline, I'll update back here/ask someone to comment on behalf of PG once it's clear what the status is.

I would expect Rate Card API and the public pricing calculator to be different in some cases, yes. Rate Card API is specific to a subscription, including e.g. customer-negotiated discounts from what I understand. Public pricing calculator has list prices only.

alexeldeib commented 5 years ago

Here's the latest:

For PAYG accounts, Rate Card API is still the latest. For Enterprise customers, there is the older pricesheet API and a newer API depending on the age of the agreement.

As far as this issue, reserved instances, you can fetch the reservations themselves programmatically: https://docs.microsoft.com/en-us/rest/api/consumption/reservationsdetails

My understanding of the way this works is that the price is no different, so you have the meters already for normal resource (disclaimer: dev, not pricing expert).

kvaes commented 5 years ago

A typical use case is someone who is interested in the costs of the Azure platform to talk to the APIs and integrate this into their tooling.

Imagine an ISV or customer wanting to have an overview of all our (list) VM sizes, and their prices per region, per contract form (PAYG vs RI1Y vs RI3Y) & license forms (Linux, Windows, SQL Enterprise/Standard, RHEL etc, DataBricks, ...). How would one go about on getting that info? The same goes for any other service... (Storage Blob, Storage Disk, Backup, SQL, CosmosDB, DataBricks, ...).

From experience, using the RateCard API is very hard to parse and get an exhaustive list of all the VM sizes. At the moment the only feasible way to realize this is by scavenging the back-end APIs of the Azure Calculator. As these are not designed to be consumed outside by outside parties, this involves great risk of having things broken.

Imho, The public list prices of our services should be easily & openly consumable (without involving overly complex ETL jobs to process the data).

alexeldeib commented 5 years ago

A typical use case is someone who is interested in the costs of the Azure platform to talk to the APIs and integrate this into their tooling.

Imagine an ISV or customer wanting to have an overview of all our (list) VM sizes, and their prices per region, per contract form (PAYG vs RI1Y vs RI3Y) & license forms (Linux, Windows, SQL Enterprise/Standard, RHEL etc, DataBricks, ...). How would one go about on getting that info?

Unfortunately I don't need to imagine, this is what I am attempting šŸ˜„ My understanding today is that the the Rate Card meters are your best bet. I've passed some feedback to the appropriate team about this. They aren't able to offer any commitments, but understand the desire to improve this experience.

DenisSa commented 5 years ago

This is more of a hack, however slightly better than scraping the pricing calculator. If you would like to have an overview of VM sizes and their prices per region (nothing on contract or license forms) you can join output of RateCard API and Resource SKUs API. The problem, however, is that to my knowledge Resource SKUs API doesn't expose meter IDs, so there's no way to definitively link the data from two APIs. However, it seems possible to link (possibly somewhat accurately) them using Resource SKUs API's "Size" with RateCard API's "MeterName".

Then you have to match Locations and MeterRegion using some sort of a lookup table as the naming convention is different. E.g "eastus" vs "US East"

This is the best I could find aside from scraping the pricing calculator, if somebody has a better approach please let me know until MS gets their APIs together to be more inline with what AWS offers here: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/price-changes.html (Which, in my opinion is a better way of providing pricing information)

alexeldeib commented 5 years ago

^this is also the track I am pursuing.

Gaploid commented 5 years ago

Hey, guys @DenisSa and @alexeldeib I've already done that. I`ve created a parser that combines data from RateCard and Resource API. You can see that here https://azureprice.net probably I can create an API facade for that for external parties. let me know if you are interested.

alexeldeib commented 5 years ago

@gaploid well hello! I saw azureprice.net and love what youā€™ve done. That data joins exactly the way Iā€™d want to use it programmatically. If youā€™re able to create a public interface, that would be awesome. If not, if youā€™re able to share/link the source of the site, iā€™d be interested in lending a hand to achieve the same :)

Gaploid commented 5 years ago

Hey, how many calls to API are you planning to make?

alexeldeib commented 5 years ago

Short answer: many, but spread across many individual clients making a relatively small number of calls each.

Iā€™m hoping to join the SKU + Rate Card data to implement a pricing sensitive extension to cluster autoscaler for Kubernetes. The thinking is, user can specify some set of ā€œallowedā€ SKUs (or use SKUs API itself to fetch the list dynamically filtered to allowed for subscription), and based on the user workload autoscaler can add VMs to a cluster based on some sort of least-cost estimation. Thereā€™s something similar already for GCE, thereā€™s a description over in one of the Kubernetes repos if youā€™re interested (but leaves getting the pricing data out of scope).

This would be a service deployed to customer VMs (pods in the cluster) with its own service principal authenticated to the customer subscription.

More generally, I do feel thereā€™s immediate value in packaging the combo of resource + pricing data so anyone (like the people in this thread) can easily use it. Iā€™m open to any kind of work to move us in that direction, if thatā€™s something you think would be possible on top of what youā€™ve already done!

Hope that adds some context. Happy to discuss offline if thatā€™s easier, preferred email is my GH alias @ gmail