Socket Licenses are back??

[Gostev]

Here's the User Guide article about same > Merging Licenses

[Origin 2000]

Most Essentials customer get some VULs for "free" some time ago. It also was possible to buy additional Windows Agents LICs which stops than and the VULs comes into the market. Yes i have some customer which have both... but never combined within a single VR Server installation. They have multiple island which acts independed to each other. Iam very surprised about your comment.

Also most of my customers have old Enterprise Edition and VUL is E+ only which never where able to combined because of different Editions.

Regards,
Joerg

[Gostev]

@Origin 2000 there are no issues with this scenario actually: you can combine a Socket license of any edition with VUL.

[Regnor]

@Origin 2000
@corbitech
With socket licenses, you can't use VUL in addition to backup virtual machines. You'll have to license sockets for all your hypervisors.
So maybe you have this scenario in mind?

[svallarian]

Staying with the socket based licenses is a great help as now, i can just stay with Veeam (even if the price does increase, which is expected anyway for enterprise software), and I don't have to go look at others.

[Origin 2000]

there are no issues with this scenario actually: you can combine a Socket license of any edition with VUL.

With socket licenses, you can't use VUL in addition to backup virtual machines. You'll have to license sockets for all your hypervisors.
So maybe you have this scenario in mind?

Maybe we should ask a 3rd. one or just role a dice to get the final answer

Back to topic.... yes they revert the changes for existing customers with CPU Licenses under a valid SnS but only for Enterprise and Enterprise+ so they can buy additional CPU lics if needed. But they leave behind the customers with the Standard edition.

We got the notification about that 6 weeks ago from the distributor and later from veeam by phone when speaking with my veeam partner representative.

Regards,
Joerg

[Gostev]

My answer was final, but note that we have been discussing the following question all along:

Could you please elaborate on how a customer could manage both socket license workloads and VUL workloads "on the same install"?

Regnor then brought up a different scenario that does not involve "VUL workloads" at all, but rather VMware and Hyper-V VMs only (which are "Socket workloads").

[mkaec]

But yes, we can all agree that Socket licensing is broken and nothing can be done to fix it. Either Veeam will be losing more and more money, or customers will not be happy with its price increases, or both (the current situation).

Veeam could switch from socket licensing to core licensing. A lot of density growth is attributed to increasing cores in CPUs. At least then price increases would be tied to visible hardware change instead of annual maintenance just going up for no good reason (from the perspective of the customer that hadn't upgraded hardware).

[corbitech]

mkaec, your comment hits the nail on the head. I've previously suggested the same thing (tie Veeam perpetual licensing cost to physical core count instead of physical socket count). This would be a reasonable approach, and it's already an established practice in the tech industry (especially for any customers with Windows Server products). I like the Veeam product itself, but I see myself eventually being forced to migrate to another backup solution as the cost of Veeam's perpetual license support cost continually rises.

[Gostev]

...aaaand now we've completed the entire circle most of you have not been our customers for too long to know this, but Veeam did already offer core-based licensing about 12 years ago. We discontinued it after a year or two because customers hated paying higher prices for higher core count CPUs and likewise threatened to leave.

Irrespective of this, while I do agree core-based licensing would make sense if Veeam was a VMware-only backup product, even today such licensing would not apply to a good half of the new licenses we sell - and its workloads coverage gap would only widen every year. So keep this in mind when suggesting ideas for any brand new licensing schemes for Veeam to implement, which are of course very welcome. Ultimately, the only thing we do NOT want is the complexity and overhead of having multiple different, workload-specific licenses. Also, I would say that tying any new licensing to hardware does not make much sense in an increasingly cloud and "as a service" world. Feels a bit like investing into a new fossil-fuel car maker in 2023: by the time they finally start shipping cars, there won't be too many buyers left.

[mkaec]

Having per-core pricing would be fairer than aggressively raising socket prices every year trying to force customers out of that licensing model under the guise of the increased prices being caused by increasing CPU core count.

I have a feeling people interested in hardware-based licensing aren't the biggest fans of the "as a service" world. My experience with "as a service" has been vendors emboldened to raise prices whenever they want because the customer has little recourse. The customer either eats the price increase or loses access to the software and data. SaaS finally solves the problem of customers "skipping versions". I think a better analogy would be comparing investing in a new car manufacturer to investing in a new competitor to Lyft or Uber.

[Gostev]

Having per-core pricing would be fairer than aggressively raising socket prices every year trying to force customers out of that licensing model under the guise of the increased prices being caused by increasing CPU core count.

I agree to this statement unless you are also implying that the previous socket prices by Veeam were "aggressive". Because taking the inflation into account, in my opinion they were not meaningful... at least, they definitely did not consider all 3 factors (not even close):
1. Inflation.
2. Host hardware advancements leading to vast majority of customers renewing much less Sockets every few years (following each hardware refresh) while still running the same number of VMs. Note that this is factually measurable because most customers explain to us openly during renewal when they occasionally renew much less licenses all of a sudden. We've been tracking these under-renewals for close to a decade now and the trend remains super steady.
3. Major releases adding significant value to the product, reducing TCO and/or increasing ROI for customers. All this new functionality requires additional R&D staff to build, support and enhance all new features included in Socket licenses. Meaning, increasing Socket prices slightly with each major release is justified.

But since you like per-core licensing, we can do a quick calculation. Let's take a host hardware refresh cycle of 5 years. Do you agree that it will be quite challenging to buy a CPU that does not have at least 50% more cores compared to CPUs 5 years back? So with per-core licensing, your effective price per Socket would raise by 50% in 5 years just from the core count alone. This is before core price indexation for inflation, which would be additional couple dozens percent across 5 years. I really don't think many would cheer to 75% effective Socket price in 5 years, even if it "would be fairer".

[mkretzer]

The problem is that the "per VM" model punishes companies who use a lot of smaller VMs (like we do) and forces us to change our whole VM strategy. I don't want to change such a strategy because of a backup solution (ok, to be fair, Veeam might be the only solution i might be willing to do this for)!

By making the license dependent on the hardware i would argue its even more cloud-like. In the cloud i can get a VM for 7 € a month and another VM for 567 € a month, depending on the VM hardware. Why should i pay the same backing up a VM which uses 1 TB ram and 32 cores as i pay for a VM with 1 core and 1 GB ram?
And the argument "i don't get CPUs with low core amount" is not entirely correct. We purchase 28/32 core systems for many years now and you can still purchase lower core counts.

Would it not be nice if we could switch a VUL to a physical core license (with a factor if necessary)? It could be optional to limit complexity. You are already doing this with NAS backup (GB per VUL), why not for OnPrem cores?

Markus

[Gostev]

I guess this is exactly where me and you have the fundamental disagreement. This whole notion of per-VM model "punishing" companies for something makes absolutely no sense to me. Because with this model, you pay Veeam EXACTLY for what Veeam does: protecting your VMs, and according to the very number of VMs you are protecting.

I would argue there's actually no licensing model is more logical for a VM backup solution, than by the number of VMs. Wow, honestly I don't even know how one can possibly argue the previous statement? Even our support costs are directly proportional to the number of VMs you're protecting, and not some other random parameter.

But clearly you have a different opinion, so we can just agree to disagree and move on at least now we know what is it exactly we disagree on.

Ultimately, one thing we can be absolutely be sure of is that per-VM licensing model is not somehow fundamentally broken. Because this is the only model that has been available to our service provider partners since the inception of this program well over a decade ago. Our VCSP partners never had access to Socket-based licensing to start with, while the Rental licensing they are required to use is effectively per workload just like VUL. Yet, VCSPs remain our fastest growing business all these years and by now represent a huge chunk of our revenue. And their growth just keeps accelerating every quarter. Would this be even possible if per-VM licensing was not a reasonable approach for VM backup? I don't think so.

[mkretzer]

@Gostev so you are saying that a 30 GB Windows VM with nothing but a NTFS filesystem causes the same support effort as a 30 TB Oracle database server with log backup, very special security policies and ReFS filesystem with deduplication?
Not every VM is the same. And most of the time bigger virtual hardware = more complex setup, more problems. But maybe i am totally wrong here!

Your model is not generally broken, in fact i believe it is "ok" for many companies, that's why i suggest to give the more "special" users a option to use VUL for cores as you do with NAS backups (VUL = X TB). That way you have only one model which is usable for all kinds of "problematic" users (as we are ).

[Gostev]

@Gostev so you are saying that a 30 GB Windows VM with nothing but a NTFS filesystem causes the same support effort as a 30 TB Oracle database server with log backup, very special security policies and ReFS filesystem with deduplication?

No, of course I did not say anything like that

What I said is that outside of low end, our support costs are largely proportional to the total number of VMs in the environment, as opposed to some other parameter like the number of Sockets. Sure, there are always some extreme VMs in any environment, but in larger environments this all averages out as "simple" VMs are still predominant.

To better explain what I actually said, let me try to take it to the ridiculous extreme, just to more easily demonstrate the support costs issue with the Socket licensing.

The following two environments will have the same support costs for Veeam:
a) 1000 VMs on 50 hosts with 2 sockets each (100 Sockets total, 10 VMs per Socket)
b) 1000 VMs on 1 host with 2 sockets (2 Sockets total, 500 VMs per Socket)

Now, if the environment (b) is licensed per Socket, as you can imagine Veeam would be losing tons of money, as licensing costs of those 2 Sockets would not even remotely cover our Support costs.

And sure, it looks crazy now... but wait 15 more years (Veeam is 15 years old now) and 500 VMs per socket will be nothing special then

[Gostev]

i suggest to give the more "special" users a option to use VUL for cores as you do with NAS backups (VUL = X TB). That way you have only one model which is usable for all kinds of "problematic" users (as we are ).

I agree with this 100%: "special" users should be given "special" licensing options. Otherwise it's no different than trying to design a shoe that fits everyone. Never going to work.

I'm not thinking a hardware connection though... I truly hate the idea of even discussing hardware component-based licensing in 2023. But I can imagine stuff like:

a) Custom workload weight matrix on the Veeam licensing server for the specific customer, allowing Veeam Sales person to set cheaper fees for particular workloads. For example, cheaper per-VM fee because of the sheer number of small VMs the given customer has due to their special business requirements.

b) Completely custom licensing options like per-frontend TB (production storage), per-backend TB (backup storage), etc. when it's a customer's preference to license our product in this particular way.

I think this might very well be the direction where we take our ELAs (Enterprise Licensing Agreements) going forward. At least I suggested something like this internally not so long ago. This of courses means moving all licensing logic to the Veeam licensing servers, with the product now merely reporting usage - and customers billed based on this usage per agreed-upon custom licensing fees matrix.

[mkaec]

I agree to this statement unless you are also implying that the previous socket prices by Veeam were "aggressive".

I'm basing my comments on the previous statement of "Socket prices will continue to be indexed annually to account for the growing VM/Socket density and high inflation". That statement says to me that prices are going to be increased based on hypothetical hardware improvements each year regardless of if the customer actually obtains any new hardware. Given the stated goal of completely eliminating socket-based licensing, it's not a big leap to think that prices will keep being raised until socket-based licensing is simply more expensive than VUL.

The old adage is "you get what you measure". If enough things go to per-VM pricing, we'll be back to the bad old days of stuffing everything into a single server. Virtualization allowed simplifying management by putting services into their own containers. Instead of having an SQL server, a file server, a web server, and 2 application servers, we'll see things go back to all of that in one VM. You'll be supporting backup of an extremely complex VM instead of 5 simple VMs.