4 ms·

Great description of what a tight-knit, motivated team can accomplish. This seems a strategic exit by VMWare to cede all desktop-hosted virtualization markets

Great description of what a tight-knit, motivated team can accomplish. This seems a strategic exit by VMWare to cede all desktop-hosted virtualization markets to competitors. Probably because that category didn't meet an arbitrary profitability criteria, instead of a customer-focused analysis of what value propositions the product line brought to the table when looked at as a part of an entire picture of all other products offered. Another possibility is VMWare might be defocusing their traditional virtualization and this is the first of an all-in shift to containers because that's a growth market at the moment. Not a few enterprise customers value these "low profitability" product lines, because they promise to lower the complexity of dealing with a wide-area problem space. After IBM ditched their "low-profit" servers, for example, you can find a CIO going on record here and there saying they abandoned their all-IBM-servers policy in their shops. I can assure you there are many more who did not go on record. Applying a single financial metric across all your products loses focus upon what really matters to your customers. It looks great to boost relative margins, though. By jettisoning certain product lines that complemented and completed a market message to your customers, you open up high-margin products to much more effective competitive attacks. It will be interesting to see what VMWare's competitors come up with.

frostmatthew 11y ago
> Another possibility is VMWare might be defocusing their traditional virtualization and this is the first of an all-in shift to containers because that's a growth market at the moment. Supporting container workloads doesn't need to come at the expense of "traditional" virtualization, e.g. see the work being done with vSphere Integrated Containers[1] or AppCatalyst[2], particularly since most (all?) containers ran on cloud providers are running in a VM. N.B. I work at VMware, but as an engineer in a completely unrelated BU I have absolutely no insight into Workstation/Fusion strategy [1] http://blogs.vmware.com/vsphere/2015/10/vsphere-integrated-containers-technology-walkthrough.html http://blogs.vmware.com/vsphere/2015/10/vsphere-integrated-c... [2] http://getappcatalyst.com/ http://getappcatalyst.com/
- walterbell 11y ago
  Is is likely that Hyper-V in Windows 10 or the OS X hypervisor framework will evolve into replacements for Workstation/Fusion?
  - mhurron 11y ago
    That would suck. VMWare Fusion/Workstation/Player mean I can run the exact same VM on a Mac, Windows and Linux without any modification. Having to use VirtualBox over here (which I've had problems with before) and KVM over there and Hyper-V over there and whatever shows up on OS X yet again would be such a pain in the ass.
- yourapostasy 11y ago
  > Supporting container workloads doesn't need to come at the expense of "traditional" virtualization... Absolutely agree with you, I think machine and container virtualization should co-exist in a sophisticated ecosystem and it isn't an either-or. Just as server- and desktop-hosted virtualization should co-exist on another axis of the ecosystem. I lack insight into why VMWare effectively gave up on holding down the desktop end of the spectrum, which essentially tells customers that the capability to scale from desktops to servers is no longer as important to its mission or business model. Perhaps native desktop OS support for virtualization is shaping up much faster and more robustly than we realize, VMWare execs see the writing on the wall and decided to exit the space on a high note instead of fighting future ever-declining revenues in that space, and they will count upon lower-margin solutions based upon native desktop OS virtualization features to address the desktop-to-server scaling issue.
parasubvert 11y ago
"This seems a strategic exit by VMWare to cede all desktop-hosted virtualization markets to competitors." It's more boring than that. They've decided to offshore the jobs. The management probably believes these products are at market saturation anyway, so beyond attrition to container-oriented solutions like Docker, it's not likely Fusion or Workstation will actually go away or feel that different. What's disappointing is that this team could have been everything Docker or Vagrant is - repeatable environments and workflow for developers.
- yourapostasy 11y ago
  There is zero chance the offshore team has the built-up institutional knowledge the original HostedUI team painstakingly accreted over decades to quickly integrate seamless container virtualization into the desktop-hosted Workstation and Fusion products. Not a knock on the offshore team. Even a brand-new domestic team would have zero chance. The container virtualization market is moving fast, so quick, effective integration is required. That's unfortunate. I was looking forward to something like a VMWare Fusion/Workstation-powered session that starts off with a virtualized OS, auto-generates a container configuration file by watching everything you install and detecting what the installed app uses while you run it through its paces, creates and deploys a containerized app, perhaps onto your laptop and perhaps injecting directly into a cloud instance you point to (bonus points for integrated account support and API hooks for customizing the cloud deployment flow or injecting into your Chef/Puppet/etc. infrastructure)...then does it in reverse as well. Or "sync" a container to a virtualized OS version of the app, where you can deploy the full panoply of debugging tools to inspect what is happening on the container in ways that would be terribly inconvenient or not even possible on the container, like using log file analysis tools that wouldn't be on the container. It would take a performance hit, but for some the trade-off might be worth it. Or create an "instrumented" container, that intercepts failed operations like a library missing from the container, which then starts a sync with a virtualized OS version presumably with the missing library that completes the call. The possibilities I saw were endless.

frostmatthew 11y ago

> Another possibility is VMWare might be defocusing their traditional virtualization and this is the first of an all-in shift to containers because that's a growth market at the moment. Supporting container workloads doesn't need to come at the expense of "traditional" virtualization, e.g. see the work being done with vSphere Integrated Containers[1] or AppCatalyst[2], particularly since most (all?) containers ran on cloud providers are running in a VM. N.B. I work at VMware, but as an engineer in a completely unrelated BU I have absolutely no insight into Workstation/Fusion strategy [1] http://blogs.vmware.com/vsphere/2015/10/vsphere-integrated-containers-technology-walkthrough.html http://blogs.vmware.com/vsphere/2015/10/vsphere-integrated-c... [2] http://getappcatalyst.com/ http://getappcatalyst.com/

walterbell 11y ago
Is is likely that Hyper-V in Windows 10 or the OS X hypervisor framework will evolve into replacements for Workstation/Fusion?
- mhurron 11y ago
  That would suck. VMWare Fusion/Workstation/Player mean I can run the exact same VM on a Mac, Windows and Linux without any modification. Having to use VirtualBox over here (which I've had problems with before) and KVM over there and Hyper-V over there and whatever shows up on OS X yet again would be such a pain in the ass.
yourapostasy 11y ago
> Supporting container workloads doesn't need to come at the expense of "traditional" virtualization... Absolutely agree with you, I think machine and container virtualization should co-exist in a sophisticated ecosystem and it isn't an either-or. Just as server- and desktop-hosted virtualization should co-exist on another axis of the ecosystem. I lack insight into why VMWare effectively gave up on holding down the desktop end of the spectrum, which essentially tells customers that the capability to scale from desktops to servers is no longer as important to its mission or business model. Perhaps native desktop OS support for virtualization is shaping up much faster and more robustly than we realize, VMWare execs see the writing on the wall and decided to exit the space on a high note instead of fighting future ever-declining revenues in that space, and they will count upon lower-margin solutions based upon native desktop OS virtualization features to address the desktop-to-server scaling issue.

parasubvert 11y ago

"This seems a strategic exit by VMWare to cede all desktop-hosted virtualization markets to competitors." It's more boring than that. They've decided to offshore the jobs. The management probably believes these products are at market saturation anyway, so beyond attrition to container-oriented solutions like Docker, it's not likely Fusion or Workstation will actually go away or feel that different. What's disappointing is that this team could have been everything Docker or Vagrant is - repeatable environments and workflow for developers.

yourapostasy 11y ago
There is zero chance the offshore team has the built-up institutional knowledge the original HostedUI team painstakingly accreted over decades to quickly integrate seamless container virtualization into the desktop-hosted Workstation and Fusion products. Not a knock on the offshore team. Even a brand-new domestic team would have zero chance. The container virtualization market is moving fast, so quick, effective integration is required. That's unfortunate. I was looking forward to something like a VMWare Fusion/Workstation-powered session that starts off with a virtualized OS, auto-generates a container configuration file by watching everything you install and detecting what the installed app uses while you run it through its paces, creates and deploys a containerized app, perhaps onto your laptop and perhaps injecting directly into a cloud instance you point to (bonus points for integrated account support and API hooks for customizing the cloud deployment flow or injecting into your Chef/Puppet/etc. infrastructure)...then does it in reverse as well. Or "sync" a container to a virtualized OS version of the app, where you can deploy the full panoply of debugging tools to inspect what is happening on the container in ways that would be terribly inconvenient or not even possible on the container, like using log file analysis tools that wouldn't be on the container. It would take a performance hit, but for some the trade-off might be worth it. Or create an "instrumented" container, that intercepts failed operations like a library missing from the container, which then starts a sync with a virtualized OS version presumably with the missing library that completes the call. The possibilities I saw were endless.