Phasing Out our Socket-based Licensing

[ejenner]

I guess what's going to happen with Veeam will be similar to what has happened with other buyouts over the years. The 'investors' will find a way to milk the cow to death. When it dies they'll have a lot more 'milk' than they would've had otherwise, it'll be more profitable to get another cow than to have kept the old one going longer just for the nostalgia. I doubt whether anyone who works at Veeam will be able to stop that happening whether they have sound reasoning or not. Once the engines have failed it's very difficult to get them restarted so best to prepare for the most comfortable possible crash landing.

The first customers to take flight will be the small guys watching their costs. Then the large customers who carry out periodic reviews of their arrangements with suppliers, they won't be able to justify the higher cost when there are scores of rivals out there. Last of all will be the gigantic corporates who don't care about money at all, they may not ever change their product and this will keep Veeam alive as a name for however long.

I think anyone looking to justify cost increases must bear in mind many customers already consider Veeam expensive to begin with.

This episode reminds me of the time I raised an objection to the massive license consumption of the (then) new File Server backup function. I've essentially been told I was incorrect, mine is just an exceptional case so Veeam did nothing wrong. My response is simply not to use that feature if nothing is going to change.

To understand what's going on you have to take the view that the new owners of Veeam see their time with Veeam as a temporary involvement, take out as much as possible.. then move on and buy another company... maybe not a backup company... maybe something else entirely... do the same again.

The perfect analogy for this scenario isn't about taking a flight of possibly 5000 miles or 10,000 miles for the same price. It's better illustrated by the story of what happened when Saab was bought by GM, hollowed out and sold as a bankrupt shell which was no longer able to make any cars.

[dsegel]

Another point - surely not every client is moving to the cloud. For those of us (small business sized) who won't, this is a negative change for us.

[jvlad]

Every time you think you have a way to save some money, someone has to come around and ruin it because they want a bigger piece of the pie now.
I'm with the leave things alone gang of this conversation thread.

And I'm especially the "chrisO", we are a small IT team and wear many hats and this will add an extra layer of complexity in managing Vm and sourcing/dropping licenses when needed.
I also backup multiple VM that are not powered on as well for various reasons. Will I need to keep paying for these VM even though they are powered off, but i need them backed up to repository and tape every night. Yeap our standard is to put everything on tape every night.

[nmdange]

I can understand the stance that per-socket licensing has some problems given the increase in compute power per socket. But I'd rather you move to per-core licensing the way Microsoft has, rather than completely phase out this style licensing. It's much easier to pay for licensing to cover a given hypervisor host at the time of purchase, rather than something much more unpredictable like number of VMs.

[tommls]

I'm surprised not to see any mention herein of Veeam sales staff claiming that once one chooses an expen$$$ive VUL bundle to buy, with whatever minimal "perpetuity" discount is involved -- that one must agree not to ever buy *fewer* VUL licenses.

e.g. we buy 70 VUL licenses to cover the various VMs involved...we're supposed to agree to always pay for 70 VUL licenses

I think this is a sleazy tactic to force getting more money from customers.

Please clarify why this sleazy sales tactic is even being done in the first place...considering how flawed your VUL licensing is to begin with, considering all the objections in this thread.

[JRRW]

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

Sorry @Gostev but this is something you need to understand: VARs are a PITA to deal with from an IT guy perspective, more so when we have to go through 40 hoops of redtape. Yes it's nice that we have 'flexibility' but I already run into this headache with VBO - every time I have to add 100 users or 10 users, it's a pain to deal with.

The UX needs to be improved on your side if you're going to push VUL. I'd love to see something closer to the way Microsoft 365 has this option in their portal where we can perhaps 'connect' to a VAR with an on file payment system, to our Veeam License Portal and let us 'clicky click' to the number we need/want and have it spit us out a license (even if it takes X amount of time to generate)

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

That's a great analogy - though it doesn't address most of our main concerns of OpEx vs CapEx.

Some businesses simply are not designed on the accounting side to accommodate huge Opex increases. Yes that's as much an accounting issue as an IT, but it's something I'd recommend you try to build use cases / white papers / 'helpful hint' material around for your sales team.

How large do we need to be for that?

(Michigan region) in 2018 I couldn't get an ELA/EA unless it was a total net-add of 100k.
We did something like 30-vmware and 20 hyper-v or such upgrade from Ent to VAS + renewal, and I remember we actually had an ROI of a little over 24 months vs normal licensing (we were going to do VeeamONE anyways so the VAS helped that for us)


At the end of the day it's a paradigm shift the entire IT world is facing. Security software has gone almost entirely opex as well, even Storage is going to a SaaS.

So I get it. You're not just 'following' along blindly, it's sort of a forced market change.

@Gostev I won a USB HDD (which died a year later ironically) from you in 2018 at VeeamON Chicago for asking one of the 'best' questions, and it was on how the merge of Socket/Instance licensing would go in regards to the technical / UI side - so this has been a 'known' change for at least 3 years. It was a PITA then and it still is now even on managing instance vs socket (mostly because of your TOU changes that stopped us from backing up a single VM on a hypervisor under an instance license) but it's really going to be all about how Veeam communicates.


Communication and providing 'easy button' migration is going to be key - both on the technical side, and on the financial/accounting side - to keep people from just saying 'screw you' and buying a Unitrends or Datto capex.

(okay really no one is going to do that but it's a funny statement)

On that note - thank you as always for engaging with the community in the forums. That is something I'm not aware of any other major software/hardware vendor offers - a community presence that listens, and communicates directly in this sort of fashion.

Cheers.

[Gostev]

No problems, always here for you and thanks for some good ideas above! I see what you're saying about dealing VARs...

That said, I think I should remind everyone that this thread was started based on me saying the following in the weekly newsletter:
"It is extremely important for us to have a solid migration policy from Sockets to VUL that most customers are comfortable with, before we can start phasing out our Socket-based licensing."

As you can see, the second part was brutally taken out of context despite its dependence on achieving the prerequisite.

We will be able to discuss "start of phasing out our Socket-based licensing" part IF and when Veeam actually decides to go this route, making the corresponding announcement. But the truth is, nothing is decided in this regard yet. Yes, I personally am convinced this has to happen sooner or later, simply because socket-based licensing is not cloud-ready. I admit it may take many years before said "cloud readiness" becomes an important factor for some of our customers, even if it is an important consideration already for other (so much they include this into the RFP). I do also fully understand why folks with 100% of their workloads running in an on-prem vSphere cluster could not care less about it, at least today. However, seeing where the industry is going overall, I truly believe most of them will be forced to change their perspective towards this some years from now.

Now, there's in fact an immediate and much more pressing issue with the Socket-based licensing that Veeam is facing, which may very quickly run our flight into the ground: the ever-increasing workloads density per hypervisor socket. This issue is very real and easy for our finance people to see, simply because many of you are renewing less and less sockets while clearly stating the reason being "consolidation of the existing environment on fewer of more powerful hosts". Somebody implied above that worrying about this situation somehow indicates "investors milking the cow", which I find to be a really strange interpretation? I would expect any business at all to be alarmed seeing their customers needing to renew less and less licenses every year to run more and more workloads, no? Simply ignoring this issue is hardly an option for any business, whether they are owned by investors or privately held.

Anyway, I did also see at least a few posters agreeing with this to be an issue from Veeam perspective. However, as I and some other have noted, solving it does not really require the discontinuation of the Socket licensing: Veeam could instead choose to index the Socket license price annually to account for increasing workloads density, or take VMware's approach of doubling Socket price from certain CPU cores count, or something along these lines - effectively keeping the price per workload more or less the same.

But to me, all of these considerations naturally make VUL a better choice for the longer term, because with the same effective price per workload VUL gives full license portability. Many of our customers are also seeing this, and moreover have an environment where VUL makes more sense from every perspective (I mean, HALF of all vSphere hosts out there run 6 or less VMs per Socket, just do the math). However, they are not necessarily happy with our VUL Migration Policy terms. So, my main ask was to keep feeding us the feedback on what doesn't work well with the current V3, any fine print that doesn't make sense etc. Then, we will be able to address these items in the following iterations of the Migration Policy, in which case everyone wins imho. You may not want to migrate now, but can be in a very different situation 5 years from now.

[mattmcg]

Also adding my tuppence worth here.
Beam is an awesome product. But if VUL is the only way forwards then my employer will be looking to change backup software in our next uplift (150 days time ish).
I can’t believe the 9 VM per socket quote you mentioned.
We have 3 x dual socket (20 core) cpu servers.
At present we have one spare as our failover/dr site, and are currently running 150 VMs without breaking a sweat.
150/4 != 9
I would prefer if the VUL was aligned to CPU core count instead of per socket. As I very much doubt we will buy any new servers until the ones we have start to drop like flies.
If we wanted to max out our hardware then we would have to have (rough estimate given our expected workloads) 250-300 VMs over 4 sockets.
Also, as a software development house we have customer projects that run for different contractual lengths of time.
However, we are required by contract to ensure backup retention for 3-5 years.
Generally this means that today we could have 150VMs, tomorrow we could have 250VMs but the day after we could have 120VMs.
How could VUL work for an SME with an extremely agile work ethic?
I would be happier for veeam to make the socket license map to a given host (we have other software like that which requires registering a machine ID).
That would reduce the risk to you guys for any hardware upgrade that would condense out compute ability.

[m.novelli]

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.

Totally agree, as a reseller the Microsoft CSP program and other vendor MSP programs shine (Trendmicro, for example)
VMware and Veeam license selling model are still in the stone age, I've told this many times to my Veeam accounts

Two months ago I started a move from Veeam Backup for Office 365 to Acronis Backup for Office 365 mostly because of MSP autonomous licensing model with Acronis, monthly billing, and worry free cloud to cloud backup...

Sorry Veeam, you are missing some big points here

Marco

[anglerzac]

22 sockets, enterprise, education establishment (can't remember if Veeam offered a discount for that)

My VAR said VUL will mean enterprise plus upgrade cost, we have no need or want of that cost.

Somewhere in this thread you said 9 vuls offered per socket, we're running average 16-17 per socket so thats a no go for a start.

Also being in local government CAPEX is requirement, the maintenance increases are bad enough that we always try to wrap them up for as long as possible.

Leave our sockets alone!

[tommls]

WHY is Veeam sales staff telling me I must buy X vul licenses?? -- AND then never pay for less licenses again??
Even if for example we buy 50 VUL licenses now and then maybe later we only need to use 30 of them, sales would be insisting we always must pay for all 50 licenses...
This doesn't make any sense!!
Makes a very good case for buying different backup software that works with Exagrid.
Thank you, Tom

[JRRW]

Anyway, I did also see at least a few posters agreeing with this to be an issue from Veeam perspective. However, as I and some other have noted, solving it does not really require the discontinuation of the Socket licensing: Veeam could instead choose to index the Socket license price annually to account for increasing workloads density, or take VMware's approach of doubling Socket price from certain CPU cores count, or something along these lines - effectively keeping the price per workload more or less the same.

Damned if you do, damned if you don't. Veeam could instead go the route of Microsoft and keep 'perpetual' licensing but make a 'socket' be 8c/16t (after all, that would align with Microsoft's view) and make people mad about that

I think people really need to understand what you're saying there - the nerds in us are all drooling over Epyc Milan's 56 core insanity, and Ice Lake Xeon's 40 core Plaid Speed Platinum's - until we realize that every single software vendor is adjusting their licensing to account for this. Veeam, has not. You've held out longer than anyone else to my knowledge. Oracle, Msft, VMWare, the list goes on.

And this isn't a new thing. It's been over a decade that people have been reading the winds that socket based licensing isn't going to work (unless you really want a crazy per socket cost)

Yeah, I'm 100% positive we're going to get pushback and I'm equally 100% positive that Veeam will have SOME incentive to help. These conversations are great for that reason, getting everyone's viewpoints and pro/cons.

While I respect other people feeling the same way and just saying 'we won't do VUL', that sort of response is not productive towards a resolution.

Heck I'd go so far as to say that it's not improbable to have Veeam work with an accounting guru to make business use cases / white papers for SMB, MSP, etc users - who might not have their own Accounting guru - on how you can best present and handle the shift.

[Gostev]

Thanks @tommls, this is exactly the kind of feedback I was looking for!!

WHY is Veeam sales staff telling me I must buy X vul licenses??

This was how the original Migration Policy worked: customers migrated their Sockets to VUL using the specific multiplier. But based on the feedback from customers like yourself, we already changed this, so it is no longer the case with the current Migration Policy v3. With the currently active policy, you just tell us the number of workloads running on your licensed Sockets, and get the corresponding number of VUL licenses.

-- AND then never pay for less licenses again??

I looked through the Migration Policy, and it's not exactly what it says. Rather, it says that Veeam "reserves right" to review the discount in case you downsize. Looks like some legal language added by our lawyers (I actually did not even realize it exists). I also don't find this language extremely useful, as I expect VUL downsizing to be quite rare event anyway. And since it is causing concerns, I asked that they simply remove this provision with the next Migration Policy update.

[tommls]

Hello Gostev,

I love your newsletter.
Your newsletter rules.
I wanted to remember to compliment and thank you for your newsletter.
It is the best newsletter I get from any source...except Heather Cox Richardson's newsletter, the only exception I make to my comment here.

Thank you for replying to me.
Thank you for clarifying the VUL license quantity.

I don't think the discount should change according to the quantity though.
A specific current customer perpetuity discount should apply according to the quantity of licenses, for example 10-50 licenses 15% discount for any order/renewal in this range, 50-100 licenses 20% discount, 100+ 30% and no higher ever. Please keep it simple.

I think for this year we are going to stick with socket licensing to have more time to think about the VUL licensing since I can actually foresee decreased VM usage with going to SaaS (not necessarily Azure/AWS virtual servers) for more things than we do now. I don't think people should be penalized for wanting to decrease their VUL license count, if ever.

Thank you, Tom

[lhan]

Please do not Phasing out Socket-base Licensing,
We have 70 esxi server; VMs comes and goes all the time (also for updates). With item based licensing we have to manage this and this ist extra work, we dont like this.

[lolbebis]

There is some big advantages with socket licensing.
It is easy to manage, buy a server, buy ESXi license, buy Microsoft datacenter license, buy Veeam and you are ready to go.
If you think socket license are too cheap raise the price so that 1 socket license = 20 VUL but don't remove that option.
And limit them to 32 cores like VMware.

We have backup jobs that backups every vm created, zero risk of forgetting to add a new server to a backup job.

Switching to VUL would immediately mean to remove every test/dev server from backups and to choose for every new server does this server need backups?
Servers will be missed to be added to backup jobs.

We have already given up on using Veeam for file backups due to VUL licensing, our goal was to consolidate to one backup platform.
But when quoting Veeam for backing up our Netapps with 80TB data.
The quote from Veeam was 5x the price of our current file backup solution which is one of the other in the gartner top quadrant.

[ChrisGundry]

It is easy to manage, buy a server, buy ESXi license, buy Microsoft datacenter license, buy Veeam and you are ready to go.
If you think socket license are too cheap raise the price so that 1 socket license = 20 VUL but don't remove that option.

I agree... We like to work this way and license everything together at the start and forget about it. If we a have to keep adding/removing licenses (our numbers go down as well as up!), then it will be a nightmare for us and will be looking for other products. Add in the fact that we are also provisioned for more VMs vs CPUs than the VUL model would like, this won't work well for us financially either.

I understand the issue Veeam faces and understand why they are taking these steps, but I don't think forcing your customers to VUL is the solution.

[Gostev]

From your perspective, what would be a good solution?

[m.novelli]

I love socket-based perpetual model for On-Premises workload

Subscription licenses are becoming boring due to every Company in the world switching their business model to "subscriptions". Personally I gain quite a lot from subscription licenses but I don't see a long life for them with actual pushing to increase every year price/functionality , aka "Premium" upgrades.

End-users are tired to pay more every year, remember the 80/20 proportion. Personally I'm upgrading some customer to Veeam Enterprise Edition only to have export to Cloud functionality, I'll never use any other functionality nor use more than 30% I think of functionality in Veeam Standard Edition

Marco

[Gostev]

Subscription licenses are becoming boring due to every Company in the world switching their business model to "subscriptions". Personally I gain quite a lot from subscription licenses but I don't see a long life for them with actual pushing to increase every year price/functionality , aka "Premium" upgrades.

Then we're back to a misunderstanding that VUL equals Subscription. This I already addressed earlier in this thread: this is simply not so, as VUL is also available on a Perpetual contract.

[m.novelli]

That's only a matter of time before Veeam switch from Perpetual to Subscription

[Gostev]

Except the time goes into an opposite direction with Veeam

What I mean is that originally and for very many years, VUL (and it predecessors) were Subscription-only.
And only most recently, less than two years ago, we have decided to also introduce the Perpetual option.

[alpha1]

The last time I asked for prices, it made me realize that you need to reach a minimum of VM/Socket ratio to make the Socket licensing less expensive than VUL.
For me, Socket-based licensing is more for big datacenter/cluster and VUL for small infra/branch sites.
I don't see why Socket and VUL can't work together in an efficient way to maximize cost savings.
What we need, in my perspective, is an easy way to assign the correct license to an ESXi host, to determine if we are in Socket or VUL Mode.
The current Enterprise Manager could be updated to include this new feature. It can also be included in the standard Veeam admin console, for smaller installations.

[Regnor]

Years ago, before there were instances and VUL I was hoping that per-vm licensing would be introduced, so that smaller or distributed environments could get licensed in a cost-effective way. I’m not sure where I’ve read this statement, but I remember that an argument against per-vm was, that sockets give you flexibility to backup what you want; per-vm would mean that at some point you could decide against backing up some systems because of the licensing costs. (now it’s the other way arround )
Then VUL came and offered customers the flexibility lo license in that way, which made sense for an environment.

Going away from socket-based licensing means losing some of the flexibility, like others already wrote. Some customers will have to decide whether they want to backup a system and reorder licenses, or whether they will just leave it without a backup. At the end IT will save costs/licenses and decided to only backup what’s really important, and rebuild other less important systems.
Also many customers don’t need the feature set or support level of a VUL, so why pay for something you don’t actually gonna need?
Of course there are customers which will benefit more from VUL, but that's the key; choosing what fits best for your environment (or better, having the choice to choose).

I’m not sure what the best way for both the customers and Veeam will be.
I personally would like to keep the licensing where it was for SMB or Essentials customers; both socket-based (Standard to Enterprise Plus) and VUL-based (Essentials). If Veeam wants to go full VUL then I would suggest to raise the maximum workloads for essentials packages; 100 would be sufficient for most SMBs I think.
For customers above that level going with Enterprise Plus or regular VUL could make sense, and the costs/differences won’t matter that much. So I don’t see a problem there.

By the way, how long can you exceed a VUL license (both technically and legally)?
When do you actually need to license additional VULs?

[Gostev]

For me, Socket-based licensing is more for big datacenter/cluster and VUL for small infra/branch sites.
I don't see why Socket and VUL can't work together in an efficient way to maximize cost savings.
What we need, in my perspective, is an easy way to assign the correct license to an ESXi host, to determine if we are in Socket or VUL Mode.

I think you just explained exactly why they can't work together well. Because if they do, customers will cherry-pick licensing for each situation and each host based on its density and renew less licenses, which will cause Veeam revenue to drop as the result. Which will in turn force the owners to start changing the very core things about the company to save the profitability situation - and these changes rarely mean good things for customers and partners.

Current prices for both VUL and Sockets are specifically coordinated around industry-average VM density, and our customers have to choose either one or another licensing approach. Then, no ability to cherry pick results in the expected/planned levels revenue. So, to allow for cherry-picking within the same environment would require increasing both VUL and Socket price significantly to cover the losses from this flexibilty.

[Gostev]

By the way, how long can you exceed a VUL license (both technically and legally)?

Indefinitely.

[Regnor]

Well that provides some flexibility and removes some of the stress if you exceed the licensed VUL.
I didn't know that and only had read the theory in the docs.

An increase in the number of protected workloads is allowed throughout the duration of the contract (license key).

I translated allowed with technically possible.
Perhaps you should emphasize that fact a bit more; not because one could order less then necessary, but rather because of the fact that every single exceeding/violation doesn't mean that you have to get into the sales/order process.

[pirx]

We have vSphere stretched clusters so most of our clusters have 50% free resources. What number of VUL licenses would be we get in this scenario? The number of VM's we currently could run with our licensed sockets or the number of VM's we're currently running?

Edit: Where can I find anything about Migration Policy v3? Or migration of licenses at all?

[Gostev]

50% utilized Sockets sounds like a perfect fit for VUL

Normally it's the total number of VMs you are currently running, including those you are not currently protecting with Veeam.

There's no public documentation about Migration Policy v3. You will need to discuss your situation with Veeam sales rep, as migration terms dependent on things like the product edition and the current density. I remember seeing a huge discount matrix depending on these factors to transform the remaining value of the perpetual license into a multi-year discount on Subscription, which ensures you're not paying more annually than you are now.

So worth checking out. You don't have to migrate if you don't like the proposal - but this gives us additional input to further improve the migration policy.

[pirx]

I was confused because we got an offer which included just the VM's we are currently running. This looks like a nice deal for Veeam but not very interesting for us.