VMware is also scared of SDNs and public cloud infrastructure. They try to remain relevant, and they may have an easier path forward than Dell and HP, but their business model is built on virtualizing old Windows boxes. It's the stepping stone for businesses as they virtualize their infrastructure. Just move off physical boxes and into the VMware cloud.

But that's quite different from native-cloud applications. Right now you may need to incorporate VMware in your deployment toolchain, but it won't stay that way forever. None of the big public clouds (Google, Amazon etc.) run on VMware, and I wouldn't want to bet on internal virtualization infrastructure going the other way.

Furthermore, integrating anything VMWare without paying extra for their (clunky, limited) solutions is painful.

I say this as someone that's writing a deployment toolkit for internal use. Their API is an ill-thought-out, illogical, and painful mess, and the more cynical side of me believes it to be that way on purpose. It's harder to get commoditized if you're harder to interop with.

Then again, it could just be cultural. It took years of people complaining about the awfulness of their web based admin tool before they decided to take those complaints onboard and deal with them; and those were the admins who have to use the thing every day, a much louder and larger group than annoyed developers.

Have you checked out tools such as Ansible and Salt? They've done a lot of the hard work for many common operations in vsphere.

http://docs.ansible.com/ansible/vsphere_guest_module.html

https://docs.saltstack.com/en/latest/ref/clouds/all/salt.clo...

Believe it or not, Ansible is what I'm using right now. Except wrapping a friendly web-app around the deployment bits.

My hat is off to their developers, about an hour of dealing directly with VMWare SOAP API was a prelude to a migraine.

They've actually started their own public cloud claiming to directly compete with Azure and AWS: http://vcloud.vmware.com/