You Cannot Virtualize That
-
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.
-
Definitely looking for feedback and ideas on this one. Trying to get the idea across but struggling to figure out if I've worded it in a good way.
-
@scottalanmiller said in You Cannot Virtualize That:
Definitely looking for feedback and ideas on this one. Trying to get the idea across but struggling to figure out if I've worded it in a good way.
The depth of thought that is displayed is obvious. Your entire article makes complete sense to me. Your ability to articulate your thoughts, and deliver them to others (while retaining readability) is amazing.
Thank you.
My pee break is over! Back to bed for me.
-
@scottalanmiller said in You Cannot Virtualize That:
Definitely looking for feedback and ideas on this one. Trying to get the idea across but struggling to figure out if I've worded it in a good way.
Do you mind if I re-write this? I wonder if a lot of it could be made shorter for the sake of speed reading online.
"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."
Becomes
"One thing that many vendors do is limit the scenarios under which their product will be supported. They set themselves up to simply not provide support - support is expensive and unreliable. This is a common strategy and in some cases any acceptable scenario fails to even exist."
For me I'd prefer reading the above, we're cutting out words and also changing the tone. We're not saying try to do, we're saying this is something they are doing today.
-
To me the article makes sense, as I've said the same thing, but less verbose, time and again.
Software vendors who sell a product but have odd requirements (IE Server 2003) are clearly there to just sell the product, when you have an issue they'll claim you're out of a support window, even though the product has that requirement.
The bit about vendor space where existing vendors simply don't support common best practice and how there is a vacuum should be made more verbose.
There is huge potential for businesses in this space.
-
The one I usually get is licensing. "Well there is no way for us to get the licensing key read..."
Me: "Well there's three ways off the top of my head I can think of... one is a key that calls home every 30 days. In which case we just need Internet connectivity, which we have, and then input a license key, which you could provide us. The other way is setting up a subscriber locally, and tie that into some subscription web client, similar to the first option works. The other is sending us a USB license, which we'd plug into the host so the VM can access it 24/7."
Rep: "Mmm yeah that just won't work."
That won't work for me, or for you? Cause those options consistently work for me. Probably won't work for you, cause you're not making any money off the appliance I don't need.
-
@DustinB3403 said in You Cannot Virtualize That:
There is huge potential for businesses in this space.
Huge potentials for what in what space?
Maybe you mean:
The bit about vendor space where existing vendors simply don't support common best practice and how there is a vacuum should be made more verbose.
That maybe true - OK well we know it is, but it would often require the vendor who makes the crappy product to provide information they probably are unwilling to make.
For example, I have a distribution client. They have to use the manufacture's software to gather the information they need to provide quotes to re sellers. In order to compete in this space, someone would have to write software that has access to the APIs of the manufacturer, if that's even possible. etc etc
Being a super small market share, and the likely denial from the manufacturer, this project would never get off the ground. -
@BBigford said in You Cannot Virtualize That:
The one I usually get is licensing. "Well there is no way for us to get the licensing key read..."
Me: "Well there's three ways off the top of my head I can think of... one is a key that calls home every 30 days. In which case we just need Internet connectivity, which we have, and then input a license key, which you could provide us. The other way is setting up a subscriber locally, and tie that into some subscription web client, similar to the first option works. The other is sending us a USB license, which we'd plug into the host so the VM can access it 24/7."
Rep: "Mmm yeah that just won't work."
That won't work for me, or for you? Cause those options consistently work for me. Probably won't work for you, cause you're not making any money off the appliance I don't need.
In that situation, they just need to up the cost of the VM solution. Just look at Unitrends. Their VM pricing isn't that much less than their appliance solutions - and you have to provide ALL the hardware.
-
@Dashrender I think you're misunderstanding the idea.
If there is Software vendor HealthCrap, and HealthCrap makes really crappy software, but it's the only software available. They have a monopoly, so any other software house could come along and make a competing software, that does the same thing, but better.
And have it supported in virtual environments etc.
Obviously the hurdles here include knowing what needs to be done, the cost of building a competitive product, federal regulations etc.
Which aren't small by any means.
But any IT person would (I hope) strive to get this software in house and dump the old one as soon as possible if it came available.
-
I have had this same approach for some time. I can't imagine pulling the trigger on software with that type of requirement and it does lead me to believe that they are not actively developing and I would never have confidence in their ability to maintain/support the product, let alone grow with my organization's needs.
-
@wrx7m said in You Cannot Virtualize That:
I have had this same approach for some time. I can't imagine pulling the trigger on software with that type of requirement and it does lead me to believe that they are not actively developing and I would never have confidence in their ability to maintain/support the product, let alone grow with my organization's needs.
I had a software vendor (existing) for one of my customers. As I learned about their product, and what was supported, and not. Then finding out that basic industry standards were unavailable I advised the customer against the solution.
To be fair to the software vendor this was a legacy solution from the early 90s. And the customer didn't like change. The vendor had updated offerings that included what was needed and advisable. He eventually switched when they EOL'd his solution and all support. -
That's great and all, for sure we all agree virtualization is best. Not sure where else you're going with this. I guess that's enough by it's self but I'm left feeling.... unsatisfied.
I think you could cut all this down a lot by making a clearer point:
"Make virtualization support a key factor when shopping for new things".
or
"The importance of checking the recommended setup for new toys: don't get stuck with gear that does not virtualize"
I'm not sure what to tell you man...
-
I think this is more general than that @MattSpeller. Don't buy things that won't provide support within the industry standard approach unless you have a very specific need that can't be otherwise met.
-
@Dashrender Virtualization is mentioned ~10? times in the first section... that seems focused enough for me
Point taken (because it's a good one) though I disagree about the article's focus.
-
You said
@MattSpeller said in You Cannot Virtualize That:
I guess that's enough by it's self but I'm left feeling.... unsatisfied.
I guess I didn't feel that way because I took a more generalized look at the article, and didn't limit it to only virtualization.
-
@Dashrender said in You Cannot Virtualize That:
@DustinB3403 said in You Cannot Virtualize That:
There is huge potential for businesses in this space.
Huge potentials for what in what space?
Maybe you mean:
The bit about vendor space where existing vendors simply don't support common best practice and how there is a vacuum should be made more verbose.
That maybe true - OK well we know it is, but it would often require the vendor who makes the crappy product to provide information they probably are unwilling to make.
For example, I have a distribution client. They have to use the manufacture's software to gather the information they need to provide quotes to re sellers. In order to compete in this space, someone would have to write software that has access to the APIs of the manufacturer, if that's even possible. etc etc
Being a super small market share, and the likely denial from the manufacturer, this project would never get off the ground.In that case the issue is bigger but NOT one of APIs, right? It would be one of replicating bad software AND a bad manufacturer.
-
@MattSpeller said in You Cannot Virtualize That:
That's great and all, for sure we all agree virtualization is best. Not sure where else you're going with this. I guess that's enough by it's self but I'm left feeling.... unsatisfied.
I think you could cut all this down a lot by making a clearer point:
"Make virtualization support a key factor when shopping for new things".
or
"The importance of checking the recommended setup for new toys: don't get stuck with gear that does not virtualize"
I'm not sure what to tell you man...
It's not fully about virtualization, though, it's about not being production ready and when you can identify that. And disputing the "we need X so that we can run in production" when X implies you can't run in production. It's pointing out the paradox of buying hobby class software in a business using production needs as an excuse.
-
@Dashrender said in You Cannot Virtualize That:
You said
@MattSpeller said in You Cannot Virtualize That:
I guess that's enough by it's self but I'm left feeling.... unsatisfied.
I guess I didn't feel that way because I took a more generalized look at the article, and didn't limit it to only virtualization.
Maybe the title is just wrong
-
My response to the Title would be: "Wanna bet?"
Sure, you'd lose support if you virtualized something they told you not to... but companies are trying to get out of doing support anyway.
But like anything else, that'd be more of a business decision than an IT one.
-
@dafyre said in You Cannot Virtualize That:
My response to the Title would be: "Wanna bet?"
Sure, you'd lose support if you virtualized something they told you not to... but companies are trying to get out of doing support anyway.
But like anything else, that'd be more of a business decision than an IT one.
Should be all one and the same. All IT decisions should be in a business context. The idea that there could be a business vs IT decision should not exist and implies a management structure that isn't aware of what the role of IT even is. The only reason that IT cares about virtualization is because it, too, is a business decision.
