We get this all of the time in IT, a vendor tells us that a system cannot be virtualized. The reasons are numerous. On the IT side, we are always shocked that a vendor would make such an outrageous claim; and often we are just as shocked that a customer (or manager) believes them. Vendors have worked hard to perfect this sales pitch over the years and I think that it is important to dissect it.
The root cause of problems is that vendors are almost always seeking ways to lower costs to themselves while increasing profits from customers. This drives a lot of what would otherwise be seen as odd behaviour.
One thing that many, many vendors attempt to do is limit the scenarios under which their product will be supported. By doing this, they set themselves up to be prepared to simply not provide support – support is expensive and unreliable. This is a common strategy. It some cases, this is so aggressive that any acceptable, production deployment scenario fails to even exist.
A very common means of doing this is to fail to support any supported operating system, de facto deprecating the vendor’s own software (for example, today this would mean only supporting Windows XP and earlier.) Another example is only supporting products that are not licensed for the use case (an example would be requiring the use of a product like Windows 10 be used as a server.) And one of the most common cases is forbidding virtualization.
These scenarios put customers into difficult positions because on one hand they have industry best practices, standard deployment guidelines, in house tooling and policies to adhere to; and on the other hand they have vendors often forbidding proper system design, planning and management. These needs are at odds with one another.
Of course, no one expects every vendor to support every potential scenario. Limits must be applied. But there is a giant chasm between supporting reasonable, well deployed systems and actively requiring unacceptably bad deployments. We hope that our vendors will behave as business partners and share a common interest in our success or, at the very least, the success of their product and not directly seek to undermine both of these causes. We would hope that, at a very minimum, best effort support would be provided for any reasonable deployment scenario and that guaranteed support would be likely offered for properly engineered, best practice scenarios.
Imagine a world where driving the speed limit and wearing a seatbelt would violate your car warranty and that you would only get support if you drove recklessly and unprotected!
Some important things need to be understood about virtualization. The first is that virtualization is a long standing industry best practice and is expected to be used in any production deployment scenario for services. Virtualization is in no way new, even in the small business market it has been in the best practice category for well over a decade now and for many decades in the enterprise space. We are long past the point where running systems non-virtualized is considered acceptable, and that includes legacy deployments that have been in place for a long time.
There are, of course, always rare exceptions to nearly any rule. Some systems need access to very special case hardware and virtualization may not be possible, although with modern hardware passthrough this is almost unheard of today. And some super low latency systems cannot be virtualized but these are normally limited to only the biggest international investment banks and most aggressive hedgefunds and even the majority of those traditional use cases have been eliminated by improvements in virtualization making even those situations rare. But the bottom line is, if you can’t virtualize you should be sad that you cannot, and you will know clearly why it is impossible in your situation. In all other cases, your server needs to be virtual.
Is it not important?
If a vendor does not allow you to follow standard best practices for healthy deployments, what does this say about the vendor’s opinion of their own product? If we were talking about any other deployment, we would immediately question why we were deploying a system so poorly if we plan to depend on it. If our vendor forces us to behave this way, we should react in the same manner – if the vendor doesn’t take the product to the same degree that we take the least of our IT services, why should we?
This is an “impedance mismatch”, as we say in engineering circles, between our needs (production systems) and how the vendor making that system appears to treat them (hobby or entertainment systems.) If we need to depend on this product for our businesses, we need a vendor that is on board and understands business needs – has a production mind set. If the product is not business targeted or business ready, we need to be aware of that. We need to question why we feel we should be using a service in production, on which we depend and require support, that is not intended to be used in that manner.
Is it supported? Is it being tested?
Something that is often overlooked from the perspective of customers is whether or not the necessary support resources for a product are in place. It’s not uncommon for the team that supports a product to become lean, or even disappear, but the company to keep selling the product in the hopes of milking it for as much as they can and bank on either muddling through a problem or just returning customer funds should the vendor be caught in a situation where they are simply unable to support it.
Most software contracts state that the maximum damage that can be extracted from the vendor is the cost of the product, or the amount spent to purchase it. In a case such as this, the vendor has no risk from offering a product that they cannot support – even if charging a premium for support. If the customer manages to use the product, great they get paid. If the customer cannot and the vendor cannot support it, they only lose money that they would never have gotten otherwise. The customer takes on all the risk, not the vendor.
This suggests, of course, that there is little or no continuing testing of the product as well, and this should be of additional concern. Just because the product runs does not mean that it will continue to run. Getting up and running with an unsupported, or worse unsupportable, product means that you are depending more and more over time on a product with a likely decreasing level of potential support, slowly getting worse over time even as the need for support and the dependency on the software would be expected to increase.
If a proprietary product is deployed in production, and the decision is made to forgo best practice deployments in order to accommodate support demands, how can this fit in a decision matrix? Should this imply that proper support does not exist? Again, as before, this implies a mismatch in our needs.
Is It Still Being Developed?
If the deployment needs of the software follow old, out of date practices, or require out of date (or not reasonably current software or design) then we have to question the likelihood that the product is currently being developed. In some cases we can determine this by watching the software release cycle for some time, but not in all cases. There is a reasonable fear that the product may be dead, with no remaining development team working on it. The code may simply be old, technical debt that is being sold in the hopes of making a last, few dollars off of an old code base that has been abandoned. This process is actually far more common than is often believed.
Smaller software shops often manage to develop an initial software package, get it on the market and available for sale, but fail to be able to afford to retain or restaff their development team after initial release(s). This is, in fact, a very common scenario. This leaves customers with a product that is expected to become less and less viable over time with deployment scenarios becoming increasingly risky and data increasing hard to extricate.
How Can It Be Supported If the Platform Is Not Supported?
A common paradox of some more extreme situations is software that, in order to qualify as “supported”, requires other software that is either out of support or was never supported for the intended use case. Common examples of this are requiring that a server system be run on top of a desktop operating system or requiring versions of operating systems, databases or other components, that are no longer supported at all. This last scenario is scarily common. In a situation like this, one has to ask if there can ever be a deployment, then, where the software can be considered to be “supported”? If part of the stack is always out of support, then the whole stack is unsupported. There would always be a reason that support could be denied no matter what. The very reason that we would therefore demand that we avoid best practices would equally rule out choosing the software itself in the first place.
Are Industry Skills and Knowledge Lacking?
Perhaps the issue that we face with software support problems of this nature are that the team(s) creating the software simply do not know how good software is made and/or how good systems are deployed. This is among the most reasonable and valid reasons for what would drive us to this situation. But, like the other hypothesis reasons, it leaves us concerned about the quality of the software and the possibility that support is truly available. If we can’t trust the vendor to properly handle the most visible parts of the system, why would we turn to them as our experts for the parts that we cannot verify?
The Big Problem
The big, overarching problem with software that has questionable deployment and maintenance practice demands in exchange for unlocking otherwise withheld support is not, as we typically assume a question of overall software quality, but one of viable support and development practices. That these issues suggest a significant concern for long term support should make us strongly question why we are choosing these packages in the first place while expecting strong support from them when, from the onset, we have very visible and very serious concerns.
There are, of course, cases where no other software products exist to fill a need or none of any more reasonable viability. This situation should be extremely rare and if such a situation exists should be seen as a major market opportunity for a vendor looking to enter that particular space.
From a business perspective, it is imperative that the technical infrastructure best practices not be completely ignored in exchange for blind or nearly blind following of vendor requirements that, in any other instance, would be considered reckless or unprofessional. Why do we so often neglect to require excellence from core products on which our businesses depend in this way? It puts our businesses at risk, not just from the action itself, but vastly moreso from the risks that are implied by the existence of such a requirement.