public-cloud-roadmap
public-cloud-roadmap copied to clipboard
ovh
Public Cloud Saving Plans
Summary
Saving Plans
A Saving Plan gives you the opportunity to get discounted prices for a certain quantity of a specific product reference, the level of discount depending on the duration you are willing to commit on.
Intended Outcome
A Saving Plan is a commercial offer. The management of Saving Plan from its creation to its termination has no impact on the infrastructure. A Saving Plan is limited to a Public Cloud project. Saving Plans are available for a specific set of product references. A quantity is defined A duration is chosen within the available options : 1 month / 6 months / 12 months / 24 months / 36 months Level of discount is function of the duration / Quantity has no impact on the level of discount. Automatic renewal option is disabled by default A Saving Plan become active at 00:00 UTC the next day A Saving Plan cannot be modified A Saving Plan cannot be terminated A Saving Plan is post-paid
Example of Saving Plans level of discount (compared to hourly price) with coming B3 compute range :
| Flavor Name | On-demand price | Saving Plan 1m | Saving Plan 12m | Saving Plan 24m | Saving Plan 36m |
|---|---|---|---|---|---|
| b3-8 | 0,0465 € | ~25% | ~47% | ~53% | ~59% |
| b3-16 | 0,0930 € | ~25% | ~47% | ~53% | ~59% |
| b3-32 | 0,1860 € | ~25% | ~47% | ~53% | ~59% |
| b3-64 | 0,3720 € | ~25% | ~47% | ~53% | ~59% |
| b3-128 | 0,7439 € | ~25% | ~47% | ~53% | ~59% |
| b3-256 | 1,4878 € | ~25% | ~47% | ~53% | ~59% |
Details about coming B3 C3 R3 compute ranges : https://github.com/ovh/public-cloud-roadmap/issues/352
As a user having a 12 months Saving Plan created for 10 B3-8, I will be monthly billed (post-paid) for those 10 B3-8 with 47% discount (considering 730 hours in a month). As long as I do not consume more than 10 B3-8 at the same time, I rely on the usage my Saving Plan is supporting. At any time, all the B3-8 instances coming on top of the first 10, will be billed based on on-demand hourly price.
How will it work
Hi @cambierr I completement understand your need and confirm we are aware of this challenge.
There are 2 parts in your questions :
- capacity to request monthly billing for VMs though Kubernetes, Openstack API, IaC tools such as Terraform : this is now possible.
- If you use our Managed Kubernetes offering you can use the monthlyBilled profperty on the nodepool CRD for a given nodepool to have alls its nodes started with monthly billing.
- If you use Terrraform openstack API you can force monthly billing at start time by adding the property ovh-monthly-instance=1
- The second question is about to enable capacity to commit to a certain consumption level, while still being able to use cloud-native approach and dynamically rebuilding environnements though ci-cd for example (cattle management). This is indeed something we have plan but more in a mid term approach.
The model we have in mind is the following :
- You commit for a certains period (1 month, 12 months ou 24 months for example) on a certains quantity (1, 2, 10) of a certain ressource type (for example B2-7 instances), and you obtain a discounted monthly price for those. Let's say you commited for 12 month on 10 B2-7. Every month, you are billed for 10 b2-7 at discounted price, whatever your consumption. If you use inedeed at any hour 10 or less, you dont get extra pay-as-you-go billing. if during a few hours you gave 12 machines started, then the 11th and 12th one are billed at hourly price at the end of the month.
Would that model suit you ?
That option (point 2) would be perfect for us: it would greatly ease cost management !
Do you have an ETA (even a very approximate one) ?
No ETA yet on this, i would say late 2021 ou early 2022 seems a reasonnable target. I will edit you initial ticket title and content to gather more votes for this approach, do not hesite to comment again if you feel I have forgotten a key point.
capacity to request monthly billing for VMs though Kubernetes, Openstack API, IaC tools such as Terraform : this is now possible. If you use our Managed Kubernetes offering you can use the monthlyBilled profperty on the nodepool CRD for a given nodepool to have alls its nodes started with monthly billing. If you use Terrraform openstack API you can force monthly billing at start time by adding the property ovh-monthly-instance=1
Just small feedback about how hard it is to use a mix of monthly nodepool and hourly nodepool for the same service with the current billing system. (we know that on some services we want to have a minimum of 5 nodes and that it can auto scale up to 20). We want to pay the 5 nodes monthly (fixed monthly nodepool of 5 instances), and the 15 other hourly (autoscalable nodepool of 15 node).
- To autoscale, we use a HPA (Horizontal Pod Autoscaler) associated with NodePools. The minimum number of pods for a HPA is 1. so I cannot just set it on the hourly nodepool (else, I will have a permanent hourly machine). 🤔
- 💡 So I setup the HPA to work on both monthly and hourly machines with a minimum value for the HPA of 5 (my monthly machines)
- Then, I want to say that when new pods are started (during a rolling update), they should target the monthly machine first (So I have to set a specific nodeAffinity preference for this). But that's not so hard.
- On the other side, when the HPA decides to scaledown, nothing forbid it to remove pods from monthly machines instead of hourly ones 😓 . So when the service scale down to 5 pods, I can have 10 machines (5 monthly machines with no pods - we pay for nothing 😢 - and 5 hourly machines with pods on them) 💸 💸 💸
- ==> To avoid this, I can now use the new https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost pod-deletion-cost annotation (only since k8S
1.22) to indicate that the pod from monthly machines should be the last to remove.
Well, it could be fine, but it's not so easy. 😬 I cannot dynamically decide to annotate pods on the monthly node with something different than the one on the hourly nodes if they are on the same Deployment (and they have to be since it's the target of the HPA). 😢
So after every upgrade/rolling-update I need to annotate the pods which are on the monthly-node. The only way I found to do this is using a helm hook (post-upgrade) to invoke a job and execute it. But to do so, I need to create a new ServiceAccount/Role/RoleBinding to give the permission to my post-process job to annotate correctly my pods 🤯
We have a set of services in AWS too. They just ask us to define the number of machines that we want to pay annually. We do not have to deal with monthly/hourly machines. It's a lot easier. It's only a billing problem. (It seems to be close to your proposal). And even if the service is more expensive than OVH, the increase of technical problems/requirement that the ovh billing system involves makes us think twice about adding more services to our OVH clusters
Any ETA update on this?
Hi @nantoniazzi Thanks a lot for this very detailled feedback. ANd yes, this issue is exactly there to solve this and the proposed deign align with the notion of "saving plans" that you have on AWS. I dont have yet an ETA to share from my compute colleagues but I confirm that it is prioritized in the next 12 months dev cycle. thanks for your patience.
Hi @matmicro we alignee internally with all public cloud product panager and gathered detailed specs for a first iteration. We made sure this is a priority identified to our internal billing colleagues. Though they did bot yet share an ETA, it has been identifiedbas a blocker for products planned late this calendar year.
The requirement have been detailed and aligned with the description of this issue? Thay have been aknowledge by our dependancies, and have been set a high priority? We currently target target early 2024 for the release of "Saving plans" and we will give a more precise ETA as we move forward.
Great news. So you confirm that these saving plans will also apply for Managed Databases, right ?
The initial scope will be compute instances (including Kubernetes nodes). But it may be generalized to other ressources after this.
@matmicro I can confirm saving plans are indeed being discussed internally for Managed Databases, nothing set in stone yet but I'll add the item to our public roadmap.
I confirm this issue was prioriritized and we will offer "Saving plans" early 2024
Hi all, Saving Plans are getting real. I updated the definition of the outcome expected.
@JacquesMrz Will this allow us tu replace VMs on-the-fly without any billing impact? If I subscribe for a saving plan of 10 VMs, having all 10 running and in the middle of the month I terminate a VM and then launch another one, will it count for 11VMs in this month or 10 Vms because there is never more than 10 running?
Hello @sblaisot as described on the updated definition of this ticket, saving plans refers to "a certain quantity of a specific product reference". I your example the "product reference" is a flavor and not a "VMs" so at the end of the month you will pay for 10 VMs no matter is you delete/create them during the month.
Hi, thank you for announcing the compute saving plans at the OVH Summit. This is exciting! 😊
I can't wait for this, as it might be a game-changer and a turning point in considering OVHCloud public-cloud instances versus more affordable options like bare-metal + Proxmox for long-term commitment contracts.
In my opinion, there are several additions that could increase the adoption of these saving plans and attract more users:
-
Allow partial or full upfront payment for the saving plans to receive an additional discount.
-
Make the instance types within a family convertible. For example, if I'm buying a 36-month saving plan for 64 x b3-8, it would be great to have the flexibility to use them as a mix of B3-* instances (like 16 x b3-8 + 16 x b3-16 + 4 x b3-32), since their prices are multiples of the "base" b3-8 instance. This would provide more flexibility in resource usage within the saving plan, making it less daunting for people unsure about their actual resource needs.
Cheers,
That seems complicated for no reason. Why not just commit on a monthly spend. Let say if I commit $1000 over 36 months, you do 2.2 the credit. So I get $2200 that I can allocated to whatever I want in the public cloud project.
That way no need for any logic of instance type conversion and whatever.
@hmorneau There is a strong difference because in exchange for a significant discount, this provides us visibility on actual IaaS consumptions (the physical infrastructures varies from one flavor family to another). credit would allow bursting 1000 instances duting a given hour for example, while the saving plans should be seen as the best way to optimize your costs for your "base" continous consumption.
Excuse me if I am missing something, but don't these new savings plans mean we have to commit for a year to get the same discount as we currently get for monthly billing. To me this seems to be a significant price increase as monthly billing will only qualify for 25%
We currently have about 40 cloud servers on monthly billing, which would result in an increase of 25% should we stick to monthly billing and pricing staying broadly the same if we commit to 12 months. For our business there is too much volatility to commit to more then monthly billing for the majority of our servers.
I do also have a question. Will it be possible to commit to say 10 b3-8 servers for 2 years, another 10 for 1 year and another 10 for 6 months?
When can we expect savings plans to be available? Without them, the new b3 flavours are rather expensive, despite the significant improvements in resources.
Hello @matmicro. I will create when an item in the Managed DB when I have something solid to share. I don't see Savings Plans on Managed DB in 2024 though as there is a lot of groundwork.
In the meantime, having B3-X instances in hourly has a cost difference that cannot be ignored. ETA for saving plan ? Thanks
Sorry to ask again, but understanding the options is important to us.
Will it be possible to commit to say 10 b3-8 servers for 2 years, another 10 for 1 year and another 10 for 6 months?
@apjltd "Sorry to ask again, but understanding the options is important to us.
Will it be possible to commit to say 10 b3-8 servers for 2 years, another 10 for 1 year and another 10 for 6 months? => Yes it will be possible
Any updates on the Gen3 monthly or saving plans?
Also, none of these flavours are currently available, they used to be available on at least GRA and BHS;
