We get this all of the time in IT, a vendor tells us that a system cannot be virtualized.\u00a0 The reasons are numerous.\u00a0 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.\u00a0 Vendors have worked hard to perfect this sales pitch over the years and I think that it is important to dissect it.<\/p>\n
The root cause of problems is that vendors are almost always seeking ways to lower costs to themselves while increasing profits from customers.\u00a0 This drives a lot of what would otherwise be seen as odd behaviour.<\/p>\n
One thing that many, many vendors attempt to do is limit the scenarios under which their product will be supported.\u00a0 By doing this, they set themselves up to be prepared to simply not provide support – support is expensive and unreliable.\u00a0 This is a common strategy.\u00a0 It some cases, this is so aggressive that any acceptable, production deployment scenario fails to even exist.<\/p>\n
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.)\u00a0 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.)\u00a0 And one of the most common cases is forbidding virtualization.<\/p>\n
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.\u00a0 These needs are at odds with one another.<\/p>\n
Of course, no one expects every vendor to support every potential scenario.\u00a0\u00a0 Limits must be applied.\u00a0 But there is a giant chasm between supporting reasonable, well deployed systems and actively requiring unacceptably bad deployments.\u00a0 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.\u00a0 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.<\/p>\n
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!<\/em><\/p>\n Some important things need to be understood about virtualization.\u00a0 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.\u00a0 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.\u00a0 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.<\/p>\n There are, of course, always rare exceptions to nearly any rule.\u00a0 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.\u00a0 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.\u00a0 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.\u00a0 In all other cases, your server needs to be virtual.<\/p>\n Is it not important?<\/strong><\/p>\n 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?\u00a0 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.\u00a0 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?<\/p>\n 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.)\u00a0 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.\u00a0 If the product is not business targeted or business ready, we need to be aware of that.\u00a0 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.<\/p>\n Is it supported?\u00a0 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.\u00a0 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.<\/p>\n 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.\u00a0 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.\u00a0 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.\u00a0 The customer takes on all the risk, not the vendor.<\/p>\n This suggests, of course, that there is little or no continuing testing of the product as well, and this should be of additional concern.\u00a0 Just because the product runs does not mean that it will continue to run.\u00a0 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.<\/p>\n 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.<\/p>\n <\/p>\n Is It Still Being Developed?<\/strong><\/p>\n 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.\u00a0 In some cases we can determine this by watching the software release cycle for some time, but not in all cases.\u00a0 There is a reasonable fear that the product may be dead, with no remaining development team working on it.\u00a0 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.\u00a0 This process is actually far more common than is often believed.<\/p>\n 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).\u00a0 This is, in fact, a very common scenario.\u00a0 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.<\/p>\n <\/p>\n How Can It Be Supported If the Platform Is Not Supported?<\/strong><\/p>\n 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.\u00a0 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.\u00a0 This last scenario is scarily common.\u00a0 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”?\u00a0 If part of the stack is always out of support, then the whole stack is unsupported.\u00a0 There would always be a reason that support could be denied no matter what.\u00a0\u00a0 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.<\/p>\n Are Industry Skills and Knowledge Lacking?<\/strong><\/p>\n 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.\u00a0 This is among the most reasonable and valid reasons for what would drive us to this situation.\u00a0 But, like the other hypothesis reasons, it leaves us concerned about the quality of the software and the possibility that support is truly available.\u00a0 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?<\/p>\n The Big Problem<\/strong><\/p>\n 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.\u00a0 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.<\/p>\n There are, of course, cases where no other software products exist to fill a need or none of any more reasonable viability.\u00a0 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.<\/p>\n 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?\u00a0 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.<\/p>\n","protected":false},"excerpt":{"rendered":" We get this all of the time in IT, a vendor tells us that a system cannot be virtualized.\u00a0 The reasons are numerous.\u00a0 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.\u00a0 Vendors … Continue reading You Can’t Virtualize That!<\/span>
\n<\/strong><\/p>\n