The VMware is superior by far IMO because I like to have full control of my systems and roll my own stuff.
This was a strong argument before the Broadcom acquisition of VMware. Have you looked at your renewal costs yet? VMware is a great product but is far less attractive at the new pricing. Every customer I have is asking how they can get out of VMware as quickly as possible because of the new pricing.
Yeah we were hit hard by the cost projections. It really sucks. But HCI stack from MS remains even more expensive. We have decided to bring as much as we can in house and only put the workloads that have strict contractual uptime agreements on our VMware or HCI stack. The rest of the stuff goes on KVM or bare metal to save costs.
We have decided to bring as much as we can in house and only put the workloads that have strict contractual uptime agreements on our VMware or HCI stack. The rest of the stuff goes on KVM or bare metal to save costs.
This is similar to the recommendations I give my customers, but its never this easy.
Entire teams are trained on managing VMware. Years of VMware compatible tools are in place and configured to support those workloads. Making a decision to change the underlying hypervisor is easy. Implementing that change is very difficult. An example of this is a customer that was all-in on VMware and using VMware’s Saltstack to orchestrate OS patching. Now workloads they move off of VMware have to have an entirely new patching orchestration tool chosen, licensed, deployed, staff trained, and operationalized. You’ve also now doubled your patching burden because you have to patch first the VMs remaining in VMware using the legacy patching method, then patch the non-VMware workloads with the second solution. Multiply this by all toolsets for monitoring, alerting, backup, etc and the switching costs skyrocket.
Broadcom knows all of this. They are counting on customers willing to choose to bleed from the wrist under Broadcom rather than bleed from the throat by switching.
We take a cloud agnostic approach to systems development so we have flexibility. Our team is quite small and we use Manageengine for patching servers and Atera for patching users systems. We only use a few cloud native services like AWS event bridge, load balancers, S3, Lambda, Azure DNS, Azure storage, Azure App service. But if needed we could pull any one of those and move to an open source solution without too much fuss. The red tape comes from exec level and their appetite for risk. For some reason they think cloud is more stable than our own servers. But we had to move VMs off Azure because of instability!
This was a strong argument before the Broadcom acquisition of VMware. Have you looked at your renewal costs yet? VMware is a great product but is far less attractive at the new pricing. Every customer I have is asking how they can get out of VMware as quickly as possible because of the new pricing.
Yeah we were hit hard by the cost projections. It really sucks. But HCI stack from MS remains even more expensive. We have decided to bring as much as we can in house and only put the workloads that have strict contractual uptime agreements on our VMware or HCI stack. The rest of the stuff goes on KVM or bare metal to save costs.
This is similar to the recommendations I give my customers, but its never this easy.
Entire teams are trained on managing VMware. Years of VMware compatible tools are in place and configured to support those workloads. Making a decision to change the underlying hypervisor is easy. Implementing that change is very difficult. An example of this is a customer that was all-in on VMware and using VMware’s Saltstack to orchestrate OS patching. Now workloads they move off of VMware have to have an entirely new patching orchestration tool chosen, licensed, deployed, staff trained, and operationalized. You’ve also now doubled your patching burden because you have to patch first the VMs remaining in VMware using the legacy patching method, then patch the non-VMware workloads with the second solution. Multiply this by all toolsets for monitoring, alerting, backup, etc and the switching costs skyrocket.
Broadcom knows all of this. They are counting on customers willing to choose to bleed from the wrist under Broadcom rather than bleed from the throat by switching.
We take a cloud agnostic approach to systems development so we have flexibility. Our team is quite small and we use Manageengine for patching servers and Atera for patching users systems. We only use a few cloud native services like AWS event bridge, load balancers, S3, Lambda, Azure DNS, Azure storage, Azure App service. But if needed we could pull any one of those and move to an open source solution without too much fuss. The red tape comes from exec level and their appetite for risk. For some reason they think cloud is more stable than our own servers. But we had to move VMs off Azure because of instability!