Phasing Out our Socket-based Licensing

[mkaec]

I was disappointed to see this phrase in yesterday's Veeam R&D Forums Digest: "...before we can start phasing out our Socket-based licensing."

The digest also indicated that customer feedback is being accepted. So, my feedback is to please don't force customers to VUL from socked-based licensing. That includes not only forcefully switching them over, but also raising to price of socket-based licensing to make it prohibitively expensive.

Right now, if I want to add a VM, then I can add one and add it to a backup job, and be done with it. If I have to pay per VM, then the process goes like this:

1. Send a quote request to the VAR.
2. Wait for the VAR to get pricing from Veeam and create a quote in their system.
3. Receive the quote from the VAR.
4. Submit the quote for purchasing approval.
5. Wait for a PO number.
6. Submit the PO to the VAR.
8. Wait for the VAR to process the quote and create an order.
9. Wait for Veeam to process the order.
10. Get the new license file.

[rbienvault]

Hello,

I am in agreement, at the moment, we love the Socket-based licensing at it is perpetual (CAPEX use), and we do not want to switch to a subscription based model (OPEX).
Socket based model is easy for us to manage as when we are buying new hardware to extend our capacity, we include the license and that's done.

Switching to a per VM licensing will have to make us predict what the user will consume in the future, and it will make more complicated to predict and will open the door to screw ups.

For example we are predicting for the year, 1000 vms of average sizing.
But in reality our user can take different sizing, smaller one for example and we will end up with 1350 vms. So we need to gather more funding for that 350 more vms, the process will be way heavier that the socket based model.

[Gostev]

@mkaec actually, the process is much simpler with VUL than you suggested above: you just add a VM to a backup job, and you're done remember that one of the VUL perks is the ability to exceed the licensed number of workloads by up to 10%.

@rbienvault you're making a typical mistake of equating VUL to the Subscription, while it is also available on the Perpetual contract for customers who require CAPEX.

You're right in that it is hard to predict the workloads growth, but we have thought of this issue from the beginning - and it is the reason why we allow to exceed VUL usage. So in good half of scenarios, VUL will actually be MORE flexible than Socket-based licensing. For example, you cannot add a new hypervisor host with a Socket license without buying an additional license, but you CAN do the same with VUL.

Overall, for me it's not a question that Socket-based licensing will be discontinued in the future, just because it is not cloud-ready. In fact, many of our chief competitors have already done so last year. Thus, the only question is how fast it happens - and this is something not up for me to decide. Although from my end, I will be pushing for a smooth and long transition period of at least 3 years for the existing customers, so that they have plenty of time to consider their options. In the end, this is what I would personally want, if I were a customer myself. So, I will continue to be your advocate on this end as always!

In my ideal world, we don't pull the emergency break until we have less than 10% of customers using Socket-based licenses. How we get down to these adoption numbers and how long it takes are separate questions, but I personally don't think it will be a smart move for us to discontinue Socket licensing while the bigger part of our customers are still using one.

[fga]

To add on top:
We are also absolutly NO fan of the VUL licencing.
We have our 3 ESX hosts with an vmware essentials bundle. So there is no posibillity to add a 4th host. therefore the 6 socket enterprise licence fits us perfectly. we also don't need any of the ent. plus features.
For us this licence change would increase our cost by a massive amount. there is no ifs and no buts. just massive extra cost without anything in return.
If that should happen we actually would not extend our support contract and just run with the latest then available version.

[Gostev]

For us this licence change would increase our cost by a massive amount. there is no ifs and no buts.

Not if we ensure with the Migration Policy that this does not happen? Even the current v3 allows you to keep the discount for your currently protected VMs in perpetuity, specifically to combat this concern.

[fga]

Okay. Hypothetical example:
Now we can double our VM Count on the existing cluster without any extra cost hitting us at any time.
With VUL? not so sure about that.
And yes we have the capacity on those 3 hosts to do that...

I hope you do understand my dilemma here...

So please veeam team: just because every other company tries to squeeze out even more money with this stupid "rental licence" crap just to please their shareholders. be the better company and don't do that.

PS: Just for your info: The second Gartner bought veeam last year i told my IT Partner where we get our licences from: please check for another vendor the prices will go up and they will force us into VUL. And I was right again.

[Gostev]

That's a totally separate issue due to the computer hardware becoming more and more powerful every year. This issue is being addressed by all vendors either way through Socket price increases. Our approach has been increasing the Socket price annually to account for increasing VM density per Socket. VMware chose to instead double their Socket price starting from certain number of cores in CPU, etc.

In other words, for the purpose of this discussion we can consider that the price per-VM will remain the same in the long run for both Sockets or VUL. In other words, even if we keep Socket licenses, 5 years from now they will cost 2x of what they cost now. So by the time you get to double the number of VMs on the same 6 sockets, the effective cost per VM will remain the same as it is today.

[fga]

@gostev: i am not talking in 5 years.. i'm talking tomorrow.
We do not run our cluster maxed out. We're maybe just a little company with about 100 vms running.
But right now i have the capacity to go way over 300 tomorrow if i want to.
With VUL my licencing cost would just explode. So still: big fat NO from our side here.

But thank god we still have 2 years of support left to sit this out, maybe i'll talk to my supplier to try to even get a longer support contract. and if veeam forces us to switch we just don't and let it run out.
And if so we will defintitly not upgrade to any new version that requires vul.
Sorry.
Veeam is a really great software. but with this type of licencing I'd rather go open source (bacula/bareos/whatever) and deal with community support than pay such a massive extra amount of money for NO real benefit at all.

unless you convert one socket for example into 30 or 40 VUL licences... then we'd MAYBE think about it..

PS: Just to be fair here: do you have any link to this V3 Migration policy where i could read up on?

PPS: Yeah it was insight who bought veeam not gartner. sorry for that.

[Gostev]

If you run the cluster underutilized now, you can migrate more VMs then you're actually have (up to a reasonable cluster capacity). I don't have all details at hand, but from what I remember, up to the certain VM per Socket density they will just migrate you with no questions asked. This is also new with the Migration Policy v3.

In general - I admit there's certainly a conflict of interests here, so I don't necessarily expect us to come to an agreement right away. Compromises will be required on both ends, like the ones we have already implemented in the Migration Policy v3.

I mean, how can you not love the fact that you're protecting 100 VMs today, and can go to 200 VMs tomorrow without paying Veeam extra to cover our 2x increased support costs. However, the people who do budgets at Veeam do not like this idea even more, because this same ability directly impacts profitability and so health of the company - and so it's ability to keep building "a really great software" (thank you btw).

In situations when I am the customer myself, I totally agree with your perspective. For example, I like to travel so I would *love* to be able to book a 5000 miles flight, but have the flexibility to take a 10000 miles flight instead without paying extra. And I would hardly listen to the voice of reason from the airline about 2x fuel costs if they would be taking this ability away from me

Changing the software (or the airline) is always an option of course. You can take a risk and jump some really cheap 3rd world airline, or you can help your favorite airline go through a tough airfare transition with some valid feedback, so that together we can come to a mutually acceptable solution. Up to you!

One thing I can say - no offence, but "keep my ability to take 2x longer flights at no extra cost, or I will stop flying/switch to a free airline" type of feedback is really not useful for me, because I will be laughed out of the room if I bring something like that to an executive meeting. So, please give me something I can use there that will actually resonate with people who needs to keep this company profitable in ever-shrinking Sockets footprint realities.

[fga]

@gostev: no offense there from me and no offense taken.
Sorry i'm just a bit angry right now as it just went down that road i already have seen a year ago...
I really do see your side on this. don't get me wrong on that.

So to give you something to talk about:

How about a "conversion option". 1 socket to x VUL depending on the hardware configuration that existed on the cluster the moment the licence is converted?
So for example here: i'm going with a 1:2 overprovision on CPU cores here because that is more or less the standard you run at the moment.
For each core on a Socket you get 2 VUL Licences. 20 Core CPU => 40 VUL.
6 Sockets, 20 Cores each would result in 240 VUL.
And those 240 VUL run at the same price for the customer as the 6 Socket Licence they used before (or within a resonable range ofc).
(our cluster runs 6x12 Core atm. so that would give me for example 144 VUL. still not nearly at the capacity we could run but a bit closer)

Could something like that be a valuable option instead of the "you get licences as you have VMs at that moment" approach?
This could give the smaller to mid sized companies like ours the wiggle room to add VMs to existing farms without getting hit by a massive bill.

Yes i see the "what if i run higher an 1:2 overprovison". its just an idea that i came up with while writing this.

PS: Yes i really meant great software. it just works. now we "just" need a linux tape server and veeam b&r would be nearly perfect (minus the bugs of course )

[Gostev]

Yep, that's basically our current approach more or less.

As I've said, the Migration Policy v3 allows migrating up to the certain reasonable VM per Socket density without any questions asked. By the way I'm sorry to say, but 40 VMs per Socket is not a reasonable density when average across our 400K customers is 9 VMs per Socket, and median is 6 VMs per Socket. However, in addition to that, our sales staff is empowered to be flexible in situations where customers presents a valid scenario to have 40 VMs per socket like yourself. For example, if you have some application that spawns dozens of virtual Raspberry Pi VMs

With that in place, we want to see how it goes over the next year, and determine the universal migration thresholds and conditions making over 90% of customers to accept migration to VUL. Then, we present the results to executive team, and (hopefully) this becomes the final version of the Migration Policy.

Overall, it's certainly a complex transition that will require much time to execute, so it's hard for me to see Sockets discontinued for existing customers sooner than 3 years from now. However, in general I think it is inevitable: while the growing VM density per Socket can easily be addressed with continuous price increases, it is impossible to make Socket licenses hybrid cloud-friendly.

[Gostev]

now we "just" need a linux tape server and veeam b&r would be nearly perfect (minus the bugs of course )

Well, good news then: this feature is one of the top priorities for the Tape R&D team, and they're actively working on this as we speak! We haven't determined the release vehicle yet as this will be decided once they are done with the implementation and QC is happy with the initial state of the feature, but of course our default goal is always the next major release!

[fga]

Yep, that's basically our current approach more or less.

As I've said, the Migration Policy v3 allows migrating up to the certain reasonable VM per Socket density without any questions asked. By the way I'm sorry to say, but 40 VMs per Socket is not a reasonable density when average across our 400K customers is 9 VMs per Socket, and median is 6 VMs per host. However, in addition to that, our sales staff is empowered to be flexible in situations where customers presents a valid scenario to have 40 VMs per socket like yourself. For example, you have some application that spans dozens of virtual Raspberry Pi VMs

Well to be fair: We are not running 40VMs on a 20 Core Cpu. But close to it
at the moment of writing this our cluster runs the following specs:
3 Hosts, 6 CPUs, 72 Physical Cores (12 Per CPU) [so we are not even scratching the 32Core licence limit per socket from vmware]
102 VMs (39/32/31)
So in actuallity we are even slightly over the 1:2 Physical to Virtual Core ratio. (not including HT)
Loads on good days range at about 50% overall across all hosts.
Thats why i said: if i push it i could run 300 VMs on that cluster...

That said: we still have 722 days remaining on our support. so we can wait and see what you do come up with for licence migration.

[mkaec]

I mean, how can you not love the fact that you're protecting 100 VMs today, and can go to 200 VMs tomorrow without paying Veeam extra to cover our 2x increased support costs.

Veeam's support costs are not 2x in that scenario. It's not a linear equation. If my backup server is having problems, it doesn't matter if it's backing up 100 or 200 VMs. If I install an update, I'm still going to only download the ISO once. 1 customer with 200 VMs is must less costly than 200 customers with 1 VM each, and only marginally more expensive to support than a customer with 100 VMs.

[Gostev]

...and neither OP has 100 VM come on, obviously these were all totally random numbers. We do however see support costs increasing linearly depending on the number of VMs protected. This is particularly due much application-specific processing logic added to the product in the past years, which basically allows each individual VM to have backup issues independently of other VMs.

[fga]

So i just came out of a meeting with our CEO...
He was absolutly clear on that: We do not do rental aka VUL period. If Veeam forces us to do rental: search for another solution
All our software and hardware is bought. Bosses have no problem with yearly support fees. But Rental to even access the software itself is an absolute no-go.
The second they hear the word SaaS then the answer is "NO search for something else" 100% of the time.

[Mildur]

VUL is also available in the Perpertual model. That should work like the same as your sockets now. Only a maintenance fee have to be payed each year. The usage will not be blocked with perpertual, if you don‘t pay the maintenance fee.

[rbienvault]

Hello,

Thank you @Gostev for the feedback.

I have one suggestion based on your answer, it is possible to remove the hard limit at 10% more than the amount of VUL that we have, and go on a true-up model where we are on period (every 6 month or every year) basis reviewing what is consumed and if we need to buy more ?
We have the possibility to use that kind of model with other software provider.

Thank you !

[Gostev]

Yes, actually this has always been available with Veeam... it's called ELA (Enterprise Licensing Agreement), you should discuss this with your Veeam sales rep. Although as the name implies, this option is available for larger customers only. Thanks!

[mkretzer]

How large do we need to be for that?

[Gostev]

Absolutely no idea to be honest... and I would not be surprised if it varied heavily depending on the region, so best is to check with your rep. I only know this existed for large customers since the inception of Veeam pretty much.

[somoa]

@Gostev

Do you still have transfer fees when changing from socket to VUL? Last year I was trying to get VUL over more socket but the fee to do so was just silly. It also pushed us to Enterprise + that we did not want/need. This also added to the extra fees.

We ended up just getting more socket licenses due to this.

[ammaross]

Yep, that's basically our current approach more or less.

As I've said, the Migration Policy v3 allows migrating up to the certain reasonable VM per Socket density without any questions asked. By the way I'm sorry to say, but 40 VMs per Socket is not a reasonable density when average across our 400K customers is 9 VMs per Socket, and median is 6 VMs per Socket. However, in addition to that, our sales staff is empowered to be flexible in situations where customers presents a valid scenario to have 40 VMs per socket like yourself. For example, if you have some application that spawns dozens of virtual Raspberry Pi VMs

Wow. Just wow. That's actually very condescending attitude and outdated notion assuming 40 VMs per socket has to be RPis. We have 167 VMs across 5 single-socket hosts, with 32 physical cores (64 threads) per server. That's 33 VMs per socket btw, which is entirely normal and reasonable considering it's only a 1:1 VM to physical core. We foresee being over 200 VMs within a year, hence the oversizing to have 1 VM per two threads currently. Not everyone is running antiquated 10-core Xeon CPUs. We have many application servers that serve just a handful of users in our environment. We have a VDI-type environment of permanent desktops due to finicky end-user software that doesn't like dynamically-created endpoints. These are backed up with Veeam because, why not? If converted, we have to decide if it's worth the extra cost to save us if a contractor or employee destroys their VM or script some VM snapshot rotation mess and deal with the performance impact of running a permanently-snapshotted VM.

Your example of "flying 10,000 miles for the cost of 5,000 miles" is disingenuous as well. For organizations that backup 1,000 VMs, they have dedicated staff to manage those backups. Experts that are likely certified in Veeam. I'd imagine you get less support calls from them than smaller organizations that have the accounting guy that built his own computer managing their backups. I know we've paid for support for years and logged maybe 2 calls in the last 5 years. We pay for support for the patches and upgrades. We have in-house experts that can fix backup problems in-house and it's usually faster than calling for support. Honestly, we also don't really run into large problems because the software is exceptional. So no, it's not flying an extra miles. We're renting a van. It's now not being allowed to take extra luggage in a rental vehicle without paying fees for the additional bags. We can stack the van to the gills with extra luggage, which is why we didn't take the airplane in the first place.

Make no mistake, selecting single-socket servers with high core count was exactly a "get the most for our money" decision, on both VMware licensing as well as Veeam licensing and a whole host of other software that uses per-socket licensing. Also, make no mistake, moving to a VUL model for Veeam is done to better-monetize customers; to get more money per client. That's just the facts of it. Obviously Veeam is a business, not a charity, and needs to cover ongoing costs. This was traditionally done, and acceptably so, through annual (entirely expected!) support cost increases or base license increases for new servers/deployments. However, switching to a VUL model would severely negatively impact our environment for going more efficient and selecting high-core-count, high-density-capable servers. This is obviously a move across a lot of datacenters, and Veeam is losing revenue because of it. Sure, I get that. Your example of VMware's move to 32-core licensing was VMware noticing that future loss of revenue as well. But slapping a VUL on VMs backed up will most certainly cause a migration to competitor software. Other backup vendors aren't "3rd world airlines." Licensing cost shakeups always cause re-evaluations of competitors. Of course, saying someone will jump to FOSS software like Bacula/Bareos/et all is obviously not very constructive, as it's hard to compete against "free" (unless it's on support and features of course ) so I understand that. But if you make the cost too prohibitively expensive, like in our case, and those "3rd world airlines" and "free flights" start to look very reasonable. At the very least, getting quotes from other companies will be a thing that is done come annual renewal, rather than just saying "we've got perpetual licenses, let's just stick with what's worked well for us so far."

Yes, I'm trying to have an open, honest dialogue of constructive criticism, with real numbers and use-cases. Your telemetry stats give you actual numbers for your current deployments, but that data just tells you what people currently do, not what they want to do.

[kabe]

Hello,

I am not 100% happy with the Veeam-only-VUL-way. I am a Freelancer and take care of (small) Veeam environments. I started with Veeam 10 years before. I love Veeam and also like the way how easy Veeam handle the licensing model. In my first years as IT-Consultant we won against other backup-competitors because they focused a payment per TB-model and nobody like it. Veeam (is/) was a no brainer.
Okay... "good old times" stories sucks... I know. We need to change and transform all and everything... It is okay too.

In my opinion VUL is not bad! For those who built an environment in the cloud or have many physical workloads or only a single host with 10 VMs (and need enterprise feature) or or or... But my customers are small and medium and have their systems to 98 % on prem. They have 6 Sockets and definitely a higher density than 6 VMs per socket, otherwise it is not economically for my customers.

At the beginning of my IT-Life many customers didn't backup their whole environment, only the importants (for example 20) VMs. I rather them to backup almost all - blind - because in case of a problem, the restore is quick and handy. I guess I need to recommend my customers to think/count twice.

I will hear the Linux-admins In future: "Let us create one Backup-VM and we make config dumps to this machine and then we have all".
This is not the way I prefer. It was so easy to handle... Maybe you will find a way of coexistence.

Regards
Ps.: Yes, I am still a Veeam-Fanboy

[m.novelli]

Love Socket licenses, dislike VUL. Period.

Marco

[bucoops]

Good Morning,

My employer also wishes to remain on a per-socket model - for example we still run on-prem everything including exchange and our intention is to continue this as long as possible. We very recently replaced our production hosts with single CPU 16 core units - single CPU for Veeam licencing purposes and 16 core for Microsoft licencing purposes. The hosts are running on average 9 VMs each and the limitation is not CPU but RAM so it looks like we are bang on the average that you are seeing, @gostev, but like I say, the limitation on increasing that is RAM not CPU. They are specced so we can lose a host and re-balance the workload without anyone noticing. We could have chosed CPUs with a LOT more cores but then we would have had a huge server licence bill on top and we don't need it.

Incidentally the primary reason for not going away from on-prem is our clients - they insist on their data being stored securely which does not include cloud (aka somebody else's computer) - yes we all know that cloud IS a valid solution these days, but out clients are the ones that pay our bills... Veeam has and will continue to be a big part of keeping our clients' data safe, as long as any price increases on it are reasonable. We don't expect something for nothing of course.

We are only a small customer using Backup Essentials Enterprise Plus (4 sockets) - please don't leave us out in the cold

[Julien]

I believe many SMB who have VMware vSphere Essentials Kit are worried about the VUL scheme.

Veeam is a really great product and, even for small IT teams, maked an outstanding job as helping to ease the backup process.
As such the costs can be justified, but the margin is thin between costs vs benefits.
Anything that makes the costs uncertain or too complitated to forecast within a typical CAPEX period can move the balance against Veeam.
Up to now is was fairly easy for VMware vSphere Essentials Kit users to plan the costs based on sockets, knowing that with the VMware vSphere Essentials Kit it is limited anyway.
It is no longer the case with VUL as on day 1 of acquisition I might need 14 VM (15 VUL) and 2 years later 26 (30 VUL!).

[mazingtree]

The whole process needs to be much slicker. If we want an extra license for say O365, we simply login to the Microsoft Aggregator's (Wholesale) website and add 1 extra license. That automatically adjust our monthly billing from the supplier. The license gets injected into the customers Microsoft tenant account, so within 5 minutes we can have a new O365 up and running, and I just need one email to our billing team to adjust the customer billing. It's extremely frustrating when products have to be quoted, instead of just being able to order them online, as you are stuck if you are doing any work in the evenings. This is made worse because our Veeam supplier has different teams that deal with VCSP licensing v Per socket or VUL licensing. So I send an email, and the email then gets copied round half of the supplier and copied to Veeam Sales. It's very inefficient. I assume our supplier needs two teams because the licensing is so complicated and one person can't understand it all!!

The technical side of Veeam is great, but your licensing and the way it's managed and handled by the software and your suppliers needs a serious rethink top to bottom alongside someone that actually has to make the process work both for large and smaller IT companies like mine. It has just taken a whole half hour meeting with 3 of our suppliers staff (4 people) in attendance just to explain what VUL actually is and how it works when compared to VCSP. It might seem obvious when you know, but the "Marketing speak" wording that describes VUL is very ambiguous and unspecific. It needs an engineer to write some of the wording instead of your marketing people.

Veeam has wasted the most learning time than any other product we supply I think and it's all been on how the licensing models VCSP /Perpetual Essentials v VUL work.
The costs of support for Essentials licenses have increased way beyond inflation too, so we have had kickback this year. Customers have to pay for Essential maintenance yearly, but then have to pay us monthly for the VCSP Cloud Connect licensing.

[chrisO]

Another vSphere Essentials customer here. Nothing particularly new to add to what's already been said, just voicing my agreement. We're a small outfit: 25-ish VMs on a two-server vSphere cluster (4 sockets total), with one weedier testing/backup/emergency single-socket server on the side. Absolutely no interest in going cloud or anything else that VUL enables - we haven't got the money and I haven't got the time (as with many small teams I'm the only vSphere admin in our team, and that's just one of lots of hats I wear). Keeping things simple and straightforward is hugely valuable in its own right to me. Veeam socket licensing matches our vSphere setup perfectly and keeps it simple. You talk about your support costs - what about mine? VUL might be magically wonderful and flexible, but if it takes up more of my time managing or monitoring it, then that's a net 'loss' to me.

I appreciate that you've tried to build some good things into VUL, like the 10% slack, but VUL would still be extra work and an extra complication that I just don't need. Please, please consider keeping socket licensing.

[OrangeWing]

We are not fans of changing from socket based as well as we also have 3 hosts and the small bus Veeam. It works for us and has for years.