Lessons that technology companies must learn from Intel... and VMware

We have seen this far too many times in the IT industry, on how technology companies frequently fall into focusing on the wrong thing (boosting sales over developing better products), hiring and promoting managers who have MBAs, but without technical prowess needed to understand their own products, to direct their businesses and end up destroying their once amazing products, leading their companies on the path toward downhill.

Worse when they have a CEO who is too arrogance to appreciate and listen to their engineering feedbacks, pushing their talented engineers to join the competitors, and enabling their competitors to catch up and even outperform the industry leaders.

Intel is one good recent example. Not only has AMD CPU outperform Intel today, they have none of the embarrassing security problems that experts have discovered in Intel CPUs. Not to mention the workaround security patches will result in even poorer performance of their badly designed CPUs.

Even Apple has decided to stop using Intel CPU for their new Macs. And none of the increasing popular smartphones are using Intel CPU as well. __________________________________________________________

By now, every vSphere customers should have already patched their vCenter against a embarrassing critical security vulnerability from the vSAN plugins, which should not have occurred in the first place, especially for customers who do not even use vSAN at all.

By deploying and enabling optional services that most users do not use by default (and without the need for authentication), just to make them easier and faster to sell and deploy, at the expense of compromising security and performance, is really a stupid business decision made by obviously incompetent decision makers, who do not have the technical background to understand the impact of their uninformed business decision.

"For vSphere users, our full 7.0 U2 support comes at the perfect time too because there was the critical vulnerability disclosed allowing to completely bypass authentication in all supported vSphere versions. This has CVSSv3 score of 9.8 out 10 so it's serious stuff folks, not something you can postpone for later. Everyone is required to act here: no matter which vSphere version you are using, you have to upgrade to the latest build of its branch." - GOSTEV from Veeam

Unfortunately not everyone can upgrade to the latest version asap without breaking something, especially for 3rd party vendor addons. While Veeam manages to get their product updated to support the latest vCenter just in time, but not other vendors such as HPE SimpliVity etc.

Fortunately we have a practical policy of keeping ourselves one step behind the latest version (especially version x.0), to ensure our production environment priority is always stability and reliability first. For why should we become free beta testers to software vendors for their untested new release for? Not to mention paying advanced money to be the first to upgrade to new version filled with new bugs?

This means there is no problem for us to upgrade to the latest 6.7u3n without affecting SimpliVity, since only security patches are released for older versions, not new untested features that might affect and break existing deployment.

I say this again. Optional features (especially those that need additional licenses such as vSAN that SimpliVity users won’t need at all) should be made optional, and not deployed and enabled by default just to make it easier and faster to sell, compromising security, reliability and maybe even performance.

Not wanting to see VMware making the same mistake and went downhill, I made an effort to feedback this concern in the vmware user group forum and suggest that they should stop enabling non-essential services to improve the security of their vCenter product.

To my disappointment, the vmware admin defended this and claim that the problem is with HTML5 and port 443, not vSAN plug-in. This is like having a door lock vendor denying that their faulty lock is a problem and push the blame on the door itself. This is really irresponsible.

On the contrary, HPE may not have always have the best products, but they have a very responsible team who are open to feedbacks, especially negative feedbacks. They take all feedbacks seriously and this is how they are able to improve, earning respect and loyalty from their customers.

This is something that I wish VMware (Microsoft included) can learn from. Instead of listening, they defended bad business decisions and denied bad customer experiences.

Note: In additional of the patch, I have also set the vSAN plugins as incompatible as additional layer of protection, despite it is not required after patching. You never know if there are more security bugs within the vSAN plugins waiting to be discovered in the future, especially with their defensive reaction to my feedback. It suggests that they do not have any intention of not enabling vSAN even for customers who do not need them in the future as well.