VMware: Protecting their turf or their customers?

I think most of the people up in arms over VMware's dealings with Veeam last month (the story broke here) are missing a very important piece of the puzzle.  The folks at Palo Alto are looking out for their customers in an important way, and aren't getting nearly enough credit for it.

Since early June there has been some uproar in the VMware community about VMware's request to have Veeam's Backup stop supporting a method of using host-level backups with ESXi when ESXi isn't licensed for VCB.  There has been plenty of discussion from more prominent voices than mine (Mike Laverick, Alex Barrett, and Rich Brambley) regarding whether or not supporting host-level backup of guests is a good idea.  For the record, I think that is a basic feature that should be included in ANY hypervisor, and placing it in the value-added space is a bad move.

It is also apparent that Veeam was doing its customers a disservice, and VMware was doing their customers a huge favor by being up-front about their strategy and talking to Veeam about this.  The reasons for this become clear if you take a deep breath and take a look at the sequence of events:

1. VMware provides documented & supported APIs to partners, along with a commitment to ensure feature updates and patches don't break them.
2. Veeam markets & sells software for ESXi that does some useful things using undocumented & undisclosed methods outside of the supported APIs.
3. Customers buy Veeam's product and build production solutions based on it.
4. VMware sees this as a problem, and asks Veeam (perhaps forcefully, we don't know) to back off & only use supported APIs.  
5. Everyone (it seems) gets angry at VMware.  

Am I missing anything here?  Am I the only one that thinks Veeam made a big mistake in step #2?  It seems like a horrible idea to use unsupported APIs in a backup product.  If there is one place I want a guarantee that everything is supported and will work the way I expect consistently, its in my backup software!  Once #2 occurred, VMware's options were limited to calling Veeam on it and asking them to stop, or risk having customers be unable to perform disaster recovery because a patch broke Veeam's secret method.  If I were a customer caught in this mess, I would take the "VMware steps in" option any day.

A few years back I looked at VDI alternatives for nationwide desktop replacements for an employer.  The CIO's favorite vendor did magical things with sharing physical XP workstations, that looked great on paper.  Picking apart their .msi files revealed they did it by shoe-horning a Microsoft terminal services .dll from XP's beta days onto current installations.  I told management there was no way I could sign off on it as a technical solution, because every Microsoft hotfix might break it (ignoring the ugly licensing issues).  Worse yet, our Microsoft TAM confirmed off the record that if we had an issue Microsoft would tell us to take a flying leap.  Short-term the solution looked good, but long-term it would have been a mess that could have crippled the business.

Excluding VCB support from the no-cost version of ESXi may be a strategic mistake on VMware's fault, with long-term implications for the company.  If I were a customer using Veeam's Backup, I'd be more worried about the short-term implications of depending on backup software that could potentially break at when you need it most.  If you have been complaining about VMware's strategy, I hope you continue yelling about it until they do something more sensible.  If you are unhappy because your investment in Veeam's Backup is a dead-end and you just realized your DR strategy isn't as reliable as you thought, you should be complaining about Veeam, not VMware.

Comments

[Anton Gostev]

Re: #2 - I personally disagree with this concolusion. It has been a common practive last 10 years of software development industry. All innovative vendors have been using undocumented APIs and approaches all this time. In most cases, you can do very little with public APIs.

For instance, Vizioncore vRanger hacks VMware VCB modules by injecting own code into those to enable VCB differential. Not just this is about using unpublished API for VCB framework interaction, this actually changes VMware-designed VCB logic and execution flow... yet, this fact did not prevent them from successfully selling the solution for years.

[denial]

I am not agree with this approach.Because software industry has been using this strategy from many years.web design is helpful to create a great website.

[web development]

I am not agree with this decision.web development is a dynamic skill.