Public Cloud Saving Plans

[cambierr]

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

Details about coming B3 C3 R3 compute ranges : https://github.com/ovh/public-cloud-roadmap/issues/352 Prices will be shared in the coming months

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 X% 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.

[mhurtrel]

Hi @cambierr I completement understand your need and confirm we are aware of this challenge.

There are 2 parts in your questions :

1. 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

2. 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 ?

[cambierr]

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) ?

[mhurtrel]

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.

[nantoniazzi]

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?

[mhurtrel]

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.

[matmicro]

Any news on this ?

[mhurtrel]

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.

[mhurtrel]

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.

[matmicro]

Great news. So you confirm that these saving plans will also apply for Managed Databases, right ?

[mhurtrel]

The initial scope will be compute instances (including Kubernetes nodes). But it may be generalized to other ressources after this.

[thild42]

@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.

[mhurtrel]

I confirm this issue was prioriritized and we will offer "Saving plans" early 2024

[JacquesMrz]

Hi all, Saving Plans are getting real. I updated the definition of the outcome expected.

[sblaisot]

@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?

[antonin-a]

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.

[sblaisot]

Thanks you for your confirmation. can't wait to test it...

[rdegez]

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,

[hmorneau]

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.

[mhurtrel]

@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.

[apjltd]

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.

[apjltd]

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?

[apjltd]

When can we expect savings plans to be available? Without them, the new b3 flavours are rather expensive, despite the significant improvements in resources.

[matmicro]

ETA for saving plans ? For PCi and Managed DB ? Thanks!

[thild42]

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.

[boagg]

In the meantime, having B3-X instances in hourly has a cost difference that cannot be ignored. ETA for saving plan ? Thanks

[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?

[mhurtrel]

@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

[apjltd]

Any update on when savings plans will be available?

[hmorneau]

Any update?

[karljohns0n]

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;

[guldil]

Do you have any information about the availability of this feature?

Several weeks ago we migrated some instances to B3-8 in the hope that the saving plans would be available fairly quickly..

[hmorneau]

Do you have any information about the availability of this feature?

Several weeks ago we migrated some instances to B3-8 in the hope that the saving plans would be available fairly quickly..

I have been waiting before migrating, as I know this can take much longer than planned. I would not be surprised if this is still open in a year from now.

[guldil]

Do you have any information about the availability of this feature? Several weeks ago we migrated some instances to B3-8 in the hope that the saving plans would be available fairly quickly..

I have been waiting before migrating, as I know this can take much longer than planned. I would not be surprised if this is still open in a year from now.

3 years to release this ? None of this seems particularly complex to me... AWS have it since 2019...

[apjltd]

Is there any chance of at least monthly prices being implemented as in interim measure so we can start using the B3 models on the same basis as the B2 models?

[emaktech]

3 years to release this ? None of this seems particularly complex to me... AWS have it since 2019...

To be fair, implementing billing systems needs to be quite thoroughly tested. If there is even a small error in billing at any point, imagine the amount of user complaints and insane cost of dealing with the backlash. I get that something like this needs to be done right.

Is there any chance of at least monthly prices being implemented as in interim measure so we can start using the B3 models on the same basis as the B2 models?

But also so much this! What I can only assume is tons of CapEx poured into acquiring new EPYC servers and they are just sitting around idle while you figure out how to bill users? Seems crazy to me.

[guldil]

I know that billing can be a complex subject, I've been implementing it for over 20 years now. But that's also why I'm taking the liberty of being critical, especially as we're talking about OVH, european leader of cloud...

[zeeZ]

New instances launched half a year ago and monthly plans are still "Coming soon". Any updates on that early 2024 goal?

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%

The current monthly commitment is slightly above 50%, so you'd have to commit for two years.

[HadrienKulik]

Any update on the Saving Plans ? We'd love to get some B3, C3, etc. instances but the hourly rate is prohibitive

[stabarly]

Saving plans are still in "Prioritized" column, not planned ...

[hmorneau]

I hope I was not too optimistic with my 12 months forecast.

[guldil]

OVH was pleased to have increased its profitability in the first quarter of 2024... Cause and effect?

[JacquesMrz]

Your comments are legit. We've faced some delays in the Dev of what we need to expose Savings Plans. Meantime you should have seen some change, your monthly instances are now postpaid so that all your Public Cloud project's spending for one month are shown on one invoice. Based on our current planning, we will launch Savings Plans by September (this year, 2024).

[mhurtrel]

Sorry for the absence of updates during the last few months. Billing and UX teams are currently polishing the experience and finalizing the development. we currently target a release of Saving plans in September 2024.