Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Fair way to charge for control panels / cloud platforms?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Fair way to charge for control panels / cloud platforms?

ditlevditlev Member, Top Host, Host Rep
edited September 2020 in General

So, lately there's been a lot of changes in how software vendors (targeting the service provider / hosting scene) charge for their software. cPanel, Plesk, Solus IO ... At OnApp we've generally charged per CPU core, our aim was to build a transparent pricing methodology that made it easy for our partners to make OnApp part of their calculations.

When we started out CPU cores was the 'currency' that service providers used. Over the years that has become RAM, but other software vendors charge per VM, User or even websites...

Ignoring the $/unit question, ie. the cost per VM/Core/RamG/etc - just looking at the methodology, what do you think would be the fairest way? What would you prefer?

Thanks!

:)
D

Comments

  • hostworldhostworld Member, Host Rep

    From a hosts perspective there's no single way of calculating this in my opinion. It's always a balancing act to establish your true cost price based on resource consumption and allocation. You need to consider if someone bought a lot of your lowest RRP resource, would you make a profit? If not, then you need to go back to the drawing board as you don't then have a sustainable business model, unless people purchase a huge amount of your higher RRP items to offset the loss leaders.

    Thanked by 1ditlev
  • ditlevditlev Member, Top Host, Host Rep
    edited September 2020

    @hostworld said:
    From a hosts perspective there's no single way of calculating this in my opinion. It's always a balancing act to establish your true cost price based on resource consumption and allocation. You need to consider if someone bought a lot of your lowest RRP resource, would you make a profit? If not, then you need to go back to the drawing board as you don't then have a sustainable business model, unless people purchase a huge amount of your higher RRP items to offset the loss leaders.

    Thanks!
    From that perspective the best way of pricing platforms would be as a % of revenue? When I had my hosting companies (UK2, VPS.net, 100tb.com etc) I always disliked that approach. But is that what you are saying?

    Thanked by 1dustinc
  • Mr_TomMr_Tom Member, Host Rep

    Per core works fine a lot of the time - what's off putting in terms of pricing is when your sales keep avoiding the "how much does it cost to licence onapp?" question by replying with other questions. They were somewhat related questions but it felt like they were dragging out the process of just saying how much it actually costs per core.

    Thanked by 1ditlev
  • ditlevditlev Member, Top Host, Host Rep

    @Mr_Tom said:
    Per core works fine a lot of the time - what's off putting in terms of pricing is when your sales keep avoiding the "how much does it cost to licence onapp?" question by replying with other questions. They were somewhat related questions but it felt like they were dragging out the process of just saying how much it actually costs per core.

    I get it ... That is so annoying - especially when you actually know all you need to know and just want the price. I hate when sales people do it to me.

    Will take your feedback to my sales team. Thanks!

    Now, re the question, would you prefer CPU cores to RAM or VMs?

    Thanked by 1Mr_Tom
  • Per hypervisor, is the best option.

  • ditlevditlev Member, Top Host, Host Rep

    @Tejy said:
    Per hypervisor, is the best option.

    Yup - understand why hosts would say that :)

  • @Tejy said:
    Per hypervisor, is the best option.

    May I ask you why you're asking us this question?
    You want to make OnApp more accessible for more companies?

  • Take an example..
    I have a (now old) Dual Quad Xeon 5420 (16 x vCPU) that I run Proxmox on, with a /29 and 8GB RAM. The free Proxmox VE makes this a very viable option on a (very) low cost dedicated server. I only run my own services/VPS (5x VMs currently), with no direct client hosting on it.
    I daren't think what OnApp what cost to run on this particular environment.

    Granted this is an unusual scenario but perhaps illustrates where a product is viable for actual use.

  • Mr_TomMr_Tom Member, Host Rep

    @ditlev said: Now, re the question, would you prefer CPU cores to RAM or VMs?

    Out of the 3, per core would probably be my preference assuming that any host/management node (which doesn't run VMs) is excluded from the count. Staged is fine (e.g up to 100 cores = xx/month, 101-150 = yy/month).

    Per VM is interesting, I can see it being potentially cheaper to start up and would be good if you've got a "fixed" range so you can plan how much it would cost per full node.

  • oplinkoplink Member, Patron Provider

    I think the bigger problem is hardware costs. It seems like every 5yrs everything needs to be rebuilt from the ground up to stay relevant in a sub 5/month VPS market.

    Everyone is always trying to have the latest fastest cpu and disks.

    After hardware costs, its a slap in the face when its $xx.xx per core

    Its why solusvm is still the go to choice for many hosts here.

  • ditlevditlev Member, Top Host, Host Rep

    @Tejy said:

    @Tejy said:
    Per hypervisor, is the best option.

    May I ask you why you're asking us this question?
    You want to make OnApp more accessible for more companies?

    yup - I talk briefly about it here. We are currently re-evaluating our product range (incl. pricing) to ensure that we can match requirements of a wider group of hosters/SPs.

  • ditlevditlev Member, Top Host, Host Rep

    @AlwaysSkint said:
    Take an example..
    I have a (now old) Dual Quad Xeon 5420 (16 x vCPU) that I run Proxmox on, with a /29 and 8GB RAM. The free Proxmox VE makes this a very viable option on a (very) low cost dedicated server. I only run my own services/VPS (5x VMs currently), with no direct client hosting on it.
    I daren't think what OnApp what cost to run on this particular environment.

    Granted this is an unusual scenario but perhaps illustrates where a product is viable for actual use.

    absolutely! We can not compete against free :)

  • ditlevditlev Member, Top Host, Host Rep

    @oplink said:
    I think the bigger problem is hardware costs. It seems like every 5yrs everything needs to be rebuilt from the ground up to stay relevant in a sub 5/month VPS market.

    yes, at UK2/100tb/VPS.net we depreciated all hardware over 3 years. Now it was not worthless at that time, but it was defo a bargain-basement spec.

    Everyone is always trying to have the latest fastest cpu and disks.

    yup

    After hardware costs, its a slap in the face when its $xx.xx per core

    I guess that works both ways, it sucks to pay $xxx/core in hardware and then not having the right software platform to monetise it :wink:

    Its why solusvm is still the go to choice for many hosts here.

    Yup - good platform at a strong price. Virtualizor & proxmox ditto.

  • ditlevditlev Member, Top Host, Host Rep
    edited September 2020

    @Mr_Tom said:

    @ditlev said: Now, re the question, would you prefer CPU cores to RAM or VMs?

    Out of the 3, per core would probably be my preference assuming that any host/management node (which doesn't run VMs) is excluded from the count. Staged is fine (e.g up to 100 cores = xx/month, 101-150 = yy/month).

    Thanks - the reason we are re-evaluating this is that most of our partners are now selling their infrastructure based on ram. Same could be said about digitalocean, linode etc. Ram seems to be the currency, no?

    Per VM is interesting, I can see it being potentially cheaper to start up and would be good if you've got a "fixed" range so you can plan how much it would cost per full node.

    I like the VM model, however I think in some cases it would favour a particular part of the market. Say we charged $1/vm/mo - then for the $5VM-type-serviceprovider that would be 20%, but for the $100/vm it would be 1%. I'd prefer a model that was catering to a larger portion of the market.

    Thanks for your input everyone!

  • Mr_TomMr_Tom Member, Host Rep

    @ditlev said: Thanks - the reason we are re-evaluating this is that most of our partners are now selling their infrastructure based on ram. Same could be said about digitalocean, linode etc. Ram seems to be the currency, no?

    A lot of providers seem to hand cores (or vcores/threads) hand in hand to RAM - so 1 core, 1gb RAM etc.

    Assuming they're assigning vcores (1 thread) then 100 core licence covers 200 VMs, but licencing 100gb RAM is only 100 VMs.

    Do you mean you want to target a larger portion of the current hosting market, or you're looking at pricing that works for the larger portion of your current client base?

  • ditlevditlev Member, Top Host, Host Rep
    edited September 2020

    @Mr_Tom said:

    @ditlev said: Thanks - the reason we are re-evaluating this is that most of our partners are now selling their infrastructure based on ram. Same could be said about digitalocean, linode etc. Ram seems to be the currency, no?

    A lot of providers seem to hand cores (or vcores/threads) hand in hand to RAM - so 1 core, 1gb RAM etc.

    But typically the ram is not oversold, where as the cores are oversold 8-10 times easily...

    Do you mean you want to target a larger portion of the current hosting market, or you're looking at pricing that works for the larger portion of your current client base?

    both :)

  • jhjh Member
    edited September 2020

    I'm not the most qualified person to answer - our company's hosting operations are quite small and mostly exist to support the rest of our business - but from what I've observed, I think you need some minimums and maximums. Something like $x per VM per month with a minimum commit of y VMs across the whole account and a maximum charge of $z per node per month.

    The minimum charge hopefully means you don't have tiny accounts driving up costs for everyone and the maximum charge per node helps out the budget hosting companies that pile them high and sell them cheap.

    With this in place I think per VM pricing works well just because it's easy - I know if I sell a new VM, I need to factor in the per VM licence price. I'm also not so worried about spinning up capacity ahead of time.

    Thanked by 1ditlev
  • dustincdustinc Member, Patron Provider, Top Host

    @ditlev said:

    @hostworld said:
    From a hosts perspective there's no single way of calculating this in my opinion. It's always a balancing act to establish your true cost price based on resource consumption and allocation. You need to consider if someone bought a lot of your lowest RRP resource, would you make a profit? If not, then you need to go back to the drawing board as you don't then have a sustainable business model, unless people purchase a huge amount of your higher RRP items to offset the loss leaders.

    Thanks!
    From that perspective the best way of pricing platforms would be as a % of revenue? When I had my hosting companies (UK2, VPS.net, 100tb.com etc) I always disliked that approach. But is that what you are saying?

    I've always disliked that approach too, which is why a lot of the big boys are trying to leave Ubersmith today :tongue:

  • ditlevditlev Member, Top Host, Host Rep

    @dustinc said:

    @ditlev said:

    @hostworld said:
    From a hosts perspective there's no single way of calculating this in my opinion. It's always a balancing act to establish your true cost price based on resource consumption and allocation. You need to consider if someone bought a lot of your lowest RRP resource, would you make a profit? If not, then you need to go back to the drawing board as you don't then have a sustainable business model, unless people purchase a huge amount of your higher RRP items to offset the loss leaders.

    Thanks!
    From that perspective the best way of pricing platforms would be as a % of revenue? When I had my hosting companies (UK2, VPS.net, 100tb.com etc) I always disliked that approach. But is that what you are saying?

    I've always disliked that approach too, which is why a lot of the big boys are trying to leave Ubersmith today :tongue:

    Well, actually - for billing systems I think it makes sense :)

  • RadiRadi Host Rep, Veteran

    Per hypervisor.

    Thanked by 1Falzo
  • Why not mix of all?
    Give customer option to pay per VM, per core, per gb ram or per hypervisor or % of income.
    Customer can choose best pricing scheme for him.

  • ditlevditlev Member, Top Host, Host Rep
    edited September 2020

    @dodheimsgard said:
    Why not mix of all?
    Give customer option to pay per VM, per core, per gb ram or per hypervisor or % of income.
    Customer can choose best pricing scheme for him.

    I like pricing to be super simple and impossible to misunderstand.

    @Radi said:
    Per hypervisor.

    When we started out with OnApp a super beefy hypervisor would have 2 sockets with perhaps 4 cores in each. So, 8 cores in total. Now, a hypervisor happily does 10x that. Sure, application requirements have also increased slightly over the last 10 years, however not close to 10 fold.
    So, for the hypervisor model to work (as a software vendor), pricing would have to increase as hypervisor capacity increased. Otherwise we'd slowly but surely drive ourselves out of business.

    Does that make sense?

    Actually, thinking about that ... power per core is actually relatively decreasing. SO a strict pricing-per-core model (as OnApp do now) works against our clients usage patterns.

  • jarjar Patron Provider, Top Host, Veteran
    edited September 2020

    Make a “low end” license that’s per HV but limits that HV to VMs of X memory size. This makes it accessible to the budget provider which increases the desirability of the panel for others who can more reasonably pay for the regular license. It also severely limits their business model and will force their higher tier services into a more profitable model for you.

    Per core is fine. It’s not going to win anyone over who doesn’t like it but per HV is increasingly unfair as larger capacity nodes become cheaper to buy, rent, and maintain. The more VMs they sell the more likely they open support tickets to pass on their customer’s reports/requests/complaints. They shouldn’t be relying on you entirely to automate their business while paying you $5/m per $50k/m revenue and expecting you to scale your business with their needs. You can’t reason with anyone who has that expectation of you.

    IF per HV is just so desired that it’s profits can’t be tossed aside, then just make it a middle ground. Something like $50-$100/m per HV. Not $5-$15.

  • For private business, IT, cloud, etc.: per core
    For hosting providers: per hypervisor

  • ditlevditlev Member, Top Host, Host Rep

    @stewdetox said:
    For private business, IT, cloud, etc.: per core
    For hosting providers: per hypervisor

    all our customers/partners are service providers/hosting companies/telco's

  • ditlevditlev Member, Top Host, Host Rep
    edited September 2020

    @jar said:
    Make a “low end” license that’s per HV but limits that HV to VMs of X memory size. This makes it accessible to the budget provider which increases the desirability of the panel for others who can more reasonably pay for the regular license. It also severely limits their business model and will force their higher tier services into a more profitable model for you.

    I see your point - and it's actually pretty good. I like that idea. So fixed price per HV, but with a max of X RAM allocated per VM?
    However it can get really complicated. Like what if one of the end-end user VMs autoscale or requires more memory than the license allows?

    Per core is fine. It’s not going to win anyone over who doesn’t like it but per HV is increasingly unfair as larger capacity nodes become cheaper to buy, rent, and maintain. The more VMs they sell the more likely they open support tickets to pass on their customer’s reports/requests/complaints. They shouldn’t be relying on you entirely to automate their business while paying you $5/m per $50k/m revenue and expecting you to scale your business with their needs. You can’t reason with anyone who has that expectation of you.

    Thank you!!!

    Thanked by 1jar
  • jarjar Patron Provider, Top Host, Veteran

    @ditlev said:
    I see your point - and it's actually pretty good. I like that idea. So fixed price per HV, but with a max of X RAM allocated per VM?
    However it can get really complicated. Like what if one of the end-end user VMs autoscale or requires more memory than the license allows?

    Either flat out don’t allow it or let it be migrated to another HV.

    Thanked by 1ditlev
Sign In or Register to comment.